======================================================================= 1 === Date: 1 Mar 1995 00:23:08 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Where is ParseParams? In article , bwbecker wrote: >I think I remember a promise that ParseParams would be >returned to libm3 in v3.5. I can't find it, although >it is documented in the WWW pages at >http://www.research.digital.com/SRC/m3sources/html/parseparams/src/Parse >Params.i3 I don't know about 3.5, but there's a `parseparams' package in 3.5.1 which appears to be it... Richard. -- `There comes a time when you look into the mirror and you realise that what you see is all that you will ever be. And then you accept it. Or you kill yourself. Or you stop looking in mirrors.' The University of Cambridge can't have these opinions even if it wants them. ======================================================================= 2 === Date: 1 Mar 1995 10:39:38 GMT From: sd@inf.rl.ac.uk Subject: M3 on Solaris I'm having severe problems building the latest Modula-3 compiler on a Sparc 10 under Solaris 2.3 (SunOS 5.3). It seems to compile the bootstrap compiler correctly, but can't build the standard library from the source code. I've unpacked boot-SOLsun.tar.gz, m3cc.tar.gz and m3.tar.gz. I've managed to compile everything under boot-SOLsun (after a few problems with wrong C compilers and lost libraries :-). I then try to build the library from m3. Running m3build correctly builds mtex, then core dumps with a segmentation fault trying to build m3core. dbx says the problem is in a routine called _INITMRTLinker. This is the first time I've tried to build Modula 3, so I'm not in a position to fix problems like this. Has anyone else managed to get the compiler built under Solaris? And if so, could they help? Is boot-SOLgnu any better? Thanks in advance, -- Si Dr Simon A. Dobson Computing and Information Systems \ My mind is racing, as it always will, DRAL, Rutherford Appleton Laboratory \ My hands tired, my heart aches Chilton, Didcot, Oxon OX11 0QX, UK. \ I'm half a world away. sd@inf.rl.ac.uk http://www.cis.rl.ac.uk/people/sd/contact.html ======================================================================= 3 === Date: Wed, 01 Mar 1995 8:57:02 MET From: rudy@cs.rug.nl Subject: Language Definition 2 At this moment I find Modula-3 one of the best programming languages. Working with Modula-3 I still find minor points where the language (definition) could be improved. Therefore I will propose some minor changes to the language definition. I hope to initiate a fruitful discussion about the language definition. I will collect the reactions and write a final report. Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup comp.lang.modula3. Reactions can also be sent to me personally: rudy@cs.rug.nl Introduction ============ I introduce the second proposal to change the language definition with two examples of unsafe implementations. I use the new definition of "ADR(x)", where instead of "ADDRESS", "ADR(x)" returns an "UNTRACED REF T" when the static type of "x" is "T". The new definition increases the safety of interfacing with the C world. I have showed these examples to some members of my department, and they all find them lunatic. So I have reported these examples as bugs to Bill Kalsow and he states that the error messages are correct according to the language definition, and really they are! From my point of view the language definition should be changed. Example 1 ========= VAR x:UNTRACED REF REAL; y:UNTRACED REF INTEGER; z:ADDRESS; BEGIN x:=y; (* error *) z:=y; x:=z; (* correct *) END Test. Are "x" and "y" assignable? "x" and "y" are not assignable. So you would expect "y" is not assignable to "z" or "z" is not assignable to "x". Besides the error in "x:=y" you would also expect an error in "z:=y" or "x:=z"! The statement "z:=y" is a normal assignment of a subtype expression to its supertype. According to the language is "x:=z" allowed by an implicit unsafe narrow, so "x:=z" is also a legal assignment of a supertype expression to a subtype. The problems are caused by (Language definition section 1.8 Unsafe operations) the rule: In unsafe modules the definition of "assignable" for types is extended: two reference types "T" and "U" are assignable if "T <: U" or "U <: T". The only effect of this change is to allow a value of type "ADDRESS" to be assigned to a variable of type "UNTRACED REF T". It is an unchecked runtime error if the value does not address a variable of type "T". I believe it will be better to remove these lines from the language definition. If one wants to assign an expression of the type "ADDRESS" to a variable of the type "UNTRACED REF T" one can always use the transfer function "LOOPHOLE" Example 2 ========= VAR x:REAL; y:=ADR(x); z:=y+1; BEGIN x:=z^; (* error *) x:=(y+1)^; (* error *) y:=y+1; x:=y^ END Test. What is the type of the expression "y+1": "ADDRESS" or "UNTRACED REF REAL"? It is likely that "y+1" is not pointing to a real anymore, so "ADDRESS" would be a good choise. On the other hand, address arithmetic is frequently used to compute references to array elements, so "UNTRACED REF REAL" is defendable. According to the language definition the type of "y+1" is "ADDRESS": "+" is not defined on "UNTRACED REF REAL", so "y" is widened to "ADDRESS" before the addition. The type of "y+1" is "ADDRESS", so "z:=y+1" gives a variable "z" of type "ADDRESS" and the assignment "x:=z^" produces an error. For similar reason "x:=(y+1)^ is also not allowed. Because the type of the expression "y+1" is "ADDRESS" and the type "UNTRACED REF REAL" is a subtype of "ADDRESS", the types "y:=y+1" are not assignable. According to the language definition an implicit, unsafe narrow is generated to allow this assignment. Now we obtain the peculiar situation that "x:=(y+1)^" is not allowed and "y:=y=1; x:=y^" is allowed. Proposal 2: untraced references and addresses ============================================= The common accepted rules for subtyping are violated in case of unsafe modules. I propose therefore to remove the lines mentioned above from the language definition. The new definition of "ADR" makes this function as safe as "NEW", so it can also be used in safe modules: ADR(VAR x: Any) : UNTRACED REF Any This function becomes dangerous if its result is used as the argument of "DISPOSE", because the result is an indisposable untraced reference. We have a similar problem in case of disposing an already disposed untraced reference. So the "DISPOSE" should remain unsafe. Address arithmetic in not unsafe as long as the computed addresses are not dereferenced. This means that the following operations are all safe: infix + ( x: ADDRESS, y: INTEGER): ADDRESS infix - ( x: ADDRESS, y: INTEGER): ADDRESS infix - ( x: ADDRESS, y: ADDRESS): INTEGER INC (VAR x: ADDRESS; n: INTEGER := 1) DEC (VAR x: ADDRESS; n: INTEGER := 1) Because now the implicit narrow is forbidden, addresses can not be converted to untraced references by safe operations. So an explicit unsafe "LOOPHOLE" is necessary to dereference an address! Notice that in the new situation "INC" and "DEC" are only defined on variables of type "ADDRESS" and not on "UNTRACED REF Any". Furthermore the following operations are defined infix = ( x, y: ADDRESS ): BOOLEAN infix # ( x, y: ADDRESS ): BOOLEAN infix < ( x, y: ADDRESS ): BOOLEAN infix <= ( x, y: ADDRESS ): BOOLEAN infix => ( x, y: ADDRESS ): BOOLEAN infix > ( x, y: ADDRESS ): BOOLEAN MIN ( x, y: ADDRESS ): ADDRESS MIN ( x, y: UNTRACED REF T ): UNTRACED REF T MAX ( x, y: ADDRESS ): ADDRESS MIN ( x, y: UNTRACED REF T ): UNTRACED REF T Notice that in the new situation the character of the operation, safe or unsafe, only depends on the operation and not on the arguments! This results in the unsafe keywords "DISPOSE" and "LOOPHOLE". What are unsafe oprations: 1) dereferencing of variables of type "ADDRESS" (forbidden) 2) using the "LOOPHOLE" transfer function 3) using the "DISPOSE" statement 4) using unsafe interfaces 5) mixing traced and untraced references All other operations are in the new situation safe! Syntax ====== No changes. ======================================================================= 4 === Date: 1 Mar 1995 15:23:51 GMT From: ljw1004@thor.cam.ac.uk (L.J. Wischik) Subject: Re: Language Definition < proposal for READONLY variable declarations > >The WITH statement already does what you are proposing. Not really. As already noted, WITH a=b, can have 'a' a writable value, depending on what b is. Also, the READONLY as proposed would be very convenient because you would be able to declare variables precisely where you wanted them. But, some more has to be said about its initialisation. If you declare READONLY a; in an interface, you have to be able to set its initial value somewhere. If it was a VAR a, you would set its initial value in the BEGIN..END of some module that exported the interface; but with READONLY, it would get very messy. There are two solutions: either have some ugly syntax specifying where a READONLY is not a READONLY, or allow READONLY variables only in restricted locations. I think because of this problem, the proposed READONLY becomes not-that-useful. -- Lucian Wischik, Queens' College, Cambridge CB3 9ET, UK. ljw1004@cam.ac.uk ======================================================================= 5 === Date: Wed, 1 Mar 1995 08:31:25 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: M3 on Solaris sd@inf.rl.ac.uk writes: > I'm having severe problems building the latest Modula-3 compiler on a Sparc > 10 under Solaris 2.3 (SunOS 5.3). It seems to compile the bootstrap compile r > correctly, but can't build the standard library from the source code. > > I've unpacked boot-SOLsun.tar.gz, m3cc.tar.gz and m3.tar.gz. I've managed t o > compile everything under boot-SOLsun (after a few problems with wrong C > compilers and lost libraries :-). I then try to build the library from m3. > Running m3build correctly builds mtex, then core dumps with a segmentation > fault trying to build m3core. dbx says the problem is in a routine called > _INITMRTLinker. Are you building 3.5.1 or 3.5 ? This problem was present in 3.5 and has been fixed in 3.5.1. If you are building 3.5.1, you can send me you configuration file and I'll take a quick look to see if there is anything obviously wrong. I've successfully built 3.5.1 (SOLsun) without any problems. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 6 === Date: 1 Mar 1995 21:11:15 GMT From: gabrius@riker.cig.mot.com (David M. Gabrius) Subject: Modula-3 for Amiga? I was wondering if there's a port underway for Modula-3 for the Amiga. Thanks! -- David Gabrius -- Motorola Cellular \\ gabrius@cig.mot.com \\ 708-632-5944 Software Engineer \\"You miss too much these days if you stop to think" -U2 "And you can find/Your own way out/You can build/And I can will..." -U2 "Some days take less but most days take more" \\ #include ======================================================================= 7 === Date: 2 Mar 1995 00:05:03 GMT From: schaub@ponder.csci.unt.edu (Stephen Schaub) Subject: Netobjects: ASSERT failure in ThreadPosix I'm working on a small netobjects program and am running into the following run-time error: *** *** runtime error: *** ASSERT failed *** file "../src/thread/POSIX/ThreadPosix.m3", line 1174 *** This occurs when I make a network object method call and attempt to transfer a linked list with more than, say, roughly 30 nodes. Sometimes the error occurs on the client side, and sometimes on the server side. Lists with fewer nodes don't cause problems. I'm using the Linux version 3.4 release. The application is a Trestle demo that attempts to check drawings in and out from a central repository. Drawings are represented by a linked list of points, managed by a (non-network) drawing object. When a drawing is checked out, the client makes a method call to obtain a drawing object from the server; the client can then make modifications to the drawing object (by adding new points) and then checks the drawing back in by transferring the drawing object to the central repository using another method call. Again, the programs work fine for drawings consisting of just a few points, but the run-time error rears its head when more nodes are involved. Any ideas what might be wrong? Thanks, Stephen Schaub schaub@cs.unt.edu ======================================================================= 8 === Date: 1 Mar 1995 20:16:12 -0700 From: mian@beethoven.cs.colostate.edu (adnan mian) Subject: How do you find the EOF for a file? How do you find the EOF? I am reading in the file like this run ======================================================================= 10 === Date: 2 Mar 1995 16:58:12 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: WinNT questions In article , hgeorge@eskimo.com (Harry George) writes: > I'm ready to try Modula3 on WinNT. But... > 1. Will it work if I install using the DOS file system (FAT), > so that I can work with both WinNT and DOS/Windows (WfW) > on the same files? I doubt it will work. The NT port of SRC Modula-3 generates and uses long file names. > 2. Which (if any) Modula-3 release is stable on WinNT? I'd prefer > an ftp-able binary. Something rock solid, so I could concentrate > on writing app code rather than debugging the installation. > (I'd be willing to do a compile if it was a pretty sure thing.) We don't have a binary to distribute. Installing a binary copy of the system in a location you specify will require a bit of new machinery. So far we've done our development on NT (beta 3.1). We've received some messages indicating that the released version (3.5) is slightly different. > 3. Is there a Modula-3 .i3 for WinNT's Win32? How about for OpenGL? There's a collection of .i3 files that describe much of the Win32 interface. The coverage is not 100%. I don't know of any Modula-3 interfaces for OpenGL. - Bill Kalsow ======================================================================= 11 === Date: 2 Mar 1995 11:58:25 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Where is ParseParams? In article , Byron Weber Becker wrote: >>bwbecker@watdragon.uwaterloo.ca writes: >> > I think I remember a promise that ParseParams would be >> > returned to libm3 in v3.5. I can't find it, although >> > it is documented in the WWW pages at >> > http://www.research.digital.com/SRC/m3sources/html/parseparams/src/Parse >> > Params.i3 >> > >> > Thanks for any help... >> >>It's in 3.5.1 in m3/parseparams > >Thanks for the response, but I still don't see it. The folks >who installed M3 claim it's 3.5.1. I think the right >place to look (on our system) is >.../modula3/lib/m3/pkg/lim3/src >but I see no m3 or parseparams in that directory, nor does >the find command find it in any subdirectories. m3which >doesn't find it, nor does m3build when I try to IMPORT it >in a program. Further clues? It's in pkg/parseparams (ie. .../modula3/lib/m3/pkg/parseparams) - you'll have to include import(parseparams) In your m3makefile to import the library before you can import the ParseParams interface in your program. (this is assuming parseparams has been installed at your site, though I can't see any reason for it not to be). Richard. -- `There comes a time when you look into the mirror and you realise that what you see is all that you will ever be. And then you accept it. Or you kill yourself. Or you stop looking in mirrors.' The University of Cambridge can't have these opinions even if it wants them. ======================================================================= 12 === Date: Thu, 2 Mar 1995 14:55:58 -0500 From: douglm@rpi.edu Subject: Re: Network objects, threads and stacks >Another solution that doesn't require any changes to the network object's >interfaces or runtime is for you to fork off your own thread in those cases >where you know that you will need a large stack. That is, the method >implementation in your server forks off a thread of its own with the size >that you choose. It's a little more work on your part, but doesn't require >any changes to the current interfaces. > I'm certainly aware that I could do that, and I'm not trying to avoid the work of doing so. However, I presume that one of the aims of having network objects is to hide such details. I don't want to have to change the program structure to get around an implementation feature. I think the implementation of network objects is great and should work well for most cases. If, however, the application begins to develop accretions as we try to avoid problems with the implementation I don't think it's inappropriate to consider changes. (That sounds awful but I hate those smiley things) I believe I could solve my own problems if I could register another transport mechanism. My belief is that there is no way to do so currently although the mechanism seems to be partially in place. ======================================================================= 13 === Date: 2 Mar 1995 19:51:48 GMT From: lrau@hal.COM (Larry Rau) Subject: Re: WinNT questions As of Win NT 3.5 the FAT filesystem supports long filenames, and as long as the runtime uses OS calls there should be no requirement for NTFS -- although I think NTFS is better, for various other reasons. -- Larry Rau Migration Software Systems (lrau@migration.com) ======================================================================= 14 === Date: Thu, 2 Mar 1995 18:47:22 GMT From: "Jason D. Smith" Subject: Re: Building NT binaries ahmiles@uk.oracle.com (Hugh Miles) wrote: > > In article <3i0f44$f6u@news1.is.net>, cadmus@cadmusinteractive.is.net (Reggie Burnett) says: > > > >I have tried building NT binaries of SRC Modula 3 3.5.1 (or something like t hat). > >I build quake, but now I am getting alot of "system cannot find specified fi le". > > > >Is there anyone else out there trying to build NT binaries? > > > >If DEC people are listening, why don't you make NT binaries available? > > > >Reggie > > > > > I am alos tyring to build the mod3 complier on windows NT 3.5. > When I build quake.exe I get the linker error > : unresolved external __imp___p__iob. > > Can any one help! or dose any have the NT binaries? > > Andy If you are using VC2.0, try changing all ocurrences of CRTDLL.LIB with MSVCRT20.LIB in all make- and quakefiles (i.e. m3build\template\NT386 and quake\makefile.nt) WRT binaries, I had to make room on my drive ... 8-( Sorry. Jason. ======================================================================= 15 === Date: 3 Mar 1995 11:13:36 GMT From: sd@inf.rl.ac.uk Subject: Re: M3 on Solaris Thanks to the people who responded to my posting about problems compiling Modula-3 under Solaris. The solution (due to Geoff Wyant at Sun) is to move to release 3.5.1 which has corrected the trouble. Having acquired the new archives the system built "out of the box" with a single exception of one incorrectly-terminated interface (I'll leave the solution as an excercise for the reader :-). Blair MacIntyre at Columbia reported that the Solaris GNU version works fine, so that's an alternative way out. Thanks again! It's good to see that news still has the power to fix people's difficulties! -- Si Dr Simon A. Dobson Computing and Information Systems \ My mind is racing, as it always will, DRAL, Rutherford Appleton Laboratory \ My hands tired, my heart aches Chilton, Didcot, Oxon OX11 0QX, UK. \ I'm half a world away. sd@inf.rl.ac.uk http://www.cis.rl.ac.uk/people/sd/contact.html ======================================================================= 16 === Date: 2 Mar 1995 17:17:38 -0500 From: atlas@alpha.bin-sixx.com (Atlas Computer Systems) Subject: WD_1_GIG_DRIVE *********************************ADVERTISEMENT******************************** Atlas Computer Systems is pleased to announce the arrival of the Western Digital Caviar AC31000 1.08 GB EIDE hard drive for the unbelievably low price of $389 plus $10 shipping and handling. Call Atlas Computer Systems at (904) 694-2900 Monday through Friday 9 a.m. to 6 p.m. EST with your credit card ready to place an order. All orders placed within the continental United States will be shipped via UPS Second Day Air. Ask your ACS sales representative for information on international shipping. If you're interested in having our current price list e-mailed to you, send a request to us001663@interramp.com. We look forward to hearing from you. *********************************ADVERTISEMENT******************************** ======================================================================= 17 === Date: 2 Mar 1995 19:56:55 GMT From: fld@Informatik.Uni-Bremen.DE () Subject: M3_3.5.1, SOLgnu, Solaris 2.4, missing library -laio I have succsessfully bootstraped m3_3.5.1, Sol2.4, GNU version. A lot of the whole m3 libraries and applications have been installed. The applications can be executed without any problem. But when I try to create 'netobjd' or 'stubgen' the following message occurs: ld: fatal: library -laio: not found ld: fatal: File processing errors. No output written to ... Can anyone explain to me where to find this library? Why is it needed ? I could not find any reference to this library in the m3makefiles. How does the compiler or m3build know about it? -- Guenter Feldmann EMail: fld@informatik.Uni-Bremen.de FB 3, Informatik Univ. Bremen, Germany ======================================================================= 18 === Date: Fri, 3 Mar 95 13:47:25 GMT From: buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409) Subject: Re: Language Definition 2 In article <9503010755.AA22038@inet-gw-1.pa.dec.com> you wrote: : I introduce the second proposal to change the language definition with two : examples of unsafe implementations. I use the new definition of "ADR(x)", : where instead of "ADDRESS", "ADR(x)" returns an "UNTRACED REF T" when the : static type of "x" is "T". The new definition increases the safety of : interfacing with the C world. I have also thought of an "ADR(x)" operator, with the same semantics. It might be nice to have. You now can have pointers to the stack. This is an advantage and a disadvantage, at the same time. You can build complicated datastructures on the stack, pass them around, and don't need to think about deallocation.. But you can also generate a dangling pointer when you put the generated reference into a global variable. So "ADR(x)" would be only possible inside an unsave module, where you can always use "ADDRESS(x)". You also take away some choices from the languages implementor. As long, as s/he is guaranteed, that there are no untraced references to the stack, s/he might do some estoic things to increase performance. Some optimisations can't be done when there are aliases to locations. : Address arithmetic in not unsafe as long as the computed addresses are not : dereferenced. This means that the following operations are all safe: : infix + ( x: ADDRESS, y: INTEGER): ADDRESS : infix - ( x: ADDRESS, y: INTEGER): ADDRESS : infix - ( x: ADDRESS, y: ADDRESS): INTEGER : INC (VAR x: ADDRESS; n: INTEGER := 1) : DEC (VAR x: ADDRESS; n: INTEGER := 1) : Because now the implicit narrow is forbidden, addresses can not be converted : to untraced references by safe operations. So an explicit unsafe "LOOPHOLE" i s : necessary to dereference an address! Notice that in the new situation "INC" : and "DEC" are only defined on variables of type "ADDRESS" and not on : "UNTRACED REF Any". The problem is, you can do address arithmetic outside of unsave modules, now. So you have to take into account all the client code of an unsave module, when checking the code for robustness. Passing an ADDRESS somewhere dosn't change it's value. Inside an unsave module, you know, you are system dependant, and may have to check, if a generated ADDRESS is a) valid and b) points to something. When accepting an ADDRESS, someone else did arithmetic on, you don't know anything about it. You even might be unable to check, if it is save to use. : Furthermore the following operations are defined : infix = ( x, y: ADDRESS ): BOOLEAN : infix # ( x, y: ADDRESS ): BOOLEAN : infix < ( x, y: ADDRESS ): BOOLEAN : infix <= ( x, y: ADDRESS ): BOOLEAN : infix => ( x, y: ADDRESS ): BOOLEAN : infix > ( x, y: ADDRESS ): BOOLEAN : MIN ( x, y: ADDRESS ): ADDRESS : MIN ( x, y: UNTRACED REF T ): UNTRACED REF T : MAX ( x, y: ADDRESS ): ADDRESS : MIN ( x, y: UNTRACED REF T ): UNTRACED REF T This assumes that either a) all values of Type ADDRESS are ordered or b) ``x < y'' isn't equivalent to ``NOT (x >= y)'' for Type ADDRESS. if x and y are unordered, ``x < y'' evaluates to FALSE and ``x >= y'' evaluates to FALSE, too. The Modula3 Language Definition doesn't say anything about the Ordering of Values of Type ADDRESS. You can implement it even for a strange CPU architecture. Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@lts.sel.alcatel.de ======================================================================= 19 === Date: 02 Mar 1995 22:48:23 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Re: WinNT questions >>>>> On 2 Mar 1995 16:58:12 GMT, kalsow@src.dec.com (Bill Kalsow) >>>>> said: >> 3. Is there a Modula-3 .i3 for WinNT's Win32? How about for OpenGL? Bill> There's a collection of .i3 files that describe much of the Bill> Win32 interface. The coverage is not 100%. Bill> I don't know of any Modula-3 interfaces for OpenGL. I have a set of .i3 files for OpenGL on the IRIS. If anyone wants them, I'll put the current set up on ftp -- they'll most likely change as we work with them. I don't know if they are the same as is required for NT. (When the WinNT support for netobj's is working, I will be installing it here. At that point, the first thing I will be doing is porting the OpenGL code we are writing on our IRIS to NT (in fact, the main reason for using NT will be as a cheaper 3D display driver). So, I'll make OpenGL i3's for NT then. So, if anyone has any hints as to when netobjs will be supported, you'll then know when we'll be making OpenGL i3's for NT. :-) -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 20 === Date: 1 Mar 1995 19:45:34 -0500 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: Netobjects: ASSERT failure in ThreadPosix >>>>> On 2 Mar 1995 00:05:03 GMT, schaub@ponder.csci.unt.edu (Stephen >>>>> Schaub) said: Stephen> I'm working on a small netobjects program and am running into the Stephen> following run-time error: Stephen> *** Stephen> *** runtime error: Stephen> *** ASSERT failed Stephen> *** file "../src/thread/POSIX/ThreadPosix.m3", line 1174 Stephen> *** Stephen> This occurs when I make a network object method call and Stephen> attempt to transfer a linked list with more than, say, Stephen> roughly 30 nodes. Sometimes the error occurs on the client Stephen> side, and sometimes on the server side. Lists with fewer Stephen> nodes don't cause problems. The network object stubs will be using the Pickling library for transfering your object, since it isn't one of the set of simple types it handles directly. Since the Pickling stuff is recursive, my guess is that you are running out of stack space. Look at the Pickle.i3 file, or the paper documentation that derives from it. It describes how to register a Pickling routine for your type. Create a pickler that iteratively scans your linked list, instead of recursively. That will hopefully solve your problem. Also, looking at the source would help you figure this out. Line 1174 in my installation (3.5.1) isn't an assert, but it's quite close to the Transfer proc, which appears to be checking if a guard at the beginning or end of you stack has been tromped. ======================================================================= 21 === Date: 03 Mar 1995 16:12:59 GMT From: bm@ground.cs.columbia.edu (Blair MacIntyre) Subject: Re: M3_3.5.1, SOLgnu, Solaris 2.4, missing library -laio >>>>> On 2 Mar 1995 19:56:55 GMT, fld@Informatik.Uni-Bremen.DE () >>>>> said: GF> I have succsessfully bootstraped m3_3.5.1, Sol2.4, GNU version. GF> A lot of the whole m3 libraries and applications have been installed. GF> The applications can be executed without any problem. GF> But when I try to create 'netobjd' or 'stubgen' the following message GF> occurs: GF> ld: fatal: library -laio: not found GF> ld: fatal: File processing errors. No output written to ... GF> Can anyone explain to me where to find this library? Why is it needed ? GF> I could not find any reference to this library in the m3makefiles. GF> How does the compiler or m3build know about it? I think the problem is that the m3makefiles for those programs specify build_standalone(), which doesn't work properly on Solaris. In this case, the problem is there is no libaio.a (at least on my system), only a libaio.so. I posted a script a while ago that partially fixes (I hope) the build_standalone problem on Solaris: it arranges things to that the m3 libraries are statically linked when building standalone, but the Solaris ones are linked dynamically. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 22 === Date: 2 Mar 1995 12:52:11 GMT From: Quentin Stafford-Fraser Subject: Re: Where is ParseParams? bwbecker@watdragon.uwaterloo.ca (Byron Weber Becker) wrote: > I think the right > place to look (on our system) is > ..../modula3/lib/m3/pkg/lim3/src No, it's a separate package, not part of libm3, so it's probably under ...modula3/lib/m3/pkg/parseparams/src. > m3which > doesn't find it, nor does m3build when I try to IMPORT it > in a program. Further clues? You need import("parseparams") in your m3makefile. Hope this helps, Quentin ======================================================================= 23 === Date: 4 Mar 1995 13:20:05 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Re: Netobjects: ASSERT failure in ThreadPosix In article <199503020045.TAA06441@shadow.cs.columbia.edu>, bm@news.cs.columbia. edu (Blair MacIntyre) writes: >>>>>> On 2 Mar 1995 00:05:03 GMT, schaub@ponder.csci.unt.edu (Stephen >>>>>> Schaub) said: > >Stephen> I'm working on a small netobjects program and am running into the >Stephen> following run-time error: > >Stephen> *** >Stephen> *** runtime error: >Stephen> *** ASSERT failed >Stephen> *** file "../src/thread/POSIX/ThreadPosix.m3", line 1174 >Stephen> *** > >Stephen> This occurs when I make a network object method call and >Stephen> attempt to transfer a linked list with more than, say, >Stephen> roughly 30 nodes. Sometimes the error occurs on the client >Stephen> side, and sometimes on the server side. Lists with fewer >Stephen> nodes don't cause problems. > >The network object stubs will be using the Pickling library for >transfering your object, since it isn't one of the set of simple types >it handles directly. Since the Pickling stuff is recursive, my guess >is that you are running out of stack space. > >Look at the Pickle.i3 file, or the paper documentation that derives >from it. It describes how to register a Pickling routine for your >type. Create a pickler that iteratively scans your linked list, >instead of recursively. That will hopefully solve your problem. Maybe the Pickle generic module should automatically register a pickelr for it's list type that will pickle it iteratively. This would save people having to write their own versions. Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 24 === Date: 04 Mar 1995 19:12:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Language Definition 2 rudy@cs.rug.nl wrote on 01.03.95 in <9503010755.AA22038@inet-gw-1.pa.dec.com>: > I have showed these examples to some members of my department, and they all > find them lunatic. So I have reported these examples as bugs to Bill Kalsow > and he states that the error messages are correct according to the language > definition, and really they are! From my point of view the language > definition should be changed. I don't see anything lunatic here; on the contrary, that's _exactly_ what I would expect. > Example 1 > ========= > > VAR x:UNTRACED REF REAL; > y:UNTRACED REF INTEGER; > z:ADDRESS; > > BEGIN > x:=y; (* error *) > z:=y; > x:=z; (* correct *) > END Test. > > Are "x" and "y" assignable? "x" and "y" are not assignable. So you would > expect "y" is not assignable to "z" or "z" is not assignable to "x". Besides No, I wouldn't. That's the exact behaviour lots of other languages have. For example, consider C - you can't assign a int* to a float*, but you can assign both to void* and vice versa. I think Modula-2 also works that way. Turbo Pascal certainly does. > Example 2 > ========= > > VAR x:REAL; > y:=ADR(x); > z:=y+1; > > BEGIN > x:=z^; (* error *) > x:=(y+1)^; (* error *) > y:=y+1; > x:=y^ > END Test. > > What is the type of the expression "y+1": "ADDRESS" or "UNTRACED REF REAL"? As you use the new form of ADR, it's the latter. > It is likely that "y+1" is not pointing to a real anymore, so "ADDRESS" Correct - y+1 _is_ a REAL instead. Adding 1 to a UNTRACED REF REAL (or to a traced one, at that) doesn't do address arithmetic, but instead dereferences and does real arithmetic. In short, "y+1" is exactly the same as "y^+1". Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 25 === Date: 5 Mar 1995 03:36:30 GMT From: pje120@cs.usask.ca (Patrick John Edwards) Subject: Re: Language Definition douglm@rpi.edu wrote: : Sam Kendall pointed out: : >The WITH statement already does what you are proposing. : > : In general there is more than one way of doing something. I guess the value : of such a feature is the self-documenting aspect. WITH doesn't really tell : us why it's being used other than as a shorthand construct. I agree completely here, the READONLY statement made the code much more readable. ======================================================================= 26 === Date: Mon, 6 Mar 95 07:58:17 GMT From: ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) Subject: Why no multiple inheritance in Modula-3? I have looked at the language definition of Modula-3, and I see that it only allows single inheritance. Are there any reasons for this except for the obviou s complication in implementing it? In my experience, multiple inheritance can be really useful, because it allows you to define different concepts and mix them in a class as you please, instead of having to force everything into a big, unwieldy class hierarchy. Does Modula-3 have any other mechanism which makes multiple inheritance superfluous? Btw., I'm not bashing the language, just curious about why it was designed this way. Ole-Hj. Kristensen ======================================================================= 27 === Date: 3 Mar 1995 04:05:48 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Re: Language Definition Some have claimed that READONLY is not needed because we have WITH. Where I would like to see READONLY is in *interfaces*, so I can export variables that won't be touched. I'll usually initialize such variables this way: READONLY x := NEW(T).init(...); You can't do this using WITH. I'm sure I've seen the words VAR (*READONLY*) in libm3 to document this sort of intention. Norman ======================================================================= 28 === Date: Mon, 6 Mar 1995 12:58:28 GMT From: jhagman@tportti.helsinki.fi (Jussi Hagman) Subject: Langage definitions Where could I find the language definitions for Modula-2, Modula-3 and Oberon? Thanks in advance, Jussi ======================================================================= 29 === Date: 6 Mar 1995 16:56:39 GMT From: chase@centerline.com (David Chase) Subject: Re: Why no multiple inheritance in Modula-3? ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes: > I have looked at the language definition of Modula-3, and I see that it only > allows single inheritance. Are there any reasons for this except for the obvi ous > complication in implementing it? There's non-obvious complications in defining its interactions with the rest of the language. Also, people tried programming in it with single inheritance, and ported code written using multiple inheritance, and decided that the lack of MI was a tolerable deficiency. That's not the same thing as "not a deficiency". Read on to find out (some reasons) why it was left out. The major difficulties come from the casting rules and the desire to avoid "accidents". If you draw the usual multiple- inheritance shared-base/super-class "diamond", A (super, base) B C D (sub, derived) you have to decide what is supposed to happen if B and C are both depending upon state (not interface, but state -- crucial difference here) stored in A. There's no reason to assume that B and C were written with any knowledge of each other, and (as the language stands now) one can use a superclass and know that the subclass controls all access to the state there -- that is, no surprises. Adding multiple inheritance (with sharing) changes this, unless you also add to the language some way to announce that "this base class can be shared" (as opposed to the C++ technique for distinguishing shared from unshared base classes, where the decision is made at the point of inheritance -- that is, in the derived class). There are two additional implementation interactions that may not be obvious. The first is the time and space complexity of narrow and typecase -- with single inheritance, the costs can be O(1) time/narrow, O(log #cases) time/typecase O(1) storage/type, O(#cases) storage/typecase For multiple inheritance, provided that sharing is associated with the base class and not its inheritance site, these figures can be maintained for "old" (single inheritance only) programs. However, this was not known at the time that the language was designed. The second implementation interactions occurs when you cast function pointers. Modula-3 lets you perform contravariant function casting -- that is, you may substitute an A -> B where a C -> D is expected, provided that A is a super(base) type of C and B is a sub(derived) type of D (this follows from an easy-to-verify rule -- if a C -> D is expected, then an A -> B will never be passed something that is not an A, and will always return something that is at least a D). There's no problem with the pointer to code itself, since all objects have the same representation and all types/classes are "rooted at" the same address. When you add multiple inheritance, this changes. Now, suppose that we pass an A -> B into a C -> D context. Suppose "A" is a strict (not equal) supertype of C at offset 16 from C's root (the fact that I know the offset will be constant for all objects passed is something that depends on my assumption that sharing is declared at the base type, not the inheritance site -- I may not know the value of the constant until runtime), and that D is a supertype of B occurring at offset 32. If you'll permit me to mix machine code and the lambda calculus, if the original function (from A -> B) was called "F", the the function that needs to be passed into the C -> D context will be this thunk: (lambda (x) (+ (F (- x 16) ) 32) ) The subtraction of 16 turns the representation of an A into the representation of a C, and the addition of 32 turns the representation of a B into the representation of a D. No run-time checks are necessary (the legality was statically verified) but something like runtime code generation IS required. Note that this was a function of one parameter -- more code means a messier thunk. Of course, for an "old" single inheritance program, this is not a problem, because all the offsets will be zero, and no thunk needs to be generated (this, however, may not be visible at compile time, given the interesting things that opaque inheritance can do to/for you). The need to generate thunks like this appears to be a sticking point for many people. I don't understand why, but I think that's partly because I've been playing with run-time code generation on and off for a while now, and because after a few years of working on a code generator, I decided that it's really all just data, anyhow. It just doesn't seem to be a problem to me. There are some architectures where the separation between code and data is more explicit, but I've managed to implement limited-but-sufficient-for-this-purpose thunks for split I/D machines (basic idea -- the thunks all do about the same thing but with different parameters. Create a cache of code+data pairs. Only write the code once, to fill the cache, but modify the data each time you need a new thunk). You can think of this as a special case of mixing interpreted code with binary code -- in the most general case, the "code" branches into the interpreter, and the "data" is a set of byte codes to modify the parameters and return values. And, if all else fails, do note that if something runs very slowly on a machine because of implementation difficulties, that is still much faster than not running at all because it was banned from the language. Do note that code using only single inheritance would not be slowed down by all this crazy thunk machinery. As if you cannot tell, I've been thinking about this for some time, and I haven't completely figured it out -- for instance, I strongly suspect that there could be some unforeseen glitches arising from the combination of opaque inheritance, multiple inheritance, and the usual changes made to programs in the course of normal development (suppose an interface is changed in a way that reveals a previously hidden supertype -- this could introduce ambiguities in existing code. I think this example motivates banning any automatic rules for resolving such an ambiguity, which in turn motivates adding a way to explicitly designate or rename a supertype). > Does Modula-3 have any other mechanism which makes multiple > inheritance superfluous? Some, but not all, applications of multiple inheritance can be implemented with opaque supertypes. The other approach is to contain the things that you need, and delegate manually. This isn't perfect. yours, David Chase ======================================================================= 30 === Date: 6 Mar 1995 21:59:53 GMT From: mastchen@des4 (Mastchenko Cyrille) Subject: Modula-3.x and Windows 95 I want to know if i can program in Modula-3 with thread, ... with windows'95, i have Visual C++ 2.1 and Watcom c++ 10.0 for compile it. MASTCHENKO Cyrille. email:mastchen@des8.u-strasbg.fr ======================================================================= 31 === Date: 7 Mar 1995 03:16:54 GMT From: mako@fnalv1.fnal.gov (Makoto Shimojima, Univ of Tsukuba/CDF) Subject: Re: Language Definition > Where I would like to see READONLY is in *interfaces*, so I can export > variables that won't be touched. I'll usually initialize such > variables this way: > READONLY x := NEW(T).init(...); > You can't do this using WITH. If you want to restrict access to a variable, write a method to handle it and hide the variable itself in the interface. If the inline pragma is properly implemented, the overhead should be minimum. mako ======================================================================= 32 === Date: 7 Mar 1995 23:25:59 GMT From: COBA Computing Center Subject: linked lists Does anyone know where I can find some info or see some example code explaining how to implement linked lists in objects? Thanx ======================================================================= 33 === Date: Wed, 8 Mar 1995 15:53:55 +0000 From: mhoward@darklord.demon.co.uk ("c:internetka9qspoolmail") Subject: Hardware & Operating Systems Some of you out there may have already been down this avenue... I am investigating possible tools/languages for developing large, distributed C/S applications. How portable is Modula-3? What platforms / operating systems is it available on? TIA /------------------------------------------------------------------------------ \ | Mark Howard mhoward@darklord.demon.co.uk | | Cheif Systems Architect | \------------------------------------------------------------------------------ / ======================================================================= 34 === Date: Wed, 8 Mar 1995 09:00:42 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: linked lists COBA Computing Center writes: > Does anyone know where I can find some info or see some example > code explaining how to implement linked lists in objects? > > Thanx Why implement it yourself ? Just use the 'List' generic type that is supplied with the SRC release. If you are just curious about how to implement linked lists, then take a look the the List.ig and List.mg source files. --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 35 === Date: 07 Mar 1995 16:34:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Problems building 3.5.1/boot-LINUX Building the library, to be exact. After hunting after an obscure bug in the dll tools-2.1.6 (a buffer [wrapup, in mkimage.c] was too small, overwriting critical variables) and telling the linker where to find lgcc, I'm now getting unresolved references. What's going on here?! I thought 3.5.1 was supposed to be bug-fixed ... but from the errors I already fixed, I'm beginning to doubt that. Script started on Tue Mar 7 16:08:15 1995 khms[tty1]:/opt/m3/m3# m3build ; exit--- building in LINUX --- -- mtex done -- ---------------------- building m3core ---------------------- --- building in LINUX --- mkdir -p jump; mkdir -p jumpas m3 -w1 -why -g -times -a libm3core.a -F/tmp/qk20931aaa seconds #times operation 2.18 2 inhaling library link info 1.40 1 getting derived timestamps 1.73 181 checking timestamps 0.65 177 checking old link info 0.01 1 merging new link info 0.99 2 garbage collection 1.69 other --------------------------------------------------- 8.63 TOTAL /opt/SRCm3/lib/m3/LINUX/buildShared -n libm3core -a 0x64400000 -j 0x4000 -g 0x2 000 -x 3 -y 5 -l " " /usr/dll/jump/as -o BasicCtypes.io BasicCtypes.is /usr/dll/jump/as -o CConvert.io CConvert.is /usr/dll/jump/as -o CConvert.mo CConvert.ms /usr/dll/jump/as -o Cerrno.io Cerrno.is /usr/dll/jump/as -o Convert.io Convert.is /usr/dll/jump/as -o Convert.mo Convert.ms /usr/dll/jump/as -o Csetjmp.io Csetjmp.is /usr/dll/jump/as -o Csignal.io Csignal.is /usr/dll/jump/as -o Cstdarg.io Cstdarg.is /usr/dll/jump/as -o Cstdarg.mo Cstdarg.ms /usr/dll/jump/as -o Cstddef.io Cstddef.is /usr/dll/jump/as -o Cstdio.io Cstdio.is /usr/dll/jump/as -o Cstdio.mo Cstdio.ms /usr/dll/jump/as -o Cstdlib.io Cstdlib.is /usr/dll/jump/as -o Cstring.io Cstring.is /usr/dll/jump/as -o Ctypes.io Ctypes.is /usr/dll/jump/as -o Date.io Date.is /usr/dll/jump/as -o DateLinux.mo DateLinux.ms /usr/dll/jump/as -o DragonInt.io DragonInt.is /usr/dll/jump/as -o DragonInt.mo DragonInt.ms /usr/dll/jump/as -o DragonT.io DragonT.is /usr/dll/jump/as -o DragonT.mo DragonT.ms /usr/dll/jump/as -o Extended.io Extended.is /usr/dll/jump/as -o Extended.mo Extended.ms /usr/dll/jump/as -o ExtendedFloat.io ExtendedFloat.is /usr/dll/jump/as -o ExtendedFloat.mo ExtendedFloat.ms /usr/dll/jump/as -o FPU.io FPU.is /usr/dll/jump/as -o FPU.mo FPU.ms /usr/dll/jump/as -o Fingerprint.io Fingerprint.is /usr/dll/jump/as -o Fingerprint.mo Fingerprint.ms /usr/dll/jump/as -o FloatMode.io FloatMode.is /usr/dll/jump/as -o FloatMode.mo FloatMode.ms /usr/dll/jump/as -o FmtTime.io FmtTime.is /usr/dll/jump/as -o FmtTime.mo FmtTime.ms /usr/dll/jump/as -o IEEESpecial.io IEEESpecial.is /usr/dll/jump/as -o IEEESpecial.mo IEEESpecial.ms /usr/dll/jump/as -o LongFloat.io LongFloat.is /usr/dll/jump/as -o LongFloat.mo LongFloat.ms /usr/dll/jump/as -o LongReal.io LongReal.is /usr/dll/jump/as -o LongReal.mo LongReal.ms /usr/dll/jump/as -o LongRealRep.io LongRealRep.is /usr/dll/jump/as -o M3toC.io M3toC.is /usr/dll/jump/as -o M3toC.mo M3toC.ms /usr/dll/jump/as -o Main.io Main.is /usr/dll/jump/as -o Poly.io Poly.is /usr/dll/jump/as -o Poly.mo Poly.ms /usr/dll/jump/as -o PolyBasis.io PolyBasis.is /usr/dll/jump/as -o PolyBasis.mo PolyBasis.ms /usr/dll/jump/as -o RT0.io RT0.is /usr/dll/jump/as -o RT0.mo RT0.ms /usr/dll/jump/as -o RT0u.io RT0u.is /usr/dll/jump/as -o RT0u.mo RT0u.ms /usr/dll/jump/as -o RTAllocator.io RTAllocator.is /usr/dll/jump/as -o RTAllocator.mo RTAllocator.ms /usr/dll/jump/as -o RTArgs.io RTArgs.is /usr/dll/jump/as -o RTArgs.mo RTArgs.ms /usr/dll/jump/as -o RTCollector.io RTCollector.is /usr/dll/jump/as -o RTCollector.mo RTCollector.ms /usr/dll/jump/as -o RTCollectorSRC.io RTCollectorSRC.is /usr/dll/jump/as -o RTExRep.io RTExRep.is /usr/dll/jump/as -o RTException.io RTException.is /usr/dll/jump/as -o RTException.mo RTException.ms /usr/dll/jump/as -o RTHeap.io RTHeap.is /usr/dll/jump/as -o RTHeap.mo RTHeap.ms /usr/dll/jump/as -o RTHeapDebug.io RTHeapDebug.is /usr/dll/jump/as -o RTHeapDebug.mo RTHeapDebug.ms /usr/dll/jump/as -o RTHeapDep.io RTHeapDep.is /usr/dll/jump/as -o RTHeapDep.mo RTHeapDep.ms /usr/dll/jump/as -o RTHeapEvent.io RTHeapEvent.is /usr/dll/jump/as -o RTHeapInfo.io RTHeapInfo.is /usr/dll/jump/as -o RTHeapInfo.mo RTHeapInfo.ms /usr/dll/jump/as -o RTHeapMap.io RTHeapMap.is /usr/dll/jump/as -o RTHeapMap.mo RTHeapMap.ms /usr/dll/jump/as -o RTHeapRep.io RTHeapRep.is /usr/dll/jump/as -o RTHeapRep.mo RTHeapRep.ms /usr/dll/jump/as -o RTHeapStats.io RTHeapStats.is /usr/dll/jump/as -o RTHeapStats.mo RTHeapStats.ms /usr/dll/jump/as -o RTHooks.io RTHooks.is /usr/dll/jump/as -o RTHooks.mo RTHooks.ms /usr/dll/jump/as -o RTIO.io RTIO.is /usr/dll/jump/as -o RTIO.mo RTIO.ms /usr/dll/jump/as -o RTLinker.io RTLinker.is /usr/dll/jump/as -o RTLinker.mo RTLinker.ms /usr/dll/jump/as -o RTMachine.io RTMachine.is /usr/dll/jump/as -o RTMapOp.io RTMapOp.is /usr/dll/jump/as -o RTMapOp.mo RTMapOp.ms /usr/dll/jump/as -o RTMisc.io RTMisc.is /usr/dll/jump/as -o RTMisc.mo RTMisc.ms /usr/dll/jump/as -o RTModule.io RTModule.is /usr/dll/jump/as -o RTModule.mo RTModule.ms /usr/dll/jump/as -o RTOS.io RTOS.is /usr/dll/jump/as -o RTOS.mo RTOS.ms /usr/dll/jump/as -o RTPacking.io RTPacking.is /usr/dll/jump/as -o RTPacking.mo RTPacking.ms /usr/dll/jump/as -o RTParams.io RTParams.is /usr/dll/jump/as -o RTParams.mo RTParams.ms /usr/dll/jump/as -o RTPerfTool.io RTPerfTool.is /usr/dll/jump/as -o RTPerfTool.mo RTPerfTool.ms /usr/dll/jump/as -o RTProcedure.io RTProcedure.is /usr/dll/jump/as -o RTProcedure.mo RTProcedure.ms /usr/dll/jump/as -o RTProcedureSRC.io RTProcedureSRC.is /usr/dll/jump/as -o RTProcess.io RTProcess.is /usr/dll/jump/as -o RTProcess.mo RTProcess.ms /usr/dll/jump/as -o RTSignal.io RTSignal.is /usr/dll/jump/as -o RTSignal.mo RTSignal.ms /usr/dll/jump/as -o RTThread.io RTThread.is /usr/dll/jump/as -o RTThread.mo RTThread.ms /usr/dll/jump/as -o RTThreadInit.io RTThreadInit.is /usr/dll/jump/as -o RTThreadStk.mo RTThreadStk.ms /usr/dll/jump/as -o RTTipe.io RTTipe.is /usr/dll/jump/as -o RTTipe.mo RTTipe.ms /usr/dll/jump/as -o RTType.io RTType.is /usr/dll/jump/as -o RTType.mo RTType.ms /usr/dll/jump/as -o RTTypeFP.io RTTypeFP.is /usr/dll/jump/as -o RTTypeFP.mo RTTypeFP.ms /usr/dll/jump/as -o RTTypeMap.io RTTypeMap.is /usr/dll/jump/as -o RTTypeMap.mo RTTypeMap.ms /usr/dll/jump/as -o RTTypeSRC.io RTTypeSRC.is /usr/dll/jump/as -o RTWeakRef.io RTWeakRef.is /usr/dll/jump/as -o RTutils.io RTutils.is /usr/dll/jump/as -o RTutils.mo RTutils.ms /usr/dll/jump/as -o Real.io Real.is /usr/dll/jump/as -o Real.mo Real.ms /usr/dll/jump/as -o RealFloat.io RealFloat.is /usr/dll/jump/as -o RealFloat.mo RealFloat.ms /usr/dll/jump/as -o RealRep.io RealRep.is /usr/dll/jump/as -o Scheduler.io Scheduler.is /usr/dll/jump/as -o SchedulerPosix.io SchedulerPosix.is /usr/dll/jump/as -o Text.io Text.is /usr/dll/jump/as -o Text.mo Text.ms /usr/dll/jump/as -o TextConv.io TextConv.is /usr/dll/jump/as -o TextConv.mo TextConv.ms /usr/dll/jump/as -o TextF.io TextF.is /usr/dll/jump/as -o Thread.io Thread.is /usr/dll/jump/as -o ThreadEvent.io ThreadEvent.is /usr/dll/jump/as -o ThreadF.io ThreadF.is /usr/dll/jump/as -o ThreadPosix.mo ThreadPosix.ms /usr/dll/jump/as -o Tick.io Tick.is /usr/dll/jump/as -o TickPortable.mo TickPortable.ms /usr/dll/jump/as -o Time.io Time.is /usr/dll/jump/as -o TimePosix.io TimePosix.is /usr/dll/jump/as -o TimePosix.mo TimePosix.ms /usr/dll/jump/as -o Udir.io Udir.is /usr/dll/jump/as -o Uerror.io Uerror.is /usr/dll/jump/as -o Uerror.mo Uerror.ms /usr/dll/jump/as -o Uexec.io Uexec.is /usr/dll/jump/as -o Ugrp.io Ugrp.is /usr/dll/jump/as -o Uin.io Uin.is /usr/dll/jump/as -o Uin.mo Uin.ms /usr/dll/jump/as -o Uipc.io Uipc.is /usr/dll/jump/as -o Umman.io Umman.is /usr/dll/jump/as -o Umsg.io Umsg.is /usr/dll/jump/as -o Umsg.mo Umsg.ms /usr/dll/jump/as -o Unetdb.io Unetdb.is /usr/dll/jump/as -o Unetdb.mo Unetdb.ms /usr/dll/jump/as -o Unix.io Unix.is /usr/dll/jump/as -o UnsafeHash.mo UnsafeHash.ms /usr/dll/jump/as -o Uprocess.io Uprocess.is /usr/dll/jump/as -o Upwd.io Upwd.is /usr/dll/jump/as -o Uresource.io Uresource.is /usr/dll/jump/as -o Usem.io Usem.is /usr/dll/jump/as -o Ushm.io Ushm.is /usr/dll/jump/as -o Usignal.io Usignal.is /usr/dll/jump/as -o Usignal.mo Usignal.ms /usr/dll/jump/as -o Usocket.io Usocket.is /usr/dll/jump/as -o Ustat.io Ustat.is /usr/dll/jump/as -o Usyslog.io Usyslog.is /usr/dll/jump/as -o Utime.io Utime.is /usr/dll/jump/as -o Utypes.io Utypes.is /usr/dll/jump/as -o Utypes.mo Utypes.ms /usr/dll/jump/as -o Uugid.io Uugid.is /usr/dll/jump/as -o Uuio.io Uuio.is /usr/dll/jump/as -o Uutmp.io Uutmp.is /usr/dll/jump/as -o WeakRef.io WeakRef.is /usr/dll/jump/as -o WeakRef.mo WeakRef.ms /usr/dll/jump/as -o Word.io Word.is /usr/dll/jump/as -o Word.mo Word.ms /usr/dll/jump/as -o cca01290.o cca01290.s /usr/dll/jump/as -o cca01296.o cca01296.s /usr/dll/jump/as -o cca01546.o cca01546.s /usr/dll/jump/as -o cca01701.o cca01701.s getvars v2.16 Reading jump.log file from /opt/m3/m3/m3core/LINUX/jump getfuncs v2.16 Reading jump.log file from /opt/m3/m3/m3core/LINUX/jump /usr/dll/jump/as -o BasicCtypes.io BasicCtypes.is /usr/dll/jump/as -o CConvert.io CConvert.is /usr/dll/jump/as -o CConvert.mo CConvert.ms /usr/dll/jump/as -o Cerrno.io Cerrno.is /usr/dll/jump/as -o Convert.io Convert.is /usr/dll/jump/as -o Convert.mo Convert.ms /usr/dll/jump/as -o Csetjmp.io Csetjmp.is /usr/dll/jump/as -o Csignal.io Csignal.is /usr/dll/jump/as -o Cstdarg.io Cstdarg.is /usr/dll/jump/as -o Cstdarg.mo Cstdarg.ms /usr/dll/jump/as -o Cstddef.io Cstddef.is /usr/dll/jump/as -o Cstdio.io Cstdio.is /usr/dll/jump/as -o Cstdio.mo Cstdio.ms /usr/dll/jump/as -o Cstdlib.io Cstdlib.is /usr/dll/jump/as -o Cstring.io Cstring.is /usr/dll/jump/as -o Ctypes.io Ctypes.is /usr/dll/jump/as -o Date.io Date.is /usr/dll/jump/as -o DateLinux.mo DateLinux.ms /usr/dll/jump/as -o DragonInt.io DragonInt.is /usr/dll/jump/as -o DragonInt.mo DragonInt.ms /usr/dll/jump/as -o DragonT.io DragonT.is /usr/dll/jump/as -o DragonT.mo DragonT.ms /usr/dll/jump/as -o Extended.io Extended.is /usr/dll/jump/as -o Extended.mo Extended.ms /usr/dll/jump/as -o ExtendedFloat.io ExtendedFloat.is /usr/dll/jump/as -o ExtendedFloat.mo ExtendedFloat.ms /usr/dll/jump/as -o FPU.io FPU.is /usr/dll/jump/as -o FPU.mo FPU.ms /usr/dll/jump/as -o Fingerprint.io Fingerprint.is /usr/dll/jump/as -o Fingerprint.mo Fingerprint.ms /usr/dll/jump/as -o FloatMode.io FloatMode.is /usr/dll/jump/as -o FloatMode.mo FloatMode.ms /usr/dll/jump/as -o FmtTime.io FmtTime.is /usr/dll/jump/as -o FmtTime.mo FmtTime.ms /usr/dll/jump/as -o IEEESpecial.io IEEESpecial.is /usr/dll/jump/as -o IEEESpecial.mo IEEESpecial.ms /usr/dll/jump/as -o LongFloat.io LongFloat.is /usr/dll/jump/as -o LongFloat.mo LongFloat.ms /usr/dll/jump/as -o LongReal.io LongReal.is /usr/dll/jump/as -o LongReal.mo LongReal.ms /usr/dll/jump/as -o LongRealRep.io LongRealRep.is /usr/dll/jump/as -o M3toC.io M3toC.is /usr/dll/jump/as -o M3toC.mo M3toC.ms /usr/dll/jump/as -o Main.io Main.is /usr/dll/jump/as -o Poly.io Poly.is /usr/dll/jump/as -o Poly.mo Poly.ms /usr/dll/jump/as -o PolyBasis.io PolyBasis.is /usr/dll/jump/as -o PolyBasis.mo PolyBasis.ms /usr/dll/jump/as -o RT0.io RT0.is /usr/dll/jump/as -o RT0.mo RT0.ms /usr/dll/jump/as -o RT0u.io RT0u.is /usr/dll/jump/as -o RT0u.mo RT0u.ms /usr/dll/jump/as -o RTAllocator.io RTAllocator.is /usr/dll/jump/as -o RTAllocator.mo RTAllocator.ms /usr/dll/jump/as -o RTArgs.io RTArgs.is /usr/dll/jump/as -o RTArgs.mo RTArgs.ms /usr/dll/jump/as -o RTCollector.io RTCollector.is /usr/dll/jump/as -o RTCollector.mo RTCollector.ms /usr/dll/jump/as -o RTCollectorSRC.io RTCollectorSRC.is /usr/dll/jump/as -o RTExRep.io RTExRep.is /usr/dll/jump/as -o RTException.io RTException.is /usr/dll/jump/as -o RTException.mo RTException.ms /usr/dll/jump/as -o RTHeap.io RTHeap.is /usr/dll/jump/as -o RTHeap.mo RTHeap.ms /usr/dll/jump/as -o RTHeapDebug.io RTHeapDebug.is /usr/dll/jump/as -o RTHeapDebug.mo RTHeapDebug.ms /usr/dll/jump/as -o RTHeapDep.io RTHeapDep.is /usr/dll/jump/as -o RTHeapDep.mo RTHeapDep.ms /usr/dll/jump/as -o RTHeapEvent.io RTHeapEvent.is /usr/dll/jump/as -o RTHeapInfo.io RTHeapInfo.is /usr/dll/jump/as -o RTHeapInfo.mo RTHeapInfo.ms /usr/dll/jump/as -o RTHeapMap.io RTHeapMap.is /usr/dll/jump/as -o RTHeapMap.mo RTHeapMap.ms /usr/dll/jump/as -o RTHeapRep.io RTHeapRep.is /usr/dll/jump/as -o RTHeapRep.mo RTHeapRep.ms /usr/dll/jump/as -o RTHeapStats.io RTHeapStats.is /usr/dll/jump/as -o RTHeapStats.mo RTHeapStats.ms /usr/dll/jump/as -o RTHooks.io RTHooks.is /usr/dll/jump/as -o RTHooks.mo RTHooks.ms /usr/dll/jump/as -o RTIO.io RTIO.is /usr/dll/jump/as -o RTIO.mo RTIO.ms /usr/dll/jump/as -o RTLinker.io RTLinker.is /usr/dll/jump/as -o RTLinker.mo RTLinker.ms /usr/dll/jump/as -o RTMachine.io RTMachine.is /usr/dll/jump/as -o RTMapOp.io RTMapOp.is /usr/dll/jump/as -o RTMapOp.mo RTMapOp.ms /usr/dll/jump/as -o RTMisc.io RTMisc.is /usr/dll/jump/as -o RTMisc.mo RTMisc.ms /usr/dll/jump/as -o RTModule.io RTModule.is /usr/dll/jump/as -o RTModule.mo RTModule.ms /usr/dll/jump/as -o RTOS.io RTOS.is /usr/dll/jump/as -o RTOS.mo RTOS.ms /usr/dll/jump/as -o RTPacking.io RTPacking.is /usr/dll/jump/as -o RTPacking.mo RTPacking.ms /usr/dll/jump/as -o RTParams.io RTParams.is /usr/dll/jump/as -o RTParams.mo RTParams.ms /usr/dll/jump/as -o RTPerfTool.io RTPerfTool.is /usr/dll/jump/as -o RTPerfTool.mo RTPerfTool.ms /usr/dll/jump/as -o RTProcedure.io RTProcedure.is /usr/dll/jump/as -o RTProcedure.mo RTProcedure.ms /usr/dll/jump/as -o RTProcedureSRC.io RTProcedureSRC.is /usr/dll/jump/as -o RTProcess.io RTProcess.is /usr/dll/jump/as -o RTProcess.mo RTProcess.ms /usr/dll/jump/as -o RTSignal.io RTSignal.is /usr/dll/jump/as -o RTSignal.mo RTSignal.ms /usr/dll/jump/as -o RTThread.io RTThread.is /usr/dll/jump/as -o RTThread.mo RTThread.ms /usr/dll/jump/as -o RTThreadInit.io RTThreadInit.is /usr/dll/jump/as -o RTThreadStk.mo RTThreadStk.ms /usr/dll/jump/as -o RTTipe.io RTTipe.is /usr/dll/jump/as -o RTTipe.mo RTTipe.ms /usr/dll/jump/as -o RTType.io RTType.is /usr/dll/jump/as -o RTType.mo RTType.ms /usr/dll/jump/as -o RTTypeFP.io RTTypeFP.is /usr/dll/jump/as -o RTTypeFP.mo RTTypeFP.ms /usr/dll/jump/as -o RTTypeMap.io RTTypeMap.is /usr/dll/jump/as -o RTTypeMap.mo RTTypeMap.ms /usr/dll/jump/as -o RTTypeSRC.io RTTypeSRC.is /usr/dll/jump/as -o RTWeakRef.io RTWeakRef.is /usr/dll/jump/as -o RTutils.io RTutils.is /usr/dll/jump/as -o RTutils.mo RTutils.ms /usr/dll/jump/as -o Real.io Real.is /usr/dll/jump/as -o Real.mo Real.ms /usr/dll/jump/as -o RealFloat.io RealFloat.is /usr/dll/jump/as -o RealFloat.mo RealFloat.ms /usr/dll/jump/as -o RealRep.io RealRep.is /usr/dll/jump/as -o Scheduler.io Scheduler.is /usr/dll/jump/as -o SchedulerPosix.io SchedulerPosix.is /usr/dll/jump/as -o Text.io Text.is /usr/dll/jump/as -o Text.mo Text.ms /usr/dll/jump/as -o TextConv.io TextConv.is /usr/dll/jump/as -o TextConv.mo TextConv.ms /usr/dll/jump/as -o TextF.io TextF.is /usr/dll/jump/as -o Thread.io Thread.is /usr/dll/jump/as -o ThreadEvent.io ThreadEvent.is /usr/dll/jump/as -o ThreadF.io ThreadF.is /usr/dll/jump/as -o ThreadPosix.mo ThreadPosix.ms /usr/dll/jump/as -o Tick.io Tick.is /usr/dll/jump/as -o TickPortable.mo TickPortable.ms /usr/dll/jump/as -o Time.io Time.is /usr/dll/jump/as -o TimePosix.io TimePosix.is /usr/dll/jump/as -o TimePosix.mo TimePosix.ms /usr/dll/jump/as -o Udir.io Udir.is /usr/dll/jump/as -o Uerror.io Uerror.is /usr/dll/jump/as -o Uerror.mo Uerror.ms /usr/dll/jump/as -o Uexec.io Uexec.is /usr/dll/jump/as -o Ugrp.io Ugrp.is /usr/dll/jump/as -o Uin.io Uin.is /usr/dll/jump/as -o Uin.mo Uin.ms /usr/dll/jump/as -o Uipc.io Uipc.is /usr/dll/jump/as -o Umman.io Umman.is /usr/dll/jump/as -o Umsg.io Umsg.is /usr/dll/jump/as -o Umsg.mo Umsg.ms /usr/dll/jump/as -o Unetdb.io Unetdb.is /usr/dll/jump/as -o Unetdb.mo Unetdb.ms /usr/dll/jump/as -o Unix.io Unix.is /usr/dll/jump/as -o UnsafeHash.mo UnsafeHash.ms /usr/dll/jump/as -o Uprocess.io Uprocess.is /usr/dll/jump/as -o Upwd.io Upwd.is /usr/dll/jump/as -o Uresource.io Uresource.is /usr/dll/jump/as -o Usem.io Usem.is /usr/dll/jump/as -o Ushm.io Ushm.is /usr/dll/jump/as -o Usignal.io Usignal.is /usr/dll/jump/as -o Usignal.mo Usignal.ms /usr/dll/jump/as -o Usocket.io Usocket.is /usr/dll/jump/as -o Ustat.io Ustat.is /usr/dll/jump/as -o Usyslog.io Usyslog.is /usr/dll/jump/as -o Utime.io Utime.is /usr/dll/jump/as -o Utypes.io Utypes.is /usr/dll/jump/as -o Utypes.mo Utypes.ms /usr/dll/jump/as -o Uugid.io Uugid.is /usr/dll/jump/as -o Uuio.io Uuio.is /usr/dll/jump/as -o Uutmp.io Uutmp.is /usr/dll/jump/as -o WeakRef.io WeakRef.is /usr/dll/jump/as -o WeakRef.mo WeakRef.ms /usr/dll/jump/as -o Word.io Word.is /usr/dll/jump/as -o Word.mo Word.ms /usr/dll/jump/as -o cca01290.o cca01290.s /usr/dll/jump/as -o cca01296.o cca01296.s /usr/dll/jump/as -o cca01546.o cca01546.s /usr/dll/jump/as -o cca01701.o cca01701.s getsize v2.16 /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_BasicCtypes.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_CConvert.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_CConvert.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cerrno.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Convert.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Convert.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Csetjmp.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Csignal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdarg.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Cstdarg.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstddef.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdio.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Cstdio.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstdlib.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Cstring.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ctypes.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Date.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DateLinux.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonInt.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DragonInt.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonT.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DragonT.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Extended.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Extended.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ExtendedFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_ExtendedFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FPU.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FPU.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Fingerprint.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Fingerprint.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FloatMode.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FloatMode.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_FmtTime.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_FmtTime.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_IEEESpecial.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_IEEESpecial.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_LongFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongReal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_LongReal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_LongRealRep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_M3toC.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_M3toC.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Main.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Poly.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Poly.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_PolyBasis.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_PolyBasis.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RT0.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RT0.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RT0u.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RT0u.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTAllocator.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTAllocator.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTArgs.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTArgs.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTCollector.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTCollector.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTCollectorSRC.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTExRep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTException.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTException.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapDebug.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapDebug.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapDep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapDep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapEvent.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapInfo.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapInfo.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapMap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapMap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapRep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapRep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHeapStats.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHeapStats.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTHooks.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTHooks.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTIO.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTIO.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTLinker.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTLinker.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMachine.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMapOp.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTMapOp.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTMisc.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTMisc.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTModule.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTModule.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTOS.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTOS.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTPacking.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTPacking.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTParams.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTParams.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTPerfTool.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTPerfTool.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcedure.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTProcedure.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcedureSRC.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTProcess.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTProcess.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTSignal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTSignal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTThread.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTThread.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTThreadInit.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTThreadStk.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTipe.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTipe.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTType.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTType.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeFP.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTypeFP.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeMap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTTypeMap.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTTypeSRC.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTWeakRef.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RTutils.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RTutils.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Real.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Real.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RealFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_RealFloat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_RealRep.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Scheduler.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_SchedulerPosix.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Text.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Text.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TextConv.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TextConv.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TextF.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Thread.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ThreadEvent.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_ThreadF.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_ThreadPosix.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Tick.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TickPortable.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Time.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_TimePosix.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_TimePosix.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Udir.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uerror.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Uerror.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uexec.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ugrp.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uin.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Uin.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uipc.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Umman.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Umsg.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Umsg.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Unetdb.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Unetdb.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Unix.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_UnsafeHash.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uprocess.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Upwd.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uresource.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usem.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ushm.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usignal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Usignal.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usocket.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Ustat.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Usyslog.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Utime.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Utypes.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Utypes.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uugid.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uuio.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Uutmp.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_WeakRef.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_WeakRef.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_Word.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_Word.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__tables_built.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__LoBits.s /opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__LoBits.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__HiBits.s /opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__HiBits.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_M3_BUILTIN.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__ThreadF__myId.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__RT0u__inCritical.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__RTThread__handlerStack.s /usr/dll/bin/mkimage -f -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 - - jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc mkimage v2.16 Warning - non-absolute pathname specified for library Reading configuration files from /opt/m3/m3/m3core/LINUX/jump Recording new library parameters. executing:ld -x -Ttext 64400000 -o libm3core.so.3.5 /opt/m3/m3/m3core/LINUX/jum p/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__cutoffAdju st.0 referenced from text segment /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__fixup.1 re ferenced from text segment /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__fixup.1 re ferenced from text segment /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _DragonT__F__cutoffAdju st.0 referenced from text segment /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _M_RTCollector_LINE_176 9.0 referenced from text segment /opt/m3/m3/m3core/LINUX/jump/__jump.o: Undefined symbol _M_ThreadPosix_LINE_331 .0 referenced from text segment system: No such file or directory /usr/dll/bin/mkimage: error running 'ld -x -Ttext 64400000 -o libm3core.so.3.5 /opt/m3/m3/m3core/LINUX/jump/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i48 6-linux/2.5.8 -lgcc -lc' /usr/dll/bin/mkstubs -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -- l ibm3core mkstubs v2.16 Warning - non-absolute pathname specified for library Reading configuration files from /opt/m3/m3/m3core/LINUX/jump libm3core.sa: ___libm3core_3_500, cca01290, cca01296, cca01701, BasicCtypes, CC onvert, Cerrno, Convert, Csetjmp, Csignal, Cstdarg, Cstddef, Cstdio, Cstdlib, C string, Ctypes, Date, DateLinux, DragonInt, DragonT, Extended, ExtendedFloat, F PU, Fingerprint, FloatMode, FmtTime, IEEESpecial, LongFloat, LongReal, LongRealRep, M3toC, Main , Poly, PolyBasis, RT0, RT0u, RTAllocator, RTArgs, RTCollector, RTCollectorSRC, RTExRep, RTException, RTHeap, RTHeapDebug, RTHeapDep, RTHeapEvent, RTHeapInfo, RTHeapMap, RTHe apRep, RTHeapStats, RTHooks, RTIO, RTLinker, RTMachine, RTMapOp, RTMisc, RTModu le, RTOS, RTPacking, RTParams, RTPerfTool, RTProcedure, RTProcedureSRC, RTProce ss, RTSignal, RTThread, RTThreadInit, RTThreadStk, RTTipe, RTType, RTTypeFP, RT TypeMap, RTTypeS RC, RTWeakRef, RTutils, Real, RealFloat, RealRep, Scheduler, SchedulerPosix, Te xt, TextConv, TextF, Thread, ThreadEvent, ThreadF, ThreadPosix, Tick, TickPorta ble, Time, TimePosix, Udir, Uerror, Uexec, Ugrp, Uin, Uipc, Umman, Umsg, Unetdb , Unix, UnsafeHa sh, Uprocess, Upwd, Uresource, Usem, Ushm, Usignal, Usocket, Ustat, Usyslog, Ut ime, Utypes, Uugid, Uuio, Uutmp, WeakRef, Word, cca01546, _LoBits, _HiBits, seq uencing, done verify v2.16 (experimental) jumpkit: Unable to open libm3core.so.3.5 *** error code 1 "/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: command execute fail ed *** call stack *** "/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: call to built-in exe c "/opt/m3/m3/m3core/src/m3makefile", line 960: call to procedure after_library_h ooks "/opt/SRCm3/lib/m3/pkg/m3build/templates/COMMON", line 1: call to procedure lib rary "/opt/m3/m3/m3core/src/m3makefile", line 42: call to procedure Library m3build: /opt/SRCm3/bin/quake failed (status = 256) *** error code 255 "/opt/m3/m3/src/m3makefile", line 41: command execute failed *** call stack *** "/opt/m3/m3/src/m3makefile", line 41: call to built-in exec "/opt/m3/m3/src/m3makefile", line 63: call to procedure BuildChunk m3build: /opt/SRCm3/bin/quake failed (status = 256) exit Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 36 === Date: Wed, 8 Mar 1995 16:35:16 +0000 From: mhoward@darklord.demon.co.uk ("c:internetka9qspoolmail") Subject: Platforms Does anyone have any idea about the variety of platforms / operating system a standard implementation of modula-3 is available for? TIA Mark ======================================================================= 37 === Date: 8 Mar 1995 12:42:36 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Problems building 3.5.1/boot-LINUX In article <5hRGNa1EcsB@khms.westfalen.de>, Kai Henningsen wrote: >Building the library, to be exact. > >After hunting after an obscure bug in the dll tools-2.1.6 (a buffer >[wrapup, in mkimage.c] was too small, overwriting critical variables) and >telling the linker where to find lgcc, I'm now getting unresolved >references. > >What's going on here?! I thought 3.5.1 was supposed to be bug-fixed ... >but from the errors I already fixed, I'm beginning to doubt that. It is bugfixed (well, modulo Linux changing underneath everyone). There are just a lot of bugs in the DLL tools :-) (well, not actually bugs - fixed-size buffers which tend to overflow). You can get patches that worked for me from http://www.cl.cam.ac.uk/m3doc/linux/archive/3.5.1/index.html [trace deleted] Richard. -- `There comes a time when you look into the mirror and you realise that what you see is all that you will ever be. And then you accept it. Or you kill yourself. Or you stop looking in mirrors.' The University of Cambridge can't have these opinions even if it wants them. ======================================================================= 38 === Date: Tue, 7 Mar 1995 17:40:19 GMT From: rodney@bcsaic.boeing.com (Rodney M. Bates) Subject: Re: Language Definition I hate to even bring it up, but while language changes are being proposed, here is one I wish for. I want to be able to write: TYPE Colors = { Plum , Red , Orange , Yellow , Green , Turquiose , Blue , Purple } ; TYPE ColorSet = SET OF Colors ; CONST Primaries = ColorSet { Red , Green , Blue } ; CONST InfraReds = ColorSet { Plum } ; CONST InfraGreens = ColorSet { Orange , Yellow } ; CONST InfraBlues = ColorSet { Turquiose } ; CONST UltraBlues = ColorSet { Purple } ; And elsewhere: IF C IN InfraReds THEN ... And elsewhere (this is where the language change is needed): CASE C OF | Primaries => ... | InfraReds => ... | InfraGreens => ... | InfraBlues => ... | UltraBlues => ... END I want to do this so that later, I can, for example, add Periwinkle to Colors and to UltraBlues without having to locate all the CASE statements in the world which might be affected. I can do this now with IF statments, but not with CASE statements. I don't believe the CASE statement is just syntactic sugar for: IF C IN Primaries THEN ... ELSIF C IN InfraReds THEN ... ELSIF C IN InfraGreens THEN ... ELSIF C IN InfraBlues THEN ... ELSIF C IN UltraBlues THEN ... END If it is, then _all_ CASE statements are just syntactic sugar. The change would be to allow a case label to be a constant expression of type SET OF T and whose elements are members of T, where T is the type of the expression Expr in CASE Expr ... . Rodney Bates ======================================================================= 39 === Date: Wed, 8 Mar 1995 16:16:09 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: re: postability of M3 and suitability for C/S apps mhoward@darklord.demon.co.uk writes: > Some of you out there may have already been down this avenue... > > I am investigating possible tools/languages for developing large, > distributed C/S applications. > > How portable is Modula-3? What platforms / operating systems is it > available on? > > TIA > > /--------------------------------------------------------------------------- ---\ > | Mark Howard mhoward@darklord.demon.co. uk | > | Cheif Systems Architect | > \--------------------------------------------------------------------------- ---/ > I'd definitely encourage you to use Modula-3 for large distributed, client/serv er systems. I think you'd be hard pressed to find a better programming system. I'v e developed distributed applications in C/C++ and Modula-3, much prefer the latte r. I waged a long and finally successfull compaign to get Modula-3 adopted as the programming language for our group. No one here regrets it, and very enthusiast ic users of it now. We've develop a number of distributed applications in our grou p with Modula-3 (a naming service, a transaction monitor, an event management sys tem, etc.) On to your specific questions. I believe that the 3.5.1 release runs on the fol lowing platforms: SunOS 4.1, Solaris 2.X, Ultrix, OSF/1, HPUX, AIX, SGI, and Windows-N T. When Windows-95 becomes available, it will run on that platform as well. Modula-3 applications tend to be very portable for a number of reasons. First, the standard libraries provide an excellent set of interfaces that abstract common OS functionality. Secondly, it is much harder to write machine dependent code in M odula-3. Not impossible, but you must explicitly document it by putting it in an "unsafe " module. So in general, Modula-3 applications can be written at a higher level o f abstraction than your typical C/C++ application. Hope this helps ! Feel free to contact me if you have any more questions ! --geoff Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 40 === Date: 09 Mar 1995 02:16:31 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: OpenGL (was Re: WinNT questions) >>>>> On 6 Mar 1995 11:40:59 GMT, Quentin Stafford-Fraser >>>>> said: Quentin> bm@shadow.cs.columbia.edu (Blair MacIntyre) wrote: >> So, if anyone has any hints as to when netobjs will be supported, >> you'll then know when we'll be making OpenGL i3's for NT. :-) Quentin> ..which I presume is equivalent to asking whether anybody is Quentin> working on porting the TCP/IP stuff to Winsock? Yep, I think that they are equivalent. As for my OpenGL .i3's, they are online on our home page. (http://www.cs.columbia.edu/graphics/modula3/m3browser.html) Any code I want to make available will appear under that page, which is automatically generated by the m3browser program included in the M3 distribution (cool program!) They are only slightly tested, so let me know if you find any problems. Blair -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 41 === Date: 6 Mar 1995 11:40:59 GMT From: Quentin Stafford-Fraser Subject: Re: WinNT questions bm@shadow.cs.columbia.edu (Blair MacIntyre) wrote: > So, if anyone has any hints as to when netobjs will be supported, > you'll then know when we'll be making OpenGL i3's for NT. :-) ..which I presume is equivalent to asking whether anybody is working on porting the TCP/IP stuff to Winsock? (That was two questions :-) ) Quentin ======================================================================= 42 === Date: 9 Mar 1995 06:52:44 GMT From: taj@vanbc.wimsey.com (Taj Khattra) Subject: try-finally-except Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead of a single TRY-FINALLY-EXCEPT statement ? Is the following case the main reason why ? TRY RAISE e; FINALLY IF (foobar) RAISE e; EXCEPT e => (* this may or may not be executed *) END I am trying to write a Modula-3 like exception handling mechanism for ANSI C (based on Eric Robert's package) and am trying to justify to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead of just TRY-FINALLY-EXCEPT. Thanks. --taj ======================================================================= 43 === Date: Thu, 9 Mar 1995 13:06:01 GMT From: faegri@dcs.glasgow.ac.uk (Tor Erlend Faegri) Subject: netobjd problems (SRC M3 3.3) I'm experiencing some problems using the netobj-daemon, netobjd(1). As far as I managed to find out, there is no option to the netobjd(1) to make it say what's going on, and what it's object-tables contains. Because of this, (and of course the fact that my program doesn't work), I'm asking this group for hints as to how I should proceed. My program is currently very simple, I'll outline it below: The type NSR.T is a subtype of NetObj.T, and is specified like this in a file NSR.i3: TYPE T = NetObj.T OBJECT METHODS init(n : TEXT) RAISES {NetObj.Error, Thread.Alerted}; alive() : TEXT RAISES {NetObj.Error, Thread.Alerted}; END; The implementation of the type, in file NSR.m3 looks like this: TYPE NSR_T = T OBJECT name : TEXT; OVERRIDES init := Init; alive := Alive; END; PROCEDURE Init(self : NSR_T; n : TEXT) RAISES {NetObj.Error, Thread.Alerted} = (* Documentation: Sets the name of the replica. *) BEGIN self.name := n; END Init; ... ... In my main module, I use NSR.T objects in the following way: VAR aReplica : NSR.T := NIL; ... (* Register an instance of a replica in node's netobjd object tables *) NetObj.Export("replica", NEW(NSR.T), NetObj.Locate(node)); (* node is a name of a machine running netobjd(1) *) ... ... (* Retrieve a reference to the replica from node's netobjd object tables *) aReplica := NetObj.Import("replica", NetObj.Locate(node)); ... (* Try to invoce a method on the replica *) IF aReplica # NIL THEN aReplica.init("replica_xx"); END; During the execution of the last statement, the method invocation, I get the following runtime error: "attempted invocation of undefined method" Because I got no complaints during compilation, I'm suspecting either that the surrugate hasn't been correctly set up on the local machine, or that the netobjd doesn't send me the right object, even though it obviously sends me something. (It might be the case I'm not using it correctly either of course ...). Could someone provide me with some hints? BTW: my configuration: Sun SPARC running SunOS 4.1.3, DEC SRC M3 rel. 3.3. All the tests in ../netobj/netobj/tests runs fine. --- -*******************************************************************- -* Tor E. Faegri, M.Sc. student, University of Glasgow, Scotland *- -* URL: http://www.dcs.gla.ac.uk/~faegri *- -* E-mail: faegri@dcs.gla.ac.uk *- -*******************************************************************- ======================================================================= 44 === Date: 9 Mar 1995 15:39:11 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: netobjd problems (SRC M3 3.3) In article , faegri@dcs.glasgow.ac.uk (Tor Erlend Fae gri) writes: > > During the execution of the last statement, the method invocation, I get the > following runtime error: > > "attempted invocation of undefined method" Because you exported an NSR.T which has no procedures bound to its methods? You'll probably be happier if you call NetObj.Export with NEW(NSR_T). - Bill Kalsow ======================================================================= 45 === Date: 10 Mar 1995 00:04:22 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Re: Netobjects: ASSERT failure in ThreadPosix >>>>> On 4 Mar 1995 13:20:05 GMT, pbm1001@cam.ac.uk (Paul Menage) >>>>> said: Paul> Maybe the Pickle generic module should automatically register a pickelr Paul> for it's list type that will pickle it iteratively. This would save Paul> people having to write their own versions. Here is the file ListPkl.i3, in the netobj/src/netobjrt directory: (* Copyright 1992 Digital Equipment Corporation. *) (* Distributed only by permission. *) (* ListPkl.i3 *) (* Last modified on Tue Sep 1 15:42:30 PDT 1992 by evers *) (* If a program contains an import of this interface, a "Pickle.Special" with "sp.sc = TYPECODE (List.T)" will be passed to "Pickle.RegisterSpecial" during initialization. This special pickles references "r" with "TYPECODE (r) = TYPECODE (List.T)" iteratively rather than recursively, and is thus useful for long lists in small stacks. *) INTERFACE ListPkl; END ListPkl. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 46 === Date: 9 Mar 95 09:40:23 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Problems building 3.5.1/boot-LINUX After hunting after an obscure bug in the dll tools-2.1.6 (a buffer [wrapup, in mkimage.c] was too small, overwriting critical variables) and telling the linker where to find lgcc, I'm now getting unresolved references. What's going on here?! I thought 3.5.1 was supposed to be bug-fixed ... but from the errors I already fixed, I'm beginning to doubt that. There are more bugs than that in the dll tools. Look into ftp.vlsi.polymtl.ca:pub/m3/linux for a "fixed" version of tools-2.11. Although it is older than 2.16, it has worked quite well. Last time I checked, newer versions of tools did not include all my bug fixes. You have to realize that the dll tools have not progressed much since a year or so because everyone knew they were a dead end soon to be replaced by ELF tools. The ELF tools are now in Beta state and working beautifully. A linux ELF release of SRC M3 is available from the same ftp site in pub/m3/linuxelf. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 47 === Date: Thu, 09 Mar 95 13:05:52 -0800 From: heydon@pa.dec.com Subject: Re: try-finally-except Taj Khattra writes: > I am trying to write a Modula-3 like exception handling mechanism > for ANSI C (based on Eric Robert's package) and am trying to justify > to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead > of just TRY-FINALLY-EXCEPT. I don't think the answer is that deep: most of the time, you need either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design philosophy was to provide simple language features, so both were provided individually. If you want to get the effect of your proposed: TRY S1 FINALLY S2 EXCEPT Handlers END statement, you can simply write: TRY TRY S1 FINALLY S2 END EXCEPT Handlers END But most of the time, I tend to use only one or the other, not both together. TRY-FINALLY is provided if some "clean up" action must be taken --- such as closing a file --- even in if an exception has occurred. An important example of this is the LOCK statement (See Section 2.3.19, "Systems Programming with Modula-3" (SPwM3), page 36). The semantics of: LOCK mu DO S END is defined using TRY-FINALLY so that the lock will always be unlocked, even if an exception occurs during the execution of S: WITH m = mu DO (* needed in case evaluating "mu" has side-effects *) Thread.Acquire(m); TRY S FINALLY Thread.Release(m) END END This is also why the semantics of the EXIT and RETURN statements are defined in terms of exceptions: if EXIT or RETURN occurs within the first part of TRY-FINALLY statement, the statements in the FINALLY portion are guaranteed to be evaluated before the loop is exited or the procedure returns, respectively. > Is the following case the main reason why ? > > TRY > RAISE e; > FINALLY > IF (foobar) RAISE e; > EXCEPT > e => (* this may or may not be executed *) > END I think you don't quite understand the semantics of TRY-FINALLY. The statement "TRY S1 FINALLY S2 END" re-raises any exception raised in "S1" (unless "S2" raises a different exception). So in your example, even if "foobar" is FALSE, the exception "e" will be raised by the initial TRY-FINALLY portion. In particular, the statement: TRY RAISE e FINALLY S END will *always* raise the exception "e", unless the statement "S" raises some other exception "e'", in which case that exception is raised by the statement as a whole. Hence, if I understand the intended semantics of your proposed TRY-FINALLY-EXCEPT statement, the comment in your example is incorrect: the exception handler for "e" is guaranteed to be invoked. See Section 2.3.8 (pg 31) of SPwM3. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 48 === Date: Thu, 9 Mar 1995 20:38:30 GMT From: spencer@ERA.COM (Spencer Allain) Subject: looking for possibly existing generics Maybe I'm daft, but after searching through all the libm3 directories, I have been unable to find an acceptable generic implementation of a list (couldn't even find one for a set). What passes as a linked list List.ig is very useless because I am unable to delete elements. Then I discovered Sequence.ig; close, but still not what I need. I want to be able to add to/delete from the middle of the sequence. Is there a library that exists with the things I guess I've become accustom to not having to implement myself? ie. I want a Queue, Stack, Set, Singly-Linked and Doubly-Linked List, and possibly a few other things of that nature. I mistakenly assumed that libm3 contained these "basic" generic objects, and really don't want to go through the effort of creating them myself when they must certainly exist in some other "standard" library. Having been forced to use C++ where one of the worst problems is the lack of a good standard library -- although STL is a step in the right direction -- I'd be very disappointed if Modula-3 didn't have what I consider almost essentials. >From what I've attempted to learn on my own, I'm quite pleased with the Modula-3 semantics, but I'll be very displeased if generic Sets are an exercise for the reader, much like an Array class is in C++. -Spencer Allain Engineering Research Associates ======================================================================= 49 === Date: 9 Mar 95 09:46:26 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Hardware & Operating Systems I am investigating possible tools/languages for developing large, distributed C/S applications. How portable is Modula-3? What platforms / operating systems is it available on? Modula-3 is an excellent vehicle for distributed, graphical, applications (check Network Objects). The FAQ (ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps) will tell you more. It runs on over a dozen Unix variants (including LINUX and FreeBSD) and on Win32 (Windows NT and Windows 9X but some libraries are still being ported). -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 50 === Date: 10 Mar 1995 02:20:45 GMT From: taj@vanbc.wimsey.com (Taj Khattra) Subject: Re: try-finally-except heydon@pa.dec.com wrote: : I don't think the answer is that deep: most of the time, you need : either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design : philosophy was to provide simple language features, so both were : provided individually. I agree that if most of the time either TRY-EXCEPT or TRY-FINALLY, but not both, are used, then having both is better than a single TRY-FINALLY-EXCEPT statement. But, I thought that code like TRY TRY S1 FINALLY S2 END EXCEPT E1 => H1 ... En => Hn END would be quite common, which is why I assume that TRY-FINALLY-EXCEPT, where both the FINALLY and EXCEPT sections were optional, might be a bit more convenient *syntactically* only. Perhaps I'm mistaken in assuming this, not having read or written all that much Modula-3 code myself. : > Is the following case the main reason why ? : > : > TRY : > RAISE e; : > FINALLY : > IF (foobar) RAISE e; : > EXCEPT : > e => (* this may or may not be executed *) : > END : I think you don't quite understand the semantics of TRY-FINALLY. Sorry for not making myself clear. I should have included this in my original message - ------------------------------------------- TRY S[T] FINALLY <- FINALLY is optional S[F] EXCEPT <- EXCEPT is optional E1 => S[E1] ... En => S[En] END execute stmt S[T] followed by stmt S[F] if (S[F] raises exception E[F]) (* propagate E[F] *) the result of the TRY stmt is exception E[F] (* ignore E1 ... En *) [1] elif (S[T] raises exception E[T]) if (E[T] matches Ei in {E1, E2, ..., En}) (* handle E[T] *) the result of the TRY stmt is the result of stmt S[Ei] else (* propagate E[T] *) the result of the TRY stmt is exception E[T] endif endif ------------------------------------------- [1] implies that "TRY TRY S1 FINALLY S2 END EXCEPT e => S3 END" is NOT equivalent to "TRY S1 FINALLY S2 EXCEPT e => S3 END", if "S2" raises an exception - this is what my example was meant to convey. But [1] could easily be modified (and it might be preferable to do so) so that both forms were equivalent, so my example really wasn't worth anything. So I guess all I've ended up worrying about is whether or not to provide some "syntactic sugar", not knowing if it would be used often enough in practice to be worth the trouble. --taj ======================================================================= 51 === Date: Fri, 10 Mar 1995 08:19:38 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: looking for possibly existing generics Spencer Allain writes: > > Maybe I'm daft, but after searching through all the libm3 directories, > I have been unable to find an acceptable generic implementation of a > list (couldn't even find one for a set). > > What passes as a linked list List.ig is very useless because I am > unable to delete elements. Then I discovered Sequence.ig; close, but > still not what I need. I want to be able to add to/delete from the > middle of the sequence. > > Is there a library that exists with the things I guess I've become > accustom to not having to implement myself? ie. I want a Queue, > Stack, Set, Singly-Linked and Doubly-Linked List, and possibly a few > other things of that nature. > > I mistakenly assumed that libm3 contained these "basic" generic > objects, and really don't want to go through the effort of creating > them myself when they must certainly exist in some other "standard" > library. > > Having been forced to use C++ where one of the worst problems is the > lack of a good standard library -- although STL is a step in the right > direction -- I'd be very disappointed if Modula-3 didn't have what I > consider almost essentials. > > >From what I've attempted to learn on my own, I'm quite pleased with > the Modula-3 semantics, but I'll be very displeased if generic Sets > are an exercise for the reader, much like an Array class is in C++. > > -Spencer Allain > Engineering Research Associates I believe that most, if not all, of the functionality that you descibed is provided by the existing generics. How is a set different than a table ? A queue is a sequence the only operations are: addhi, remlo. A stack is a sequence where the only operations are: addlo, remlo. Deleting from the middle of list can be done in several ways. It can be done functionally by creating a new list that contains the elements from the two sides of the element being deleted; and this isn't necessarily inefficient - it merely a matter of an allocation and some pointer copying. It can also be done "destruct ively" (that is by overwriting existing pointers) the 'AppendD' operation on a list. Hope this helps point you in the right direction ! Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 52 === Date: Fri, 10 Mar 95 10:28:17 -0800 From: detlefs@pa.dec.com Subject: Re: looking for possibly existing generics I must respectfully disagree with Geoff Wyant, and agree with Spencer Allain's implicit assertion, to wit: that the set of M3 standard generics distributed with SRC's libm3 is not as comprehensive as one might like. To answer Geoff's question "How is a set different than a table?" I will include my generic set package at the end of this message. The executive summary is that a good Set package supports operations such as union, intersection, set equality, set difference, etc. that don't appear in the Table interface. Obviously, Table is an excellent implementation strategy for Set -- as long as you have an obvious hash function for your element type, and you expect your sets to be sufficiently large so that the overhead of a table (vs., say a linked-list implementation) is justified. (In fact, I also provide a linked list implementation, which I use heavily myself; I've also implemented the Table.T interface with a association list representation.) Another item from Spencer's list that cannot be easily dismissed is "Doubly-Linked List." I don't find Geoff's argument that Deleting from the middle of list can be done in several ways. It can be done functionally by creating a new list that contains the elements from the two sides of the element being deleted; and this isn't necessarily inefficient - it's merely a matter of an allocation and some pointer copying. very convincing; occasionally one has to solve problems in which the asymptotic complexity of algorithm really is a practical concern, and the ability to insert into a list before *or* after a given element in a list in constant time is something I've needed time and time again. This one I haven't implemented generically, but maybe someone ought to... Dave Below follow the 8 source files of the set package: m3makefile set.tmpl Set.ig, Set.mg SetDef.ig, SetDef.mg SetList.ig, SetList.mg The "set.tmpl" template file defines quake procedures for building set instantiations. You have to instantiate both Set(Foo) and Set{Def,List}(Foo) to get a set implementation. (Def is the table implementation, List the linked-list version. The examples in the m3makefile should make it clear how to do so. ---------------- m3makefile ------------------------------------------------ /* Copyright (C) 1992, Digital Equipment Corporation */ /* All rights reserved. */ /* See the file COPYRIGHT for a full description. */ /* Last modified on Fri Mar 10 10:28:10 PST 1995 by detlefs */ /* modified on Tue Feb 11 20:48:28 PST 1992 by muller */ import(libm3) Generic_module (Set) Generic_module (SetDef) Generic_module (SetList) template(set) MkSet(Atom, Atom) MkSetDef(Atom, Atom) MkSetList(Atom, Atom) MkSet(Int, Integer) MkSetDef(Int, Integer) MkSetList(Int, Integer) MkSet(Text, Text) MkSetDef(Text, Text) MkSetList(Text, Text) MkSet(Ref, Refany) MkSetList(Ref, Refany) Library(set) ---------------- set.tmpl ------------------------------------------------ % Copyright (C) 1993 Digital Equipment Corporation % All rights reserved. % See the file COPYRIGHT for a full description. % % modified on Mon Sep 20 12:26:41 PDT 1993 by kalsow % % Quake functions to instantiate a generic table. % readonly proc MkSet (nm, elem) is local set = nm & "Set" build_generic_intf (set, "Set", [elem], VISIBLE) build_generic_impl (set, "Set", [elem]) end readonly proc mkSet (nm, elem) is local set = nm & "Set" build_generic_intf (set, "Set", [elem], HIDDEN) build_generic_impl (set, "Set", [elem]) end % % Table-based implementation % readonly proc MkSetDef (nm, elem) is local set = nm & "Set" local setDef = nm & "SetDef" local elemRefTbl = nm & "RefTbl" build_generic_intf (setDef, "SetDef", [set], VISIBLE) build_generic_impl (setDef, "SetDef", [elem, set, elemRefTbl]) end readonly proc mkSetDef (nm, elem) is local set = nm & "Set" local setDef = nm & "SetDef" local elemRefTbl = nm & "RefTbl" build_generic_intf (setDef, "SetDef", [set], HIDDEN) build_generic_impl (setDef, "SetDef", [elem, set, elemRefTbl]) end % % List-based implementation % readonly proc MkSetList (nm, elem) is local set = nm & "Set" local setList = nm & "SetList" local elemList = nm & "List" build_generic_intf (setList, "SetList", [set], VISIBLE) build_generic_impl (setList, "SetList", [elem, set, elemList]) end readonly proc mkSetList (nm, elem) is local set = nm & "Set" local setList = nm & "SetList" local elemList = nm & "List" build_generic_intf (setList, "SetList", [set], HIDDEN) build_generic_impl (setList, "SetList", [elem, set, elemList]) end ---------------- Set.ig --------------------------------------------------- (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Tue Feb 11 20:48:45 PST 1992 by muller *) (* "Set" is a generic interface defining sets of "Elem.T"'s. *) GENERIC INTERFACE Set(Elem); (* Where "Elem.T" is a type that is not an open array type and "Elem" contains | PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN; "Equal" must be an equivalence relation. "Equal" may be declared with a parameter mode of either "VALUE" or "READONLY", but not "VAR". *) TYPE Public = OBJECT METHODS fromArray(READONLY a: ARRAY OF Elem.T): T; copy(): T; member(e: Elem.T): BOOLEAN; insert(e: Elem.T): BOOLEAN; delete(e: Elem.T): BOOLEAN; size(): CARDINAL; isEmpty(): BOOLEAN; subset(s2: T): BOOLEAN; equal(s2: T): BOOLEAN; union(s2: T): T; intersection(s2: T): T; diff(s2: T): T; unionD(s2: T): T; intersectionD(s2: T): T; diffD(s2: T): T; iterate(): Iterator; END; T <: Public; Iterator = OBJECT METHODS next(VAR e: Elem.T): BOOLEAN END; (* A "Set(Elem)" is a set of "Elem.T"'s. "Elem.T"'s that are equivalent under "Elem.Equal" are treated as equivalent by "Set"; for example, if you are creating a set with an "Elem.T" of "TEXT", you are likely to want "Text.Equal" as the equivalence relation. The equivalence relation must be time-invariant. For example, it can't depend on the values of particular references since some garbage collectors may move "REF" values. Formally, a set "s" has the component | set(s) `a set of equivalence classes of "Elem.T"'s`. We will use "equiv(e)" to denote the equivelance class containing an "Elem.T" "e". For efficiency, a set is not monitored: it is up to the clients to avoid illegal concurrent accesses on the methods of a set. A set's "insert" and "delete" methods have side-effects on the set, so can't be performed concurrently with any other method of that set or of an iterator on that set. An iterator's "next" method has side-effects on the iterator, and is also considered to be a side-effect free operation on the parent set. The methods of an object "s" of type "Set.T" have the following specifications: The call "s.fromArray(a)" causes "set(s)" to contain exactly the equivalence classes containing all the elements of the array "a". The call "s.copy()" returns a set "s2" whose abstract state "set(s2)" is the same as "set(s)". The call "s.member(e)" returns "TRUE" iff "e" is in an equivalence class in "set(s)". The call "s.insert(e)" returns "TRUE" and does not modify "s" if "equiv(e)" is in "set(s)"; otherwise it adds "equiv(e)" to "set(s)" and returns "FALSE". The call "s.delete(e)" ensures that "set(s)" does not contain "equiv(e)", returning "TRUE" iff "set(s)" contained "equiv(e)" before the call. The call "s.isEmpty()" returns "TRUE" iff "set(s)" is the empty set. The call "s.size()" returns the cardinality of "set(s)". The call "s.subset(s2)" returns "TRUE" iff "set(s)" is a subset of "set(s2)". The call "s.equal(s2)" returns "TRUE" iff "set(s)" and "set(s2)" are the same set. The call "s.union(s2)" returns a new set "s3" such that "set(s3)" is the union of "set(s)" and "set(s2)". The call "s.intersection(s2)" returns a new set "s3" such that "set(s3)" is the intersection of "set(s)" and "set(s2)". The call "s.diff(s2)" returns a set "s3" such that "set(s3)" contains all equivalence classes in "set(s)" but not in "set(s2)". The call "s.unionD(s2)" modifies "s" so that "set(s)" contains the union of "set(s`)" and "set(s2)", where "s`" is the state of "s" immediately before the call, and returns the modified set. The call "s.intersectionD(s2)" modifies "s" so that "set(s)" contains the intersection of "set(s`)" and "set(s2)", where "s`" is the state of "s" immediately before the call, and returns the modified set. The call "s.diffD(s2)" modifies "s" so that "set(s)" contains no equivalence classes that are in "set(s2)", and returns the modified set. The call "s.iterate()" returns an iterator, which is an object that can be used to iterate over the elements in "s". See below for the specification of the "Iterator" type. If "it" is the result of the call "s.iterate()", then the call "it.next(e)" selects an element from "s" that has not already been returned by "it", sets "e" to that element, and returns "TRUE". If no entries remain, the call returns "FALSE" without setting "e". It is a checked runtime error to call "next" after it has returned "FALSE". *) PROCEDURE Equal(s1, s2: T): BOOLEAN; (* Equivalent to "s1.equal(s2)". Exported so that "Set"'s may be used as arguments to generic interfaces. *) END Set. ---------------- Set.mg --------------------------------------------------- (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Tue Feb 11 20:48:45 PST 1992 by muller *) (* "Set" is a generic interface defining sets of "Elem.T"'s. *) GENERIC MODULE Set(Elem); (* Set is an abstract type, but many of it's operations can be implemented reasonably efficiently independently of any specific representation decisison. Those are defined here. Of course, subtypes may choose representations that offer the possibility of more efficient implementations, and would therefore override these methods. *) REVEAL T = Public BRANDED OBJECT OVERRIDES isEmpty := IsEmpty; subset := Subset; equal := Equal; union := Union; intersection := Intersection; diff := Diff; unionD := UnionD; intersectionD := IntersectionD; diffD := DiffD; END; PROCEDURE IsEmpty(s: T): BOOLEAN = BEGIN RETURN s.size() = 0 END IsEmpty; PROCEDURE Subset(s: T; s2: T): BOOLEAN = BEGIN IF s.size() > s2.size() THEN RETURN FALSE ELSE VAR iter := s.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO IF NOT s2.member(e) THEN RETURN FALSE END (* IF *) END (* WHILE *) END (* BEGIN *); RETURN TRUE END (* IF *) END Subset; PROCEDURE Equal(s1, s2: T): BOOLEAN = BEGIN RETURN s1.size() = s2.size() AND s1.subset(s2) AND s2.subset(s1) END Equal; PROCEDURE Union(s1: T; s2: T): T = VAR s3 := s1.copy(); BEGIN RETURN s3.unionD(s2) END Union; PROCEDURE Intersection(s1: T; s2: T): T = VAR s3 := s1.copy(); BEGIN RETURN s3.intersectionD(s2) END Intersection; PROCEDURE Diff(s1: T; s2: T): T = VAR s3 := s1.copy(); BEGIN RETURN s3.diffD(s2) END Diff; PROCEDURE UnionD(s1: T; s2: T): T = VAR iter := s2.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO EVAL s1.insert(e) END (* WHILE *); RETURN s1 END UnionD; PROCEDURE IntersectionD(s1: T; s2: T): T = VAR iter := s1.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO IF NOT s2.member(e) THEN EVAL s1.delete(e) END (* IF *) END (* WHILE *); RETURN s1 END IntersectionD; PROCEDURE DiffD(s1: T; s2: T): T = VAR iter := s1.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO IF s2.member(e) THEN EVAL s1.delete(e) END (* IF *) END (* WHILE *); RETURN s1 END DiffD; BEGIN END Set. ---------------- SetDef.ig --------------------------------------------------- (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Tue Feb 11 20:48:45 PST 1992 by muller *) (* "SetDef" is a generic interface defining sets of "Elem.T"'s, implemented via hash tables. *) GENERIC INTERFACE SetDef(ElemSet); (* WHERE "ElemSet = Set(Elem)", and "Elem.T" is a type that is not an open array type and "Elem" contains | PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN; | PROCEDURE Hash(k: Key.T): Word.T; "Equal" must be an equivalence relation and "Hash" must respect that equivalence relation, i.e., if "Equal(k1, k2)", then "Hash(k1)=Hash(k2)". "Hash" and "Equal" may be declared with a parameter mode of either "VALUE" or "READONLY", but not "VAR". *) TYPE Public = ElemSet.T OBJECT METHODS init(sizeHint: CARDINAL := 0): T END; T <: Public; Iterator <: ElemSet.Iterator; (* The expression | NEW(SetDef.T).init(sz) creates a new, empty set. The argument "sz" is a hint; the set may be more efficient if "sz" accurately predicts the maximum number of elements it will ever contain. *) END SetDef. ---------------- SetDef.mg --------------------------------------------------- (* Copyright 1993 Digital Equipment Corporation. *) (* Distributed only by permission. *) (* See the file COPYRIGHT for a full description. *) GENERIC MODULE SetDef(Elem, ElemSet, ElemRefTable); (* WHERE "ElemSet = Set(Elem)" and "ElemRefTable = Table(Elem, Refany)". *) REVEAL T = Public BRANDED OBJECT t: ElemRefTable.Default; OVERRIDES init := Init; fromArray := FromArray; copy := Copy; member := Member; insert := Insert; delete := Delete; size := Size; intersection := Intersection; diff := Diff; intersectionD := IntersectionD; iterate := Iterate; END (* OBJECT *); Iterator = ElemSet.Iterator BRANDED OBJECT tIter: ElemRefTable.Iterator; OVERRIDES next := Next; END (* OBJECT *); PROCEDURE Init(s: T; sizeHint: CARDINAL): T = BEGIN s.t := NEW(ElemRefTable.Default).init(sizeHint); RETURN s END Init; PROCEDURE FromArray(s: T; READONLY a: ARRAY OF Elem.T): ElemSet.T = BEGIN s.t := NEW(ElemRefTable.Default).init(NUMBER(a)); FOR i := 0 TO LAST(a) DO EVAL s.insert(a[i]) END (* FOR *); RETURN s END FromArray; PROCEDURE Copy(s: T): ElemSet.T = VAR res := NEW(T).init(s.size()); iter := s.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO EVAL res.insert(e) END (* WHILE *); RETURN res END Copy; PROCEDURE Member(s: T; e: Elem.T): BOOLEAN = VAR dummy: REFANY; BEGIN RETURN s.t.get(e, dummy) END Member; PROCEDURE Insert(s: T; e: Elem.T): BOOLEAN = BEGIN RETURN s.t.put(e, NIL) END Insert; PROCEDURE Delete(s: T; e: Elem.T): BOOLEAN = VAR dummy: REFANY; BEGIN RETURN s.t.delete(e, dummy) END Delete; PROCEDURE Size(s: T): CARDINAL = BEGIN RETURN s.t.size() END Size; PROCEDURE Intersection(s1: T; s2: ElemSet.T): ElemSet.T = VAR s3: T; larger: ElemSet.T; smallerIter: ElemSet.Iterator; e: Elem.T; BEGIN IF s1.size() >= s2.size() THEN larger := s1; smallerIter := s2.iterate() ELSE larger := s2; smallerIter := s1.iterate() END; s3 := NEW(T).init(larger.size()); WHILE smallerIter.next(e) DO IF larger.member(e) THEN EVAL s3.insert(e) END (* IF *) END (* WHILE *); RETURN s3 END Intersection; PROCEDURE Diff(s1: T; s2: ElemSet.T): ElemSet.T = VAR s3 := NEW(T).init(s1.size()); iter := s1.iterate(); e: Elem.T; BEGIN WHILE iter.next(e) DO IF NOT s2.member(e) THEN EVAL s3.insert(e) END (* IF *) END (* WHILE *); RETURN s3 END Diff; CONST SizeFactor = 3; (* This is overridden because there is a more efficient implementation than the default when "s2" is significantly smaller than "s1". *) PROCEDURE IntersectionD(s1: T; s2: ElemSet.T): ElemSet.T = BEGIN IF s2.size() * SizeFactor < s1.size() THEN VAR tOld := s1.t; tNew := NEW(ElemRefTable.Default).init(s2.size()); iter := s2.iterate(); e: Elem.T; dummy: REFANY; BEGIN WHILE iter.next(e) DO IF tOld.get(e, dummy) THEN EVAL tNew.put(e, NIL) END (* IF *) END (* WHILE *); s1.t := tNew; END (* BEGIN *); RETURN s1 ELSE RETURN ElemSet.T.intersectionD(s1, s2) END (* IF *) END IntersectionD; PROCEDURE Iterate(s: T): ElemSet.Iterator = VAR res := NEW(Iterator, tIter := s.t.iterate()); BEGIN RETURN res; END Iterate; PROCEDURE Next(iter: Iterator; VAR e: Elem.T): BOOLEAN = VAR dummy: REFANY; BEGIN RETURN iter.tIter.next(e, dummy) END Next; BEGIN END SetDef. ---------------- SetList.ig ------------------------------------------------ (* Copyright (C) 1992, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Tue Feb 11 20:48:45 PST 1992 by muller *) (* "SetList" is a generic interface defining sets of "Elem.T"'s, implemented as linked lists. This implementations is appropriate only for small sets. *) GENERIC INTERFACE SetList(ElemSet); (* WHERE "Elem.T" is a REF type and contains | PROCEDURE Equal(e1, e2: Elem.T): BOOLEAN; "ElemSet = Set(Elem)". "Equal" must be an equivalence relation. "Equal" may be declared with a parameter mode of either "VALUE" or "READONLY", but not "VAR". *) TYPE Public = ElemSet.T OBJECT METHODS init(): T; END; T <: Public; Iterator <: ElemSet.Iterator; (* If "s" is an object of type "SetDefault.T", the expression | NEW(SetDef.T).init() creates a new, empty set. The call "s.toRefList()" returns a "RefList.T" whose elements include an element from each of the equivalence classes in "set(s)", and no other elements. *) END SetList. ---------------- SetList.mg ------------------------------------------------ (* Copyright 1993 Digital Equipment Corporation. *) (* Distributed only by permission. *) (* See the file COPYRIGHT for a full description. *) GENERIC MODULE SetList(Elem, ElemSet, ElemList); (* WHERE "ElemSet = Set(Elem)", and "ElemList = List(Elem)". *) REVEAL T = Public BRANDED OBJECT l: ElemList.T := NIL OVERRIDES init := Init; fromArray := FromArray; copy := Copy; member := Member; insert := Insert; delete := Delete; size := Size; intersection := Intersection; diff := Diff; intersectionD := IntersectionD; diffD := DiffD; iterate := Iterate; END (* OBJECT *); Iterator = ElemSet.Iterator BRANDED OBJECT l: ElemList.T OVERRIDES next := Next; END (* OBJECT *); PROCEDURE Init(s: T): T = BEGIN RETURN s END Init; PROCEDURE FromArray(s: T; READONLY a: ARRAY OF Elem.T): ElemSet.T = BEGIN s.l := NIL; FOR i := 0 TO LAST(a) DO EVAL s.insert(a[i]) END (* FOR *); RETURN s END FromArray; PROCEDURE Copy(s: T): ElemSet.T = VAR res := NEW(T).init(); rl := s.l; BEGIN WHILE rl # NIL DO res.l := ElemList.Cons(rl.head, res.l); rl := rl.tail END (* WHILE *); RETURN res END Copy; PROCEDURE Member(s: T; e: Elem.T): BOOLEAN = VAR rl := s.l; BEGIN WHILE rl # NIL DO IF Elem.Equal(rl.head, e) THEN RETURN TRUE END (* IF *); rl := rl.tail END (* WHILE *); RETURN FALSE END Member; PROCEDURE Insert(s: T; e: Elem.T): BOOLEAN = BEGIN IF s.member(e) THEN RETURN TRUE ELSE s.l := ElemList.Cons(e, s.l); RETURN FALSE END (* IF *) END Insert; PROCEDURE Delete(s: T; e: Elem.T): BOOLEAN = VAR pl: ElemList.T := NIL; rl := s.l; BEGIN WHILE rl # NIL DO IF Elem.Equal(e, rl.head) THEN IF pl = NIL THEN s.l := rl.tail ELSE pl.tail := rl.tail END (* IF *); RETURN TRUE ELSE pl := rl; rl := rl.tail END (* IF *) END (* WHILE *); RETURN FALSE END Delete; PROCEDURE Size(s: T): CARDINAL = BEGIN RETURN ElemList.Length(s.l) END Size; PROCEDURE Intersection(s1: T; s2: ElemSet.T): ElemSet.T = VAR rl1 := s1.l; res := NEW(T).init(); BEGIN WHILE rl1 # NIL DO IF s2.member(rl1.head) THEN res.l := ElemList.Cons(rl1.head, res.l) END (* IF *); rl1 := rl1.tail END (* WHILE *); RETURN res END Intersection; PROCEDURE Diff(s1: T; s2: ElemSet.T): ElemSet.T = VAR rl1 := s1.l; res := NEW(T).init(); BEGIN WHILE rl1 # NIL DO IF NOT s2.member(rl1.head) THEN res.l := ElemList.Cons(rl1.head, res.l) END (* IF *); rl1 := rl1.tail END (* WHILE *); RETURN res END Diff; PROCEDURE IntersectionD(s1: T; s2: ElemSet.T): ElemSet.T = VAR prl1: ElemList.T := NIL; rl1 := s1.l; BEGIN WHILE rl1 # NIL DO IF NOT s2.member(rl1.head) THEN IF prl1 = NIL THEN s1.l := rl1.tail ELSE prl1.tail := rl1.tail END (* IF *) ELSE prl1 := rl1 END (* IF *); rl1 := rl1.tail END (* WHILE *); RETURN s1 END IntersectionD; PROCEDURE DiffD(s1: T; s2: ElemSet.T): ElemSet.T = VAR prl1: ElemList.T := NIL; rl1 := s1.l; BEGIN WHILE rl1 # NIL DO IF s2.member(rl1.head) THEN IF prl1 = NIL THEN s1.l := rl1.tail ELSE prl1.tail := rl1.tail END (* IF *) ELSE prl1 := rl1 END (* IF *); rl1 := rl1.tail END (* WHILE *); RETURN s1 END DiffD; PROCEDURE Iterate(s: T): ElemSet.Iterator = VAR res := NEW(Iterator, l := s.l); BEGIN RETURN res; END Iterate; PROCEDURE Next(iter: Iterator; VAR e: Elem.T): BOOLEAN = BEGIN IF iter.l = NIL THEN RETURN FALSE ELSE e := iter.l.head; iter.l := iter.l.tail; RETURN TRUE END (* IF *) END Next; BEGIN END SetList. ======================================================================= 53 === Date: 10 Mar 1995 12:37:21 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Re: Network objects, threads and stacks In article <9502281543.AA28627@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.COM ( Geoffrey Wyant - Sun Microsystems Labs BOS) writes: >douglm@rpi.edu writes: > > A more general solution might be some extension to the network objects > > package which allows us to register our own new thread routine. One > > parameter would be the typecode of the object for which the thread is > > required (at least). > > >Another solution that doesn't require any changes to the network object's >interfaces or runtime is for you to fork off your own thread in those cases >where you know that you will need a large stack. That is, the method >implementation in your server forks off a thread of its own with the size >that you choose. It's a little more work on your part, but doesn't require >any changes to the current interfaces. But if you are passing complicated structures around, the Pickle packacge may well exceed the available stack space whilst unmarshalling parameters, before the user code is reached. Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 54 === Date: 10 Mar 1995 12:34:26 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Re: netobjd problems (SRC M3 3.3) In article , faegri@dcs.glasgow.ac.uk (Tor Erlend Faegri) writes: > >In my main module, I use NSR.T objects in the following way: > > VAR > aReplica : NSR.T := NIL; > ... > (* Register an instance of a replica in node's netobjd object tables *) > NetObj.Export("replica", NEW(NSR.T), NetObj.Locate(node)); ^^^^^^ This line should read NEW(NSR_T). An NSR.T object has _no_ default methods, so you export a subtype of it that does have the methods defined, namely an NSR_T object. Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 55 === Date: 10 Mar 1995 16:10:32 GMT From: bm@play.cs.columbia.edu (Blair MacIntyre) Subject: Re: OpenGL (was Re: WinNT questions) To all those who noticed the unqualified host names in the html page that contains my OpenGL headers, I've fixed m3browser so the host names should be qualified now. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 56 === Date: Fri, 10 Mar 1995 13:24:21 MET From: rudy@cs.rug.nl Subject: Report: Language definition (readonly) On the language definition of Modula-3 R. Moddemeijer March 10, 1995 Department of Computing Science, University of Groningen, P.O.Box 800, NL-9700 AV Groningen, The Netherlands, Telephone: + 31 50 63 3940, Telefax: + 31 50 63 3800, e-mail: rudy@cs.rug.nl 1 Introduction As I have promised, I now present the report on the subject readonly variables. This report consist out of the modified original proposal and a discussion based on the reactions on the Modula-3 newsgroup. 2 Readonly variables 2.1 Proposal There is a certain symmetry between procedure parameters and variable declarations. In case of procedure parameters we pos- sess the VAR-parameter, the VALUE-parameter and the READONLY- parameter. These parameters have there counterparts: the VAR- declaration, the CONST-declaration and the not existing READONLY- declaration. I therefore propose the introduction of READONLY vari- ables. A readonly variable is a constant after initialization. At the moment of declaration a readonly variable will be initialized by an expression. After initialization readonly variables can not be changed. So a readonly variable is an RHS variable. Notice: con- stants can only be initialized by a constant expresssions, readonly variables by any expression. 2.2 Syntax The Modula-3 syntax (Language report section 1.10.7 Compila- tion Unit Productions) should be changed into: Declaration = CONST {ConstDecl ";"} | TYPE {TypeDecl ";"} | EXCEPTION {ExcecptionDecl ";"} | READONLY {ReadOnlyDecl ";"} | VAR {VariableDecl ";"} | ProcedureHead ["=" Block Indent] ";" | REVEAL {Type ID ("="|"<:") Type. ReadonlyDecl = Ident [":" Type]":=" Expr. 2.3 Example An example program could be the computation of the roots of the equation ax2 + bx + c = 0: IMPORT RealFloat; PROCEDURE tgp(a,b,c:REAL; VAR x1,x2:REAL)= READONLY disc := b*b - 4.0*a*c; root := RealFloat.Sqrt(disc); BEGIN x1 := (-b+root)/(2.0*a); x2 := (-b-root)/(2.0*a); END; END tgp; Notice that disc and root are used as constants; they are never changed. In larger programs the READONLY variables increase the security. READONLY variables can never be changed accidently. 2.4 Discussion Farshad Nayeri: Often, you can achieve the same effect by using a WITH statement: IMPORT RealFloat; PROCEDURE tgp(a,b,c:REAL; VAR x1,x2:REAL)= BEGIN WITH disc = b*b - 4.0*a*c, root = RealFloat.Sqrt(disc) DO x1 := (-b+root)/(2.0*a); x2 := (-b-root)/(2.0*a); END; END tgp; WITH is a bit looser than READONLY as it may give a writable designator. Lucian Wischik: On the other hand, with READONLY you are able to declare variables precisely where you wanted them; e.g. in the declaration block and not in the statement block. Self: If the expression E in WITH V = E is a writable designator, the WITH-statement is an alternative for a VAR-declaration with ini- tialization, if not, it is an alternative for a READONLY-declaration. The main argument to introduce this READONLY construction is security. And security is one of the most important advantages of Modula-3 with respect to C++. The WITH construction does not increase the security. Norman Ramsey: The READONLY declara- tion in interfaces can export variables that won't be touched. You can't do this using WITH. Makoto Shimojima: To restrict access to a variable, one can write a method to handle it and hide the variable itself in the interface. If the inline pragma is properly implemented, the overhead should be minimum. Self: This would cost a lot of additional source code. This source code is difficult to read and makes bugs more probable. douglm@rpi.edu: The value of the READONLY-declaration is the self-documenting aspect. WITH doesn't really tell us why it's being used other than as a shorthand construct. Patrick John Edwards: The READONLY de- claration makes the code much more readable. Self: I concude the proposal to introduce the READONLY is widely accepted. 3 Thanks I thank all researchers which have contributed to the discussion on the internet: Patrick John Edwards, Sam Kendall, Farshad Nay- eri, Norman Ramsey, Makoto Shimojima, Lucian Wischik and douglm@rpi.edu ======================================================================= 57 === Date: 10 Mar 1995 16:09:02 GMT From: bm@play.cs.columbia.edu (Blair MacIntyre) Subject: Re: Question. Well, that was a failed experiment (cc:ing a mail message with a mime attachment to the newsgroup ... could anybody read the attachment with the news readers?) The attachment was my current IRIX5 template file, which I'm attaching here. Actually, I'm only attaching the end of if where the changes occur. The changes are in the function before_program_hooks(x), and adding the M3_STANDALONE variable (which is set in a few places). ------------------------------------------------- [.... lot's deleted .....] % used by the stuff below. M3_STANDALONE = "" proc build_standalone() is % --- reset the linker to avoid shared libraries. M3_CONFIG += "-Y2@/bin/cc@-Wl,-B,static@" M3_STANDALONE = "yes" end proc build_nodebug() is % Use the gcc distribution that comes with M3 (2.5.7) -- this % version of gcc does not support debugging on Irix, but is % probably better debugged than gcc 2.6.0 M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1-2.5.7@-quiet@" end proc build_shared() is % --- reset the linker to use shared libraries. M3_CONFIG += "-Y2@/bin/cc@-call_shared@-Wl,-rpath," & LIB_USE & "@" M3_STANDALONE = "" end %-------------------------------------------------------------------- hooks --- % These are the "last chance" hooks that are called each time a library % or program is built. They might build shared libraries or strip % executables... proc before_library_hooks(x) is end proc after_library_hooks(x) is local lib_a = format ("lib%s.a", x) local lib_so = format ("lib%s.so", x) if defined ("_all") if stale (lib_a, lib_a) write ("missing ", lib_a, ": not building ", lib_so, CR) else if stale (lib_so, lib_a) exec ("ld -shared -ignore_unresolved -o", lib_so, "-all", lib_a, "-none", IMPORT_LIBS, OTHER_LIBS_L, "-lm -lc") end install_derived (lib_so) install_link_to_derived (lib_so, LIB_INSTALL) end end deriveds (lib_so, no_extension) deriveds ("so_locations", no_extension) end proc before_program_hooks(x) is local arr = "" if not M3_STANDALONE foreach ov in PKG_OVERRIDES if not equal(normalize("..", PKG_CACHE{ov}), PKG_CACHE{ov}) or not equ al(normalize(".", PKG_CACHE{ov}), PKG_CACHE{ov}) write ("m3build: relative override(", PKG_CACHE{ov}, ") may cause p roblems if package contains a shared library", CR) end arr = arr & PKG_CACHE{ov} & SL & TARGET & ":" end M3_CONFIG += "-Y2@/bin/cc@-call_shared@-Wl,-rpath," & arr & LIB_USE & "@ " end end proc after_program_hooks(x) is end %------------------------------------------------------------- installation --- % "install_file" is called during an "m3build install" for % each file that neededs to be externally exported. readonly proc install_file (src, dest, mode) is Note_install (src, dest) exec ("@cp -p", src, dest) % exec ("install -c -m", mode, src, dest) end %---------------------------------------------- the rest of the environment --- if defined("_bootstrap") include("COMMON.BOOT") end include ("COMMON") -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 58 === Date: Fri, 10 Mar 1995 13:30:09 MET From: rudy@cs.rug.nl Subject: Language definition (overrides) At this moment I find Modula-3 one of the best programming languages. Working with Modula-3 I still find minor points where the language (definition) could be improved. Therefore I will propose some minor changes to the language definition. I hope to initiate a fruitful discussion about the language definition. I will collect the reactions and write a final report. Messages sent to m3@src.dec.com are automatically forwarded to the newsgroup comp.lang.modula3. Reactions can also be sent to me personally: rudy@cs.rug.nl Example ======= What is a hidden method? A hidden method is a method in a parent object which is not accessible because there exists a method with the same name in a child object. For example: TYPE Parent=OBJECT ... METHODS hidden():INTEGER; (* hidden method *) END; Child =parent OBJECT ... METHODS hidden():REAL; (* the overlaying method *) END; In an expression we can choose to activate the hidden or the overlaying method: VAR child:=NEW(Child); i:INTEGER; r:REAL; BEGIN i:=NARROW(child,Parent).hidden;(* hidden method with dynamic binding *) i:=Parent.hidden(child); (* hidden method without dynamic binding *) r:=child.hidden; (* overlaying method *) In case of overriding a method, we do not have this choise. We can only override the overlaying method. This is especially a problem in case of generics, where the interface containing the parent and the interface containing the child are generated with the same generic interface. Proposal: hidden methods ======================== I propose a more liberal "OVERRIDES" clause. The method to be overridden can be identified by a single identifier or a quallified identifier followed by an identifier. The quallified identifier must refer to a parent objecttype or the objecttype itself. After the declarations TYPE A = OBJECT METHODS m() := P END; B = A OBJECT METHODS m() := Q OVERRIDES A.m := R END; VAR b:=NEW(B); we have that A.m(b) activates P(b) b.m() activates Q(b) NARROW(b,A).m() activates R(b) Syntax ====== The Modula-3 syntax (Language report section 1.10.9 Type productions) should be changed into: Override = [ QualId "." ] Id ":=" ConstExpr. ======================================================================= 59 === Date: Fri, 10 Mar 95 16:03:33 EST From: spencer@ERA.COM (Spencer Allain) Subject: Re: looking for possibly existing generics > Spencer Allain writes: > > > > Maybe I'm daft, but after searching through all the libm3 directories, > > I have been unable to find an acceptable generic implementation of a > > list (couldn't even find one for a set). >I believe that most, if not all, of the functionality that you descibed is >provided by the existing generics. How is a set different than a table ? >A queue is a sequence the only operations are: addhi, remlo. A stack is >a sequence where the only operations are: addlo, remlo. Deleting from the >middle of list can be done in several ways. It can be done functionally by >creating a new list that contains the elements from the two sides of the >element being deleted; and this isn't necessarily inefficient - it merely a >matter of an allocation and some pointer copying. It can also be done "destruc tively" >(that is by overwriting existing pointers) the 'AppendD' operation on a list. > >Hope this helps point you in the right direction ! > >Geoff Wyant >Geoff.Wyant@east.sun.com >Sun Microsystems Laboratories, Inc. Ok, I probably shouldn't have included Stack and Queue in this discussion, but I guess I was looking for a predifined Queue and Stack so I didn't have to create my own special interface so that only "Stack" operations could be done on my sequence. I've also realized that "List" fits more neatly with my concept of a "Collection" and that I could easily define "Set" operations on it, where my definition of Set is an unordered collection of exactly "one" instance of any value placed into the collection. ie. duplicate values can either be thought of as "overwriting" the previously inserted value or can be considered no-ops. A table requires a key and a value pair, which I have encountered being called everything from a "Map", a "Hash-Table", to an "Associated Array". I guess it's not so much that I couldn't easily construct them myself, but adding the appropriated methods in the inherited objects, I just wanted to know if the structures that I mentioned existed in some standard library. Why is it so important to me. Well, for one thing I like to be consistent. With a Sequence I can use it directly as a queue by either using the "addhi/remhi" or "addlo/remlo" pair of operations. Now unless I define a consistent Queue Interface somewhere, other people could easily do it in the opposite fashion that I do. Not a problem unless you start to mix and match the two styles. The same goes for the Stack operations. The Set that I was looking for, would have been as consistent as possible, with the language's builtin set for Ordinal Types. Sure I can create this from the generic List, but there is plenty of room for procedural name conflicts between individual creation of this structure. What I mean, is that if I define a Set, and somebody else defines a Set with slightly different procedure names, and I think his/her set is better, then I have to search through all my code to change to the new names. If there were a standard for this type of structure, then I wouldn't have to write my potentially "non-standard" interface. Believe me, this has been more than a major pain-in-the-you-know-what for my group in our C++ work, and I would hate to see something similar happen to Modula-3 once enough people start using it and encounter more and more library "clashes". It has been so difficult to switch to a new library because there isn't even close to a standard for the basic operations that should be present in every implementation of say a Stack (this is one of the things that STL addresses). I'm pleased to death that Modula-3 has a very robust standard library, but I also believe that some higher level types need to be standardized also. The best way to drag people kicking and screaming from their present language is to provide them the high-level object types that everyone who took programming courses had to do for themselves. Sure many people will want to write their own Queues, Stacks, Linked Lists, Sets, and what-not, but many would prefer to not have to worry about it. I've found that the majority of people would rather use a pre-made structure than create one that would possibly perform faster. Hmm, I guess that I've rambled on a bit. From what I've learned so far of Modula-3 I've been pretty pleased. It's not the end-all language, but I can see where it would be the logical choice over C++ in many instances, and a potential loser in others. After all that babbling, I'd like to thank you for taking the time to respond to my inquiry. I guess since I enjoy the Modula-3 style, I want to help make sure that everything is as good as it can be for people looking for another language when they've gotten completely fed up with what they're using now. -Spencer Allain Engineering Research Associates ======================================================================= 60 === Date: 10 Mar 1995 09:39:55 -0500 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: Re: Question. This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --1900020681-993439912-794846390=:21791 Content-Type: TEXT/PLAIN; charset=US-ASCII (Eric, I'm CC'ing you since you might be interested. I'm also CC:ing this to the newsgroup, although I have no idea how the attached MIME message will appear on News ... if it's really messed up, I'll repost the file) I have a fix for the following problem on IRIX5, but I haven't used it extensively. It appears to work, at least for the one case that was causing the problem I describe, so I'm attaching my template here. In the template, the LINK command has the parameter -rpath,...../lib/m3/IRIX5 which puts the modula3 library in an RPATH variable inside the executable. Thus, that directory will be searched in addition to the standard ones for the dynamic libraries. Now, if I override a package location using m3_override, and that package has a library in it, it's IRIX5 build directory is not automatically searched. That's no problem, though, since I can just add it's directory to the LD_LIBRARY_PATH environment variable, and it will get searched at run time. The problem is that if the overridden package _also_ exists in the modula3 installation directory (that is embedded in the binary file via the -rpath switch above) the run time loader will always find the one in the standard installation directory, since it looks there before the directories set via LD_LIBRARY_PATH! The easy fix is to remove the rpath switch from the link phase, and require a LD_LIBRARY_PATH variable be set that includes the standard installation directory. The not so easy fix (when you don't know quake), is to add all the override build directories to the -rpath command, which is what I've tried to do. It looks like it works. I made it issue a warning if the path starts with . or .., since the resulting binary will only be runnable from a small selection of subdirectories in that case. I hope this helps someone. :-) --1900020681-993439912-794846390=:21791 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=IRIX5 Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: IRIX5 template JSBDb3B5cmlnaHQgKEMpIDE5ODksIDE5OTIgRGlnaXRhbCBFcXVpcG1lbnQg Q29ycG9yYXRpb24gDQolIEFsbCByaWdodHMgcmVzZXJ2ZWQuDQolIFNlZSB0 aGUgZmlsZSBDT1BZUklHSFQgZm9yIGEgZnVsbCBkZXNjcmlwdGlvbi4NCiUg DQolIExhc3QgTW9kaWZpZWQgT24gRnJpIEZlYiAxMCAxMzoyMjowMyBQU1Qg MTk5NSBieSBrYWxzb3cgIA0KJSAgICAgIE1vZGlmaWVkIE9uIFR1ZSBPY3Qg MjUgMTE6MjM6MDMgUERUIDE5OTQgYnkgZXJpY3YgICANCiUNCiUgU3RhbmRh cmQgY29uZmlndXJhdGlvbiBmaWxlIGZvciBTaWxpY29uIEdyYXBoaWNzIG1h Y2hpbmUNCiUgKE1JUFMxIG9yIE1JUFMyIGFyY2hpdGVjdHVyZSkgcnVubmlu ZyBJcml4IDUuMi4NCiUNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGNvbXBpbGF0aW9uIGVudmlyb25t ZW50IC0tLQ0KDQpyZWFkb25seSBUQVJHRVQgPSAiSVJJWDUiDQpyZWFkb25s eSBERUZBVUxUX0JVSUxEX0RJUiA9IFRBUkdFVA0KDQppbmNsdWRlICgiUExB VEZPUk1TIikgICUgZ2V0IHRoZSB0YXJnZXQtZGVwZW5kZW50IG1hcHBpbmdz DQppbmNsdWRlIChPU19UWVBFKSAgICAgICUgZ2V0IHRoZSBPUy1kZXBlbmRl bnQgZnVuY3Rpb25zDQoNCnJlYWRvbmx5IE5BTUlOR19DT05WRU5USU9OUyA9 ICIwIg0KJSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBvYmplY3QgZmlsZXMgICAgICAgbGlicmFyaWVzDQolICAwPVVuaXggICAg ICAgICAgICAgICAgICAgICAgICAgID0+ICAubyAgIC5pbyAgICAubW8gICAg ICAgbGliWFguYQ0KJSAgMT1Vbml4IHdpdGggYSBncnVtcHkgQyBjb21waWxl ciA9PiAgLm8gICBfaS5vICAgX20ubyAgICAgIGxpYlhYLmENCiUgIDI9V2lu ZG93cy9OVCAgICAgICAgICAgICAgICAgICAgPT4gIC5vYmogLmlvICAgIC5t byAgICAgICBYWC5saWINCiUNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gZXhwb3J0 IHBhdGhzIC0tLQ0KJSBEdXJpbmcgdGhlIGluc3RhbGxhdGlvbiwgZGVzdGlu YXRpb24gZGlyZWN0b3JpZXMgdGhhdCBkbyBub3QgZXhpc3QNCiUgd2lsbCBi ZSBjcmVhdGVkLiAgWW91IG5lZWQgdGhlIG5lY2Vzc2FyeSBwZXJtaXNzaW9u cyB0byBkbyBzbzsgb3RoZXJ3aXNlLA0KJSB0aGUgaW5zdGFsbGF0aW9uIHdp bGwgZmFpbCwgYnV0IGNhbiBiZSByZXN0YXJ0ZWQgYWZ0ZXIgeW91IGhhdmUg DQolIGZpeGVkIHRoZSBwZXJtaXNzaW9ucy4NCg0KDQpJTlNUQUxMX1JPT1Qg PSAiL3Byb2ovZ3JhcGhpY3Mvc29mdHdhcmUvbW9kdWxhMy92My41LjEvIg0K JS0tIGhhbmR5IGZvciBpbnN0YWxsYXRpb25zIHRoYXQga2VlcCBhbGwgTTMg c3R1ZmYgdG9nZXRoZXINCg0KQklOX0lOU1RBTEwgICA9IElOU1RBTExfUk9P VCAmICJiaW4vaXJpeDUiCQklIGV4ZWN1dGFibGVzDQpMSUJfSU5TVEFMTCAg ID0gSU5TVEFMTF9ST09UICYgImxpYi9tMy8iICYgVEFSR0VUCSUgbGlicmFy aWVzDQpET0NfSU5TVEFMTCAgID0gSU5TVEFMTF9ST09UICYgImxpYi9tMy9k b2MiCQklIGRvY3VtZW50cw0KUEtHX0lOU1RBTEwgICA9IElOU1RBTExfUk9P VCAmICJsaWIvbTMvcGtnIgkJJSBwYWNrYWdlcw0KRU1BQ1NfSU5TVEFMTCA9 IElOU1RBTExfUk9PVCAmICJsaWIvZWxpc3AiCQklIGVtYWNzIGxpc3AgY29k ZQ0KTUFOX0lOU1RBTEwgICA9IElOU1RBTExfUk9PVCAmICJtYW4iCQkJJSBt YW4gcGFnZXMNCkhUTUxfSU5TVEFMTCAgPSBJTlNUQUxMX1JPT1QgJiAibGli L20zL3d3dyIJCSUgcHVibGljIGh5cGVydGV4dA0KDQolIFRoZSBtYW51YWwg cGFnZXMgbm9ybWFsbHkgZ28gaW4gc3ViZGlyZWN0b3JpZXMgbWFuezEsLi4u OH0gb2YNCiUgdGhlIE1BTl9JTlNUQUxMIGRpcmVjdG9yeS4gIElmIHlvdSBw cmVmZXIgdG8gaGF2ZSB0aGVtIGFsbCBpbg0KJSBhIHNpbmdsZSBzZWN0aW9u LCBkZWZpbmUgTUFOX1NFQ1RJT04gdG8gYmUgdGhhdCBzZWN0aW9uJ3MgbmFt ZS4NCiUgTUFOX1NFQ1RJT04gPSAibCINCg0KJSBPbiBzb21lIHN5c3RlbXMg KGUuZy4gQUZTKSB5b3UgbXVzdCBpbnN0YWxsIHB1YmxpYyBmaWxlcyBpbiBh IGRpZmZlcmVudA0KJSBwbGFjZSBmcm9tIHdoZXJlIHlvdSB1c2UgdGhlbS4g IElmIHRoYXQgaXMgdGhlIGNhc2UgZm9yIHlvdXIgc3lzdGVtLA0KJSBzcGVj aWZ5IHRoZSAidXNlIiBsb2NhdGlvbiBoZXJlLCBvdGhlcndpc2UgbGVhdmUg dGhlbSBhbG9uZS4NCkJJTl9VU0UgICA9IEJJTl9JTlNUQUxMDQpMSUJfVVNF ICAgPSBMSUJfSU5TVEFMTA0KUEtHX1VTRSAgID0gUEtHX0lOU1RBTEwNCg0K cmVhZG9ubHkgSU5TVEFMTF9JTVBMUyA9ICJUUlVFIg0KJSAiVFJVRSINCiUg ICAgPT4gc2F2ZSBhbGwgc291cmNlIGZpbGVzIGR1cmluZyB0aGUgaW5zdGFs bA0KJSAgICA9PiBtYWtlcyBkZWJ1Z2dpbmcgZWFzaWVyIGFuZCBicm93c2lu ZyBtb3JlIGZydWl0ZnVsDQolICIiIChpLmUuIEZBTFNFKQ0KJSAgICA9PiBz YXZlIG9ubHkgdGhlIGV4cG9ydGVkIGludGVyZmFjZXMgYW5kIHRlbXBsYXRl cyANCiUgICAgPT4gbWFrZXMgdGhlIGluc3RhbGxlZCBzeXN0ZW0gc2xpZ2h0 bHkgc21hbGxlci4NCg0KcmVhZG9ubHkgTkVFRF9PQkpFQ1RTID0gIiINCiUg IlRSVUUiDQolICAgID0+IGFjY3VtdWxhdGUgYSBsaXN0IG9mIGRlcml2ZWQg b2JqZWN0cyBpbiBDT01QSUxFX09CSkVDVFMNCiUgICAgPT4gZm9yIGJ1aWxk aW5nIHNoYXJlZCBsaWJyYXJpZXMgaW4gdGhlIGxpYnJhcnlfaG9va3MgZnVu Y3Rpb24gYmVsb3cNCiUgIiINCiUgICAgPT4gZG9uJ3QgYm90aGVyDQoNCiUt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIFgxMSAtLS0NCiUgSWYgeW91IGhh dmUgWDExUjQgaW5zdGFsbGVkIGFuZCB3b3VsZCBsaWtlIHRoZSBYMTFSNCBi aW5kaW5nIGludGVyZmFjZXMNCiUgdG8gYmUgYnVpbHQsIGRlZmluZSB0aGUg cHJvY2VkdXJlICJpbXBvcnRfWDExUjQiIHRvIGltcG9ydCB0aGUgbGlicmFy aWVzDQolIHRoYXQgYXJlIG5lZWRlZC4gIE90aGVyd2lzZSwgZGVmaW5lICJp bXBvcnRfWDExUjQiIHRvIGJlIGFuIGVtcHR5IHByb2NlZHVyZS4NCiUNCiUg SWYgeW91IHVzZSB0aGUgTUlUIHNlcnZlciB3aXRoIERFQ25ldCBzdXBwb3J0 LCB5b3UgbmVlZCBYMTEgYW5kIGRuZXQsDQolIG90aGVyd2lzZSBYMTEgc2hv dWxkIGJlIGVub3VnaC4NCiUgDQolIFNpbmNlIFgxMVI1IGlzIGFuIGV4dGVu c2lvbiBvZiBYMTFSNCwgeW91IGNhbiB1c2UgdGhlIFgxMVI1IGxpYnJhcmll cw0KJSBpbnN0ZWFkIG9mIFgxMVI0LiAgSG93ZXZlciwgdGhlIE1vZHVsYS0z IGJpbmRpbmcgaW50ZXJmYWNlcyBoYXZlIG5vdA0KJSB5ZXQgYmVlbiB1cGdy YWRlZCB0byBYMTFSNS4NCiUNCg0KcmVhZG9ubHkgcHJvYyBpbXBvcnRfWDEx UjQoKSBpcw0KICBpbXBvcnRfbGliKCJYYXciLCAgIi91c3IvbGliIikNCiAg aW1wb3J0X2xpYigiWG11IiwgICIvdXNyL2xpYiIpDQogIGltcG9ydF9saWIo IlhleHQiLCAiL3Vzci9saWIiKQ0KICBpbXBvcnRfbGliKCJYdCIsICAgIi91 c3IvbGliIikNCiAgaW1wb3J0X2xpYigiWDExIiwgICIvdXNyL2xpYiIpDQpl bmQNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGVtYWNzIC0tLQ0KJSBJ ZiB5b3UgaGF2ZSBlbWFjcyBhbmQgd2FudCB0byBjb21waWxlICIuZWwiIGZp bGVzIHRvICIuZWxjIiBmaWxlcywNCiUgZmlsbCBpbiB0aGUgZnVuY3Rpb24g YmVsb3cuICBPdGhlcndpc2UsIGNvbW1lbnQgb3V0IG9yIGRlbGV0ZSB0aGUN CiUgZW50aXJlIGZ1bmN0aW9uLiAgTm90ZSwgdGhlIGRpc3RyaWJ1dGVkIGNv ZGUgYXNzdW1lcyBnbnVlbWFjcyB2ZXJzaW9uIDE5DQolIG9yIGxhdGVyLg0K DQpyZWFkb25seSBwcm9jIGVtYWNzX2NvbXBpbGUgKGVsKSBpcw0KICBleGVj ICgiZW1hY3MgLWJhdGNoIC1mIGJhdGNoLWJ5dGUtY29tcGlsZSIsIGVsKQ0K ZW5kDQoNCiUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tIEMgY29tcGlsZXIgYW5kIGxpbmtlciAtLS0NCiUg VGhlIGZvbGxvd2luZyBkZWZpbml0aW9ucyBhcmUgdXNlZCB0byBjb21waWxl IGFuZCBsaW5rIEMgbW9kdWxlcy4NCiUgTm90ZSB0aGF0IHRoZXNlIGRlZmlu aXRpb25zIGNhbiBiZSBvdmVycmlkZGVuIG9uIHRoZSBtM2J1aWxkIGNvbW1h bmQNCiUgbGluZSB3aXRoICItRCIuICAoZS5nLiAgbTNidWlsZCAtRENDPWdj YykNCiUNCiUgX2lmZGVmKGEsYixjKSA9PSBpZiBkZWZpbmVkKGEpIHJldHVy biBiIGVsc2UgcmV0dXJuIGMNCiUNCiUgVGhlIGFjdHVhbCBkZWZpbml0aW9u cyBtdXN0IGJlIGtlcHQgb24gb25lIGxpbmUgZHVlIHRvIGZpbmlja3kgZGV0 YWlscw0KJSBvZiB0aGUgYm9vdHN0cmFwIHByb2Nlc3MuDQoNCkNDID0gX2lm ZGVmICgiQ0MiLCBDQywgWyAiL2Jpbi9jYyIsICItRHZmb3JrPWZvcmsiLCAi LWNja3IiIF0pDQolLS0tIEMgY29tcGlsZXIgd2l0aCBmbGFncyBmb3IgY29t cGlsaW5nIGEgc2luZ2xlICIuYyIgZmlsZQ0KDQpMSU5LID0gX2lmZGVmICgi TElOSyIsIExJTkssIFsgIi9iaW4vY2MiLCAiLWNhbGxfc2hhcmVkIiwgIi1X bCwtcnBhdGgsIiAmIExJQl9VU0UgXSkNCg0KJS0tLSBDIGNvbXBpbGVyIHdp dGggZmxhZ3MgZm9yIGxpbmtpbmcNCiUgICAgYW5kIGZpbmQgc2hhcmVkIGxp YnJhcmllcyBpbiB0aGUgaW5zdGFsbGVkIGxpYnJhcnkNCg0KTUFLRUxJQiA9 IF9pZmRlZiAoIk1BS0VMSUIiLCBNQUtFTElCLCBbICIvYmluL2FyIiwgImNy dSIgXSkNCiUtLS0gcHJvZ3JhbSB0byBidWlsZCBsaWJyYXJ5IGFyY2hpdmVz DQoNClJBTkxJQiA9IF9pZmRlZiAoIlJBTkxJQiIsIFJBTkxJQiwgWyAiL3Vz ci9iaW4vdG91Y2giIF0pDQolLS0tIHByb2dyYW0gdG8gaW5kZXggbGlicmFy aWVzDQoNCkFTTSA9IF9pZmRlZiAoIkFTTSIsIEFTTSwgWyAiZ2FzIiBdKQ0K JS0tLSBhc3NlbWJsZXINCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gR05VIHZhcmlh bnRzIC0tLQ0KJSBUaGUgdHdvIGxhcmdlIHBpZWNlcyBvZiBHTlUgc29mdHdh cmUgdXNlZCBieSB0aGUgTW9kdWxhLTMgc3lzdGVtDQolIGdjYyg9bTNjYykg YW5kIGdkYig9bTNnZGIpIG9mdGVuIHJlcXVpcmUgc2xpZ2h0bHkgZGlmZmVy ZW50IEMgY29tcGlsZXJzDQolIG9yIGZsYWdzLiAgVGhleSBhcmUgc3BlY2lm aWVkIGhlcmUuICBOb3RlIHRoYXQgdGhleSBtYXkgYmUgb3ZlcnJpZGRlbg0K JSBmcm9tIHRoZSBtM2J1aWxkIGNvbW1hbmQgbGluZS4NCiUNCiUgVG8gdXNl IHRoZSBHTlUgZGVmYXVsdHMgZm9yIENDIGFuZCBDRkxBR1MsIHNwZWNpZnkg IioiLg0KJQ0KDQpHTlVfQ0MgICAgID0gX2lmZGVmICgiR05VX0NDIiwgICAg IEdOVV9DQywgICAgICIqIikNCkdOVV9DRkxBR1MgPSBfaWZkZWYgKCJHTlVf Q0ZMQUdTIiwgR05VX0NGTEFHUywgIioiKQ0KR05VX01BS0UgICA9IF9pZmRl ZiAoIkdOVV9NQUtFIiwgICBHTlVfTUFLRSwgICAibWFrZSIpDQoNCiUtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLSBNb2R1bGEtMyBjb21waWxlciAtLS0NCiUgVGhlIHN5bnRheCBm b3IgdGhlIHZhbHVlcyBwYXNzZWQgdG8gbW9zdCBvZiB0aGUgTTNfQ09ORklH IG9wdGlvbnMgaXMNCiUgIkBwZ21AYXJnMUAuLi5AYXJnbkAiIHdoZXJlICJA IiBpcyBhbiBhcmJpdHJhcnkgY2hhcmFjdGVyLiAgVGhlDQolIHNlcGFyYXRv ciBjaGFyYWN0ZXIgbXVzdCBiZWdpbiBhbmQgZW5kIHRoZSB2YWx1ZS4NCg0K JSBXaGVyZSBpcyB0aGUgZHJpdmVyPw0KTTMgPSBMSUJfVVNFICYgIi9tMyIN Cg0KJSBXaGF0IGFyZSB0aGUgc3RhbmRhcmQgZmxhZ3M/DQpNM09QVElPTlMg PSBbICItdzEiLCAiLXdoeSIsICItZyIgXQ0KDQpNM19DT05GSUcgPSBbDQog ICAiLVkxIiAmIF9wYWNrX2FyZ3MgKENDKSwNCiAgICItWTIiICYgX3BhY2tf YXJncyAoTElOSyksDQogICAiLVkzIiAmIF9wYWNrX2FyZ3MgKE1BS0VMSUIp LA0KICAgIi1ZNCIgJiBfcGFja19hcmdzIChSQU5MSUIpLA0KICAgIi1ZNyIg JiBfcGFja19hcmdzIChBU00pLA0KDQogICAiLVk2QCIgJiBMSUJfVVNFICYg Ii9tM2NnYzFALXF1aWV0QCIsDQogICAlIC0tLSB0aGUgTW9kdWxhLTMgSUwg dG8gYXNzZW1ibHkgbGFuZ3VhZ2UgcGFzcw0KDQogICAiLXoyQC1sbUAiLCAg JSAtLS0gbGlicmFyaWVzIHN5c3RlbWF0aWNhbGx5IGxpbmtlZCB3aXRoIGFs bCBwcm9ncmFtcw0KDQogICAiLXozIiAmIExJQl9VU0UgJiBTTCAmICJyZXBv cnRfY292ZXJhZ2UubyIsDQogICAlIC0tLSBsaWJyYXJ5IGxpbmtlZCBpbiBw cm9ncmFtcyBjb21waWxlZCB3aXRoICItWiIgY292ZXJhZ2Ugb3B0aW9uDQoN CiAgICItejUiICYgTkFNSU5HX0NPTlZFTlRJT05TLA0KICAgJSBTZXQgdGhl IGhvc3QgbmFtaW5nIGNvbnZlbnRpb25zLg0KDQogICAiLXo2MCIsDQogICAl IFZhbHVlcyBvZiAiLXo2IjoNCiAgICUgICAiMCIgPT4gdGhlIG0zIGRyaXZl ciB3aWxsIHNwbGl0IGxpYnJhcnkgbmFtZXMgYW5kIHBhc3MgLUwvLWwNCiAg ICUgICAgICAgICAgYXJndW1lbnRzIHRvIHRoZSBsaW5rZXINCiAgICUgICAi MSIgPT4gdGhlIG0zIGRyaXZlciB3aWxsIHBhc3MgbGlicmFyaWVzIHdpdGgg ZnVsbCBwYXRoIG5hbWVzDQogICAlICAgIjIiID0+IGxpa2UgIjAiIGV4Y2Vw dCB0aGF0IGZvciBzaGFyZWQgbGlicmFyaWVzLCB0aGUgZHJpdmVyDQogICAl ICAgICAgICAgIHBhc3NlcyAtUmRpciBhcyB3ZWxsIGFzIC1MZGlyIHRvIHRo ZSBsaW5rZXINCg0KICAgIi16QTAiLA0KICAgJSBUaGUgIi16QSIgb3B0aW9u IHNwZWNpZmllcyB0aGUgbWF4aW11bSBzaXplIChpbiBtZWdhYnl0ZXMpIHRo YXQgUGFzczANCiAgICUgaXMgYWxsb3dlZCB0byByZWFjaCBhcyBhIHBlcnNp c3RlbnQgc2VydmVyIGJlZm9yZSB0aGUgZHJpdmVyIGtpbGxzIGl0Lg0KICAg JSBTZXR0aW5nIGl0IHRvIHplcm8gZGlzYWJsZXMgc2VydmVyIG1vZGUuDQog ICAlIE5PVEU6IHRoZSBjdXJyZW50IGNvbXBpbGVyIGlzIGJ1Z2d5LCBsZWF2 ZSAiLXpBIiBhbG9uZSENCg0KICAgIi16QkAtTzJAIiwgICUgLS0tIHBhc3Mg MSBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0KICAgIi16Q0AtTzJAIiwgICUg LS0tIHBhc3MgNiBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0KICAgIi16REAt TzJAIiwgICUgLS0tIHBhc3MgNyBvcHRpb25zIGltcGxpZWQgYnkgIi1PIg0K DQogICAiLXpFQC1nQCIsICAlIC0tLSBwYXNzIDEgb3B0aW9ucyBpbXBsaWVk IGJ5ICItZyINCiAgICItekZALWdAIiwgICUgLS0tIHBhc3MgNiBvcHRpb25z IGltcGxpZWQgYnkgIi1nIg0KICAgIi16R0BAIiwgICUgLS0tIHBhc3MgNyBv cHRpb25zIGltcGxpZWQgYnkgIi1nIg0KICAgJSAtLS0gRm9yIElSSVgsIHlv dSBtdXN0IHVwZ3JhZGUgdG8gZ2NjIDIuNi4wIHRvIGdldCBkZWJ1Z2dpbmcg c3VwcG9ydC4NCg0KICAgIi16SCIgJiBOQU1JTkdfQ09OVkVOVElPTlMsDQog ICAlIC0tLSB0aGUgdGFyZ2V0J3MgbmFtaW5nIGNvbnZlbnRpb25zDQoNCiAg ICItekkiICYgVEFSR0VULA0KICAgJSAtLS0gdGhlIHRhcmdldCBhcmNoaXRl Y3R1cmUNCg0KICAgJSAiLXpKMTAiLA0KICAgJSBUaGUgb3B0aW9uICItekp4 MSIgc3BlY2lmaWVzIHRoYXQgcGFzcyAieCIgaXMgIm5vaXN5IiwgIi16Sngw Ig0KICAgJSBzcGVjaWZpY2VzIHRoYXQgaXQncyBub3QuICBUaGUgZGVmYXVs dCBpcyB0byBhc3N1bWUgdGhhdCBwYXNzZXMNCiAgICUgYXJlIG5vdCBub2lz eS4gIFRoZSBkcml2ZXIgY29sbGVjdHMgdGhlIHN0YW5kYXJkIG91dHB1dCBv ZiBub2lzeQ0KICAgJSBwYXNzZXMgaW4gYSBmaWxlIGFuZCB0aGVuIGRlbGV0 ZXMgdGhlIGZpbGUsIHVubGVzcyAiLWtlZXAiIG9yDQogICAlICItdmVyYm9z ZSIgaXMgc3BlY2lmaWVkLg0KDQogICAiLXpLMCIsDQogICAlIC0tLSBTZXQg dGhlIHZhbHVlIG9mICIteksiIHRvICIxIiBpZiB5b3Ugd2FudCB0aGUgbTMg ZHJpdmVyIHRvDQogICAlICAgICBzdXBwbHkgLUJkeW5hbWljLy1Cc3RhdGlj IG9wdGlvbnMgdG8gdGhlIGxpbmtlciwgIjAiIG90aGVyd2lzZS4NCg0KICAg Ii1CZHluYW1pYyIsDQogICAlIC0tLSBsaWJyYXJpZXMgYXJlIHNoYXJlZCBi eSBkZWZhdWx0LiAgSWYgeW91IGdpdmUgLXpLMSB5b3Ugc2hvdWxkDQogICAl ICAgICBhbHNvIHByb3ZpZGUgYW4gaW5pdGlhbCAtQmR5bmFtaWMgb3IgLUJz dGF0aWMuDQoNCiAgICItekwwIg0KICAgJSAtLS0gU2V0IHRoZSB2YWx1ZSBv ZiAiLXpMIiB0byAiMSIgaWYgeW91IHdhbnQgLk0zTElOSyBmaWxlcyBwcm9k dWNlZA0KICAgJSAgICAgZm9yIGEgZHluYW1pYyBsb2FkZXINCl0NCg0KJSB1 c2VkIGJ5IHRoZSBzdHVmZiBiZWxvdy4NCk0zX1NUQU5EQUxPTkUgPSAiIg0K DQpwcm9jIGJ1aWxkX3N0YW5kYWxvbmUoKSBpcw0KICAgJSAtLS0gcmVzZXQg dGhlIGxpbmtlciB0byBhdm9pZCBzaGFyZWQgbGlicmFyaWVzLg0KICAgTTNf Q09ORklHICs9ICItWTJAL2Jpbi9jY0AtV2wsLUIsc3RhdGljQCINCiAgIE0z X1NUQU5EQUxPTkUgPSAieWVzIg0KZW5kDQoNCnByb2MgYnVpbGRfbm9kZWJ1 ZygpIGlzDQogICAlIFVzZSB0aGUgZ2NjIGRpc3RyaWJ1dGlvbiB0aGF0IGNv bWVzIHdpdGggTTMgKDIuNS43KSAtLSB0aGlzDQogICAlIHZlcnNpb24gb2Yg Z2NjIGRvZXMgbm90IHN1cHBvcnQgZGVidWdnaW5nIG9uIElyaXgsIGJ1dCBp cw0KICAgJSBwcm9iYWJseSBiZXR0ZXIgZGVidWdnZWQgdGhhbiBnY2MgMi42 LjANCiAgIE0zX0NPTkZJRyArPSAiLVk2QCIgJiBMSUJfVVNFICYgIi9tM2Nn YzEtMi41LjdALXF1aWV0QCINCmVuZA0KDQpwcm9jIGJ1aWxkX3NoYXJlZCgp IGlzDQogICAlIC0tLSByZXNldCB0aGUgbGlua2VyIHRvIHVzZSBzaGFyZWQg bGlicmFyaWVzLg0KICAgTTNfQ09ORklHICs9ICItWTJAL2Jpbi9jY0AtY2Fs bF9zaGFyZWRALVdsLC1ycGF0aCwiICYgTElCX1VTRSAmICJAIg0KICAgTTNf U1RBTkRBTE9ORSA9ICIiDQplbmQNCg0KJS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tIGhvb2tzIC0tLQ0KJSBUaGVzZSBhcmUgdGhlICJsYXN0IGNoYW5jZSIg aG9va3MgdGhhdCBhcmUgY2FsbGVkIGVhY2ggdGltZSBhIGxpYnJhcnkNCiUg b3IgcHJvZ3JhbSBpcyBidWlsdC4gIFRoZXkgbWlnaHQgYnVpbGQgc2hhcmVk IGxpYnJhcmllcyBvciBzdHJpcA0KJSBleGVjdXRhYmxlcy4uLg0KDQpwcm9j IGJlZm9yZV9saWJyYXJ5X2hvb2tzKHgpIGlzDQplbmQNCg0KcHJvYyBhZnRl cl9saWJyYXJ5X2hvb2tzKHgpIGlzDQogIGxvY2FsIGxpYl9hICA9IGZvcm1h dCAoImxpYiVzLmEiLCB4KQ0KICBsb2NhbCBsaWJfc28gPSBmb3JtYXQgKCJs aWIlcy5zbyIsIHgpDQogIGlmIGRlZmluZWQgKCJfYWxsIikNCiAgICBpZiBz dGFsZSAobGliX2EsIGxpYl9hKQ0KICAgICAgd3JpdGUgKCJtaXNzaW5nICIs IGxpYl9hLCAiOiBub3QgYnVpbGRpbmcgIiwgbGliX3NvLCBDUikNCiAgICBl bHNlDQogICAgICBpZiBzdGFsZSAobGliX3NvLCBsaWJfYSkNCiAgICAgICAg ZXhlYyAoImxkIC1zaGFyZWQgLWlnbm9yZV91bnJlc29sdmVkIC1vIiwgbGli X3NvLCAiLWFsbCIsIGxpYl9hLA0KICAgICAgICAgICAgICAgIi1ub25lIiwg SU1QT1JUX0xJQlMsIE9USEVSX0xJQlNfTCwgIi1sbSAtbGMiKQ0KICAgICAg ZW5kDQogICAgICBpbnN0YWxsX2Rlcml2ZWQgKGxpYl9zbykNCiAgICAgIGlu c3RhbGxfbGlua190b19kZXJpdmVkIChsaWJfc28sIExJQl9JTlNUQUxMKQ0K ICAgIGVuZA0KICBlbmQNCiAgZGVyaXZlZHMgKGxpYl9zbywgbm9fZXh0ZW5z aW9uKQ0KICBkZXJpdmVkcyAoInNvX2xvY2F0aW9ucyIsIG5vX2V4dGVuc2lv bikNCmVuZA0KDQpwcm9jIGJlZm9yZV9wcm9ncmFtX2hvb2tzKHgpIGlzDQog ICBsb2NhbCBhcnIgPSAiIg0KDQogICBpZiBub3QgTTNfU1RBTkRBTE9ORQ0K ICAgICAgIGZvcmVhY2ggb3YgaW4gUEtHX09WRVJSSURFUw0KCSBpZiBub3Qg ZXF1YWwobm9ybWFsaXplKCIuLiIsIFBLR19DQUNIRXtvdn0pLCBQS0dfQ0FD SEV7b3Z9KSBvciBub3QgZXF1YWwobm9ybWFsaXplKCIuIiwgUEtHX0NBQ0hF e292fSksIFBLR19DQUNIRXtvdn0pIA0KICAgICAgICAgICAgd3JpdGUgKCJt M2J1aWxkOiByZWxhdGl2ZSBvdmVycmlkZSgiLCBQS0dfQ0FDSEV7b3Z9LCAi KSBtYXkgY2F1c2UgcHJvYmxlbXMgaWYgcGFja2FnZSBjb250YWlucyBhIHNo YXJlZCBsaWJyYXJ5IiwgQ1IpDQogICAgICAgICBlbmQNCiAgICAgICAgIGFy ciA9IGFyciAmIFBLR19DQUNIRXtvdn0gJiBTTCAmIFRBUkdFVCAmICI6Ig0K ICAgICAgIGVuZA0KICAgICAgIE0zX0NPTkZJRyArPSAiLVkyQC9iaW4vY2NA LWNhbGxfc2hhcmVkQC1XbCwtcnBhdGgsIiAmIGFyciAmIExJQl9VU0UgJiAi QCINCiAgIGVuZA0KZW5kDQoNCnByb2MgYWZ0ZXJfcHJvZ3JhbV9ob29rcyh4 KSBpcw0KZW5kDQoNCiUtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIGluc3RhbGxhdGlvbiAt LS0NCiUgImluc3RhbGxfZmlsZSIgaXMgY2FsbGVkIGR1cmluZyBhbiAibTNi dWlsZCBpbnN0YWxsIiBmb3INCiUgZWFjaCBmaWxlIHRoYXQgbmVlZGVkcyB0 byBiZSBleHRlcm5hbGx5IGV4cG9ydGVkLg0KDQpyZWFkb25seSBwcm9jIGlu c3RhbGxfZmlsZSAoc3JjLCBkZXN0LCBtb2RlKSBpcw0KICBOb3RlX2luc3Rh bGwgKHNyYywgZGVzdCkNCiAgZXhlYyAoIkBjcCAtcCIsIHNyYywgZGVzdCkN CiAgJSBleGVjICgiaW5zdGFsbCAtYyAtbSIsIG1vZGUsIHNyYywgZGVzdCkN CmVuZA0KDQolLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSB0aGUgcmVzdCBvZiB0aGUgZW52aXJvbm1lbnQgLS0tDQoN CmlmIGRlZmluZWQoIl9ib290c3RyYXAiKSBpbmNsdWRlKCJDT01NT04uQk9P VCIpIGVuZA0KaW5jbHVkZSAoIkNPTU1PTiIpDQoNCg== --1900020681-993439912-794846390=:21791-- ======================================================================= 61 === Date: 10 Mar 1995 22:20:24 GMT From: dmoen@mks.com (Doug Moen) Subject: VAR parameters and garbage collection There is an interesting interaction between VAR parameters and garbage collection. The usual implementation of VAR parameters is to pass the address of the designator that is given as the actual parameter. But, the designator might designate a field in the middle of a record object R in the traced heap. If so, then the formal parameter will be bound to a pointer into the middle of R. What happens if a garbage collection occurs during this procedure call? a) It could be that this pointer into the middle of R is the last reference to R at the time of the garbage collection. The collector had better recognize this; if R is collected, then a subsequent assignment to the formal parameter could corrupt the heap. b) If a copying garbage collector is used, then the pointer into the middle of R will need to be updated if R is moved. The only garbage collector that I know of that is capable of recognizing pointers into the middle of an object is Hans Boehm's conservative garbage collector. (Are there any others?) If your garbage collector is not capable of recognizing pointers into the middle of an object, then you could represent a VAR parameter as an (address, offset) pair, where the address points to the beginning of the object. If you don't do either of the above two things, then VAR parameters will be unsafe to use. How does the SRC Modula 3 compiler deal with this issue? ======================================================================= 62 === Date: 10 Mar 1995 14:47:19 GMT From: heinze@i41s5.ira.uka.de (Ernst A. Heinz) Subject: READONLY Revisited Let me add my personal opinion to the previous thread about READONLY: As for software engineering reasons, Modula-3 would greatly benefit from two READONLY syntax additions with non-uniform semantics. Although the latter is generally undesirable, its benefits seem to prevail in this special case. 1. Decl = (READONLY | VAR) VariableDecl {";" VariableDecl} ";" . 2. Binding = [READONLY] Id "=" Expr . The first rule allows for READONLY variable declarations and the second for READONLY bindings in WITH statements. Whereas the semantics of READONLY bindings are straightforward, I propose the following non-uniform, i.e. context sensitive, semantics for READONLY variable declarations. 1.1 READONLY variables declared in interfaces must neither be used as nor bound to writable designators by client modules importing the interface. However, modules exporting the interface may freely do so. 1.2 READONLY variables declared in non-interface blocks (i.e. all others) have to be initialized upon declaration and, subsequently, must neither be used as nor bound to writable designators. I feel that the above semnatics exactly capture what Modula-3 programmers long for --- any comments welcome! Of course, I know that proposing new language features is very easy as compared to the effort of their actual implementation. Any volunteers out there on the net? Cheers. =Ernst= -- +--------------------------------------------------------+-------------------+ | Ernst A. Heinz (email: heinze@ira.uka.de) | | | Institut fuer Programmstrukturen und Datenorganisation | Make it as simple | | Fakultaet fuer Informatik, Universitaet Karlsruhe | as possible, but | | Postfach 6980, D-76128 Karlsruhe, F.R. Germany | not simpler. | | (Voice: ++49/(0)721/6084386, FAX: ++49/(0)721/694092) | | +--------------------------------------------------------+-------------------+ "It has recently been found out that research causes cancer in rats!" ======================================================================= 63 === Date: 11 Mar 1995 09:07:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Why no multiple inheritance in Modula-3? chase@centerline.com wrote on 06.03.95 in <3jfes7$pbd@wcap.centerline.com>: > ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes: > > I have looked at the language definition of Modula-3, and I see that it > > only allows single inheritance. Are there any reasons for this except for > > the obvious complication in implementing it? > > There's non-obvious complications in defining its interactions with > the rest of the language. Also, people tried programming in it > with single inheritance, and ported code written using multiple > inheritance, and decided that the lack of MI was a tolerable > deficiency. That's not the same thing as "not a deficiency". > Read on to find out (some reasons) why it was left out. [implementation difficulties deleted] Don't forget the third type of reason - keeping the language definition short and clear. I've yet to see a definition of multiple inheritance (complete with clarification of all ramifications) that meets these criteria. It may well be impossible to do. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 64 === Date: 11 Mar 1995 22:44:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Problems building 3.5.1/boot-LINUX dagenais@notung.vlsi.polymtl.ca wrote on 09.03.95 in : > There are more bugs than that in the dll tools. Look into > ftp.vlsi.polymtl.ca:pub/m3/linux for a "fixed" version of tools-2.11. > Although it is older than 2.16, it has worked quite well. Last time > I checked, newer versions of tools did not include all my bug fixes. So I tried that one ... unfortunately, the results seem to me to be a lot worse than what I had! I think my slightly-patched 2.16 is a much better prospect than your massively-patched 2.11 ... No complete listing this time, as it's more than 100 KB ... [...] /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MM_DateLinux.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__MI_DragonInt.s /opt/m3/m3/m3core/LINUX/jump/_GVAR_libm3core__L_2.s /opt/m3/m3/m3core/LINUX/jump/_GCMN_libm3core__L_2.s /usr/dll/bin/getsize: no source file for symbol '_L_2' /usr/dll/bin/mkimage -f -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 - - jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc mkimage v2.11 Warning - non-absolute pathname specified for library Reading configuration files from /opt/m3/m3/m3core/LINUX/jump Recording new library parameters. executing:ld -x -T 64400000 -o libm3core.so.3.5 /opt/m3/m3/m3core/LINUX/jump/__ jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-linux/2.5.8 -lgcc -lc jumpas/BasicCtypes.io: Undefined symbol "_MI_BasicCtypes" referenced jumpas/CConvert.io: Undefined symbol "_MI_CConvert" referenced jumpas/CConvert.mo: Undefined symbol "_MM_CConvert" referenced jumpas/Cerrno.io: Undefined symbol "_MI_Cerrno" referenced jumpas/Convert.io: Undefined symbol "_MI_Convert" referenced Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference d from text segment Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta ck referenced from text segment Convert.m3:20 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta ck referenced from text segment Convert.m3:51 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference d from text segment Convert.m3:67 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference d from text segment Convert.m3:79 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert reference d from text segment Convert.m3:79 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks reference d from text segment Convert.m3:86 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference d from text segment Convert.m3:93 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta ck referenced from text segment Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert reference d from text segment Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta ck referenced from text segment Convert.m3:97 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSta ck referenced from text segment Convert.m3:113 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc ed from text segment Convert.m3:122 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc ed from text segment Convert.m3:122 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:128 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc ed from text segment Convert.m3:135 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt ack referenced from text segment Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc ed from text segment Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt ack referenced from text segment Convert.m3:139 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt ack referenced from text segment Convert.m3:144 (jumpas/Convert.mo): Undefined symbol __GOT__RTThread__handlerSt ack referenced from text segment Convert.m3:155 (jumpas/Convert.mo): Undefined symbol __GOT__MM_Convert referenc ed from text segment Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__RTThread__handle rStack refs follow Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__MM_Convert refs follow Convert.m3:204 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:249 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:486 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:488 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:492 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc ed from text segment Convert.m3:492 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:508 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:510 (jumpas/Convert.mo): Undefined symbol __GOT__MI_RTHooks referenc ed from text segment Convert.m3:514 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc ed from text segment Convert.m3:0 (jumpas/Convert.mo): More undefined symbol __GOT__MI_RTHooks refs follow Convert.m3:536 (jumpas/Convert.mo): Undefined symbol __GOT__MI_Convert referenc ed from text segment jumpas/Convert.mo: Undefined symbol "_MM_Convert" referenced jumpas/Csetjmp.io: Undefined symbol "_MI_Csetjmp" referenced jumpas/Csignal.io: Undefined symbol "_MI_Csignal" referenced jumpas/Cstdarg.io: Undefined symbol "_MI_Cstdarg" referenced jumpas/Cstdarg.mo: Undefined symbol "_MM_Cstdarg" referenced jumpas/Cstddef.io: Undefined symbol "_MI_Cstddef" referenced jumpas/Cstdio.io: Undefined symbol "_MI_Cstdio" referenced Cstdio.m3:10 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f rom text segment Cstdio.m3:11 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f rom text segment Cstdio.m3:12 (jumpas/Cstdio.mo): Undefined symbol __GOT__MI_Cstdio referenced f rom text segment jumpas/Cstdio.mo: Undefined symbol "_MM_Cstdio" referenced jumpas/Cstdlib.io: Undefined symbol "_MI_Cstdlib" referenced jumpas/Cstring.io: Undefined symbol "_MI_Cstring" referenced jumpas/Ctypes.io: Undefined symbol "_MI_Ctypes" referenced jumpas/Date.io: Undefined symbol "_MI_Date" referenced DateLinux.m3:27 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_TimePosix ref erenced from text segment DateLinux.m3:28 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:41 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:46 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:61 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc ed from text segment DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:13 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc ed from text segment DateLinux.m3:67 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc ed from text segment DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc ed from text segment DateLinux.m3:68 (jumpas/DateLinux.mo): Undefined symbol __GOT__MI_Date referenc ed from text segment DateLinux.m3:69 (jumpas/DateLinux.mo): Undefined symbol __GOT__MM_DateLinux ref erenced from text segment jumpas/DateLinux.mo: Undefined symbol "_MM_DateLinux" referenced jumpas/DragonInt.io: Undefined symbol "_MI_DragonInt" referenced DragonInt.m3:42 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt ref erenced from text segment DragonInt.m3:44 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt ref erenced from text segment DragonInt.m3:345 (jumpas/DragonInt.mo): Undefined symbol __GOT__MI_DragonInt re ferenced from text segment DragonInt.m3:382 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt re ferenced from text segment DragonInt.m3:397 (jumpas/DragonInt.mo): Undefined symbol __GOT__MM_DragonInt re ferenced from text segment jumpas/DragonInt.mo: Undefined symbol "_MM_DragonInt" referenced jumpas/DragonT.io: Undefined symbol "_MI_DragonT" referenced DragonT.m3:37 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen ced from text segment DragonT.m3:40 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen ced from text segment DragonT.m3:42 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen ced from text segment DragonT.m3:43 (jumpas/DragonT.mo): Undefined symbol __GOT__MI_DragonInt referen ced from text segment [... and so on ...] UnsafeHash.m3:273 (jumpas/UnsafeHash.mo): Undefined symbol __GOT__MM_UnsafeHash referenced from text segment UnsafeHash.m3:276 (jumpas/UnsafeHash.mo): Undefined symbol __GOT__MM_UnsafeHash referenced from text segment UnsafeHash.m3:0 (jumpas/UnsafeHash.mo): More undefined symbol __GOT__MM_UnsafeH ash refs follow jumpas/UnsafeHash.mo: Undefined symbol "_MM_UnsafeHash" referenced jumpas/Uprocess.io: Undefined symbol "_MI_Uprocess" referenced jumpas/Upwd.io: Undefined symbol "_MI_Upwd" referenced jumpas/Uresource.io: Undefined symbol "_MI_Uresource" referenced jumpas/Usem.io: Undefined symbol "_MI_Usem" referenced jumpas/Ushm.io: Undefined symbol "_MI_Ushm" referenced jumpas/Usignal.io: Undefined symbol "_MI_Usignal" referenced Usignal.m3:17 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference d from text segment Usignal.m3:18 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference d from text segment Usignal.m3:19 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference d from text segment Usignal.m3:20 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference d from text segment Usignal.m3:21 (jumpas/Usignal.mo): Undefined symbol __GOT__MI_Usignal reference d from text segment jumpas/Usignal.mo: Undefined symbol "_MM_Usignal" referenced jumpas/Usocket.io: Undefined symbol "_MI_Usocket" referenced jumpas/Ustat.io: Undefined symbol "_MI_Ustat" referenced jumpas/Usyslog.io: Undefined symbol "_MI_Usyslog" referenced jumpas/Utime.io: Undefined symbol "_MI_Utime" referenced jumpas/Utypes.io: Undefined symbol "_MI_Utypes" referenced Utypes.m3:59 (jumpas/Utypes.mo): Undefined symbol __GOT__MM_Utypes referenced f rom text segment jumpas/Utypes.mo: Undefined symbol "_MM_Utypes" referenced jumpas/Uugid.io: Undefined symbol "_MI_Uugid" referenced jumpas/Uuio.io: Undefined symbol "_MI_Uuio" referenced jumpas/Uutmp.io: Undefined symbol "_MI_Uutmp" referenced jumpas/WeakRef.io: Undefined symbol "_MI_WeakRef" referenced WeakRef.m3:15 (jumpas/WeakRef.mo): Undefined symbol __GOT__MI_RTWeakRef referen ced from text segment WeakRef.m3:20 (jumpas/WeakRef.mo): Undefined symbol __GOT__MI_RTWeakRef referen ced from text segment jumpas/WeakRef.mo: Undefined symbol "_MM_WeakRef" referenced jumpas/Word.io: Undefined symbol "_MI_Word" referenced Word.m3:48 (jumpas/Word.mo): Undefined symbol __GOT__MM_Word referenced from te xt segment jumpas/Word.mo: Undefined symbol "_MM_Word" referenced ../src/Csupport/Common/hand.c:168 (jumpas/cca02744.o): Undefined symbol __GOT__ tables_built referenced from text segment ../src/Csupport/Common/hand.c:174 (jumpas/cca02744.o): Undefined symbol __GOT__ LoBits referenced from text segment ../src/Csupport/Common/hand.c:180 (jumpas/cca02744.o): Undefined symbol __GOT__ HiBits referenced from text segment ../src/Csupport/Common/hand.c:195 (jumpas/cca02744.o): Undefined symbol __GOT__ tables_built referenced from text segment ../src/Csupport/Common/hand.c:200 (jumpas/cca02744.o): Undefined symbol __GOT__ HiBits referenced from text segment ../src/Csupport/Common/hand.c:200 (jumpas/cca02744.o): Undefined symbol __GOT__ LoBits referenced from text segment ../src/Csupport/Common/hand.c:202 (jumpas/cca02744.o): Undefined symbol __GOT__ HiBits referenced from text segment ../src/Csupport/Common/hand.c:203 (jumpas/cca02744.o): Undefined symbol __GOT__ HiBits referenced from text segment ../src/Csupport/Common/hand.c:204 (jumpas/cca02744.o): Undefined symbol __GOT__ LoBits referenced from text segment jumpas/cca02744.o: Undefined symbol "_tables_built" referenced jumpas/cca02744.o: Undefined symbol "_LoBits" referenced jumpas/cca02744.o: Undefined symbol "_HiBits" referenced jumpas/cca02797.o: Undefined symbol "_MI_M3_BUILTIN" referenced jumpas/cca02955.o: Undefined symbol "_ThreadF__myId" referenced jumpas/cca02955.o: Undefined symbol "_RT0u__inCritical" referenced jumpas/cca02955.o: Undefined symbol "_RTThread__handlerStack" referenced system: No such file or directory /usr/dll/bin/mkimage: error running 'ld -x -T 64400000 -o libm3core.so.3.5 /opt /m3/m3/m3core/LINUX/jump/__jump.o jumpas/*o -lm -lc -L /usr/lib/gcc-lib/i486-li nux/2.5.8 -lgcc -lc' /usr/dll/bin/mkstubs -l libm3core -v 3.5 -a 0x64400000 -j 0x4000 -g 0x2000 -- l ibm3core mkstubs v2.11 Warning - non-absolute pathname specified for library Reading configuration files from /opt/m3/m3/m3core/LINUX/jump libm3core.sa: ___libm3core_3_500, cca02744, cca02750, cca02955, sequencing, don e verify v2.11 (experimental) jumpkit: Unable to open libm3core.so.3.5 *** error code 1 "/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: command execute fail ed *** call stack *** "/opt/SRCm3/lib/m3/pkg/m3build/templates/LINUX", line 315: call to built-in exe c "/opt/m3/m3/m3core/src/m3makefile", line 960: call to procedure after_library_h ooks "/opt/SRCm3/lib/m3/pkg/m3build/templates/COMMON", line 1: call to procedure lib rary "/opt/m3/m3/m3core/src/m3makefile", line 42: call to procedure Library m3build: /opt/SRCm3/bin/quake failed (status = 256) *** error code 255 "/opt/m3/m3/src/m3makefile", line 41: command execute failed *** call stack *** "/opt/m3/m3/src/m3makefile", line 41: call to built-in exec "/opt/m3/m3/src/m3makefile", line 63: call to procedure BuildChunk m3build: /opt/SRCm3/bin/quake failed (status = 256) khms[tty1]:/opt/m3/m3# exit exit Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 65 === Date: 11 Mar 1995 11:44:55 GMT From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: VAR parameters and garbage collection Doug Moen (dmoen@mks.com) wrote: > If your garbage collector is not capable of recognizing pointers into the > middle of an object, then you could represent a VAR parameter as an > (address, offset) pair, where the address points to the beginning of the > object. Another way to do this is to save the address of the object in the caller's stack frame. That's relatively easy to implement and probably doesn't cause much overhead. This could even be implemented for languages without builtin garbage collection support (like C[++]) as a source transformation. I guess it should be more efficient than having to recognize pointers to the middle of objects, as long as you don't want to move objects. ------------------------------------------------------------------------------ * wonder everyday * nothing in particular * all is special * Marc Wachowitz ======================================================================= 66 === Date: 11 Mar 1995 11:52:52 GMT From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz) Subject: Re: Why no multiple inheritance in Modula-3? Kai Henningsen (kai@khms.westfalen.de) wrote: > I've yet to see a definition of multiple inheritance > (complete with clarification of all ramifications) that meets these > criteria. It may well be impossible to do. It shouldn't be too difficult if one defines inheritance (multiple or not) as a combination of including transformed source code and message passing. If one requires that naming conflicts must be resolved explicitly (as soon as the clash would occur, not at the place of calls) it doesn't become too complicated. ------------------------------------------------------------------------------ * wonder everyday * nothing in particular * all is special * Marc Wachowitz ======================================================================= 67 === Date: 12 Mar 1995 11:37:35 GMT From: mako@FNALA.FNAL.GOV (Makoto Shimojima, Univ of Tsukuba/CDF) Subject: Re: READONLY Revisited > 1.1 READONLY variables declared in interfaces must neither be used as nor > bound to writable designators by client modules importing the interface. > However, modules exporting the interface may freely do so. The Oberon language has readonly exports. It would be interesting to see how they implemented it. mako ======================================================================= 68 === Date: 12 Mar 1995 13:34:17 GMT From: dmoen@mks.com (Doug Moen) Subject: Re: try-finally-except Taj Khattra wrote: >Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead >of a single TRY-FINALLY-EXCEPT statement ? > >Is the following case the main reason why ? > > TRY > RAISE e; > FINALLY > IF (foobar) RAISE e; > EXCEPT > e => (* this may or may not be executed *) > END > >I am trying to write a Modula-3 like exception handling mechanism >for ANSI C (based on Eric Robert's package) and am trying to justify >to myself why I should have both TRY-EXCEPT and TRY-FINALLY instead >of just TRY-FINALLY-EXCEPT. I wrote an exception handling mechanism for C several years ago. The design evolved over a three-year period, with feedback from about a dozen other people using the package on a daily basis. (It is described in the Summer 1992 Usenix conference proceedings.) My package supports the following structure (with slightly different syntax): TRY THEN_TRY THEN_TRY EXCEPT END You could repeat the 'THEN_TRY' part zero or more times. Each is executed in sequence. If is terminated by an exception, then execution resumes at . After all of the statement lists have been executed, if any of them raised an exception, then the handler is invoked on the *first* (not the last) exception that was raised by any of the statement lists. Here is a typical use of this generalized TRY statement: f1 = f2 = NULL; TRY f1 = efopen(file1, mode1); f2 = efopen(file2, mode2); THEN_TRY efclose(f1); THEN_TRY efclose(f2); EXCEPT END efopen() and efclose() are wrappers for fopen() and fclose() that raise an exception on error. efclose() ignores a NULL argument. In this example (which is typical), it is the first exception raised that is of most interest to the exception handler. Subsequent exceptions, if they occur, might be side effects of the original exception, and you don't want these follow on exceptions to mask the original exception. In Modula-3, TRY s1 FINALLY s2 END reraises the exception from s2 if both s1 and s2 raise an exception. In my experience (which is based on using C with exceptions, not Modula-3), this is the opposite of what you normally want. Can anyone offer a rationale? ======================================================================= 69 === Date: 11 Mar 95 09:40:43 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: try-finally-except In article <3jod1t$9rh@wolfe.wimsey.com> taj@vanbc.wimsey.com (Taj Khattra) wri tes: : I don't think the answer is that deep: most of the time, you need : either TRY-EXCEPT or TRY-FINALLY, but not both. Modula-3's design : philosophy was to provide simple language features, so both were : provided individually. I agree that if most of the time either TRY-EXCEPT or TRY-FINALLY, but not both, are used, then having both is better than a single TRY-FINALLY-EXCEPT statement. But, I thought [that TRY-FINALLY-EXCEPT] would be quite common, [...]. I tend to think the difference is deeper than Alan points out. It boils down to a difference in programmer's expectation: Modula-3 programmer writes code assuming automatic garbage collection, while the C programmer needs to account for the memory used upon an exception. This hit me when I read Alan writing: TRY-FINALLY is provided if some "clean up" action must be taken --- such as closing a file --- even in if an exception has occurred. I suspect that in C, the most important form of clean up upon an exception is freeing memory. I am guessing this is why Taj is feeling that TRY-EXCEPT-FINALLY has been so important: he frees memory there. Alan goes on to say: An important example of this is the LOCK statement [...] I speculate that for the miniscule portion of C programmers who do multi-threaded programming, the second-most popular usage of FINALLY is to unlock locks. In Modula-3, you are doing multi-threaded stuff all the time, so if the LOCK statement didn't exist in M3, you'd be doing FINALLY's all the time to unlock locks. Hence the syntactic sugar in Modula-3. Later, Taj says: So I guess all I've ended up worrying about is whether or not to provide some "syntactic sugar", not knowing if it would be used often enough in practice to be worth the trouble. Other than dealing with external systems resources like files handles, I am guessing that TRY-FINALLY would be used more in unsafe modules than safe ones. I looked around some packages to informally test this hypothesis. If you look at unsafe modules in ui/src/xvbt for example, you see that there is a lot of TRY-FINALLYs to do DISPOSEs or Exits. As Modula-3 encourages safety and simplicity, the designers' choice makes more sense. Forgive me for a possible over-generalization, but I think this illustrates the abstraction power of a strong synergy between garbage collection, threads and exceptions that we asume in Modula-3 which is not present in many other languages. -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 70 === Date: 12 Mar 1995 17:36:18 GMT From: adiwan@cs.cmu.edu (Amer Diwan) Subject: Re: VAR parameters and garbage collection Our scheme (reference given below) deals with derived pointers by having the compiler generate tables describing each derived pointer at each program point where garbage collection might occur. The garbage collector uses these tables to ensure that when an object is copied, all derived pointers that reference it are properly updated. Derived pointers include pointers to the middle of objects (such as var parameters, pointers created by the WITH statement, etc.) and pointers outside the referenced object (such as those created by some compiler optimizations, eg., those that compute a virtual array base to reference an array). Reference: Compiler Support for Garbage Collection in a Statically Typed Language , Amer Diwan, Eliot Moss, and Richard Hudson. SIGPLAN Conference on Programming Language Design and Implementation '92, pp. 273-282. Also available from: http://osl-www.cs.umass.edu/~oos/home.html Amer ------------------------------------------------------------------------------ Amer Diwan Department of Computer Science Object Systems Lab University of Massachusetts diwan@cs.umass.edu Amherst, MA 01003 (413) 545-0256 http://www.cs.umass.edu/~diwan/home.html ======================================================================= 71 === Date: Sun, 12 Mar 1995 18:31:09 GMT From: wolfmom@netcom.com (Jennifer York) Subject: Generating an exception from a signal? Greetings. I'm wondering if it possible to generate an exception in reponse to a UNIX signal (say, SIGSEGV or SIGILL). Obviously, it wouldn't be possible to continue code from inside the signal handler, but I was wondering if Modula-3 might handle something like this (preferably in a (semi-)system independent fasion). If it makes a difference, the apllication I'm thinking about working on would be a somewhat dynamic system that would allow various users to add code to the executable and run it. I would like to be able to ensure that the added code does not cause the system to crash. Any help, suggestions, etc., would be welcome. Joel Newsgroups: comp.lang.modula-3 Subject: Possible to generate exceptions from signal? Summary: Followup-To: Distribution: world Organization: NETCOM On-line Communication Services (408 261-4700 guest) Keywords: Greetings. I'm wondering if it possible to generate an exception in reponse to a UNIX signal (say, SIGSEGV or SIGILL). Obviously, it wouldn't be possible to continue code from inside the signal handler, but I was wondering if Modula-3 might handle something like this (preferably in a (semi-)system independent fasion). If it makes a difference, the apllication I'm thinking about working on would be a somewhat dynamic system that would allow various users to add code to the executable and run it. I would like to be able to ensure that the added code does not cause the system to crash. Any help, suggestions, etc., would be welcome. Joel ======================================================================= 72 === Date: Sun, 12 Mar 1995 22:28:57 GMT From: gasboy@eskimo.com (Dan Wilder) Subject: Re: Why no multiple inheritance in Modula-3? kai@khms.westfalen.de (Kai Henningsen) writes: >chase@centerline.com wrote on 06.03.95 in <3jfes7$pbd@wcap.centerline.com>: >> ohk@hal.nta.no (Ole-Hjalmar Kristensen TF.E/DELAB) writes: >> > I have looked at the language definition of Modula-3, and I see that it >> > only allows single inheritance. Are there any reasons for this except for >> > the obvious complication in implementing it? >[stuff deleted] >Don't forget the third type of reason - keeping the language definition >short and clear. I've yet to see a definition of multiple inheritance >(complete with clarification of all ramifications) that meets these >criteria. It may well be impossible to do. Have you looked into the Eiffel handling of MI? Not sure quite what would pass "short," Eiffel stuff runs more than a few sentences, but by most accounts it passes "clear." Certainly some of the most serious ramifications, the name collision and diamond (repeat) inheritance problems, are dealt with quite simply, one might say summarily. For the most part the subobject reference problem is not a problem in Eiffel, though this is probably because objects are not structures there. So, depending again on just how demanding your "short and clear" is, it might be fair to say here is a counterexample illustrating it is indeed possible to do. Which is not, of course, to say it belongs in M3, just that being impossible might not be the best reason for leaving it out. --- Dan Wilder ======================================================================= 73 === Date: 12 Mar 1995 18:32:15 -0700 From: jmacnish@CS.Arizona.EDU (J MacNish) Subject: Generics and getting them to instantiate I'm having a problem getting a linked list generic to work. I realize there is a predefined List generic, but I want my own doubly-linked list. I am trying desperately to follow the example in Harbison's _Modula-3_ book, on page 193, and am using the SRC M3 compiler. If I am reading it correctly, you would create 6 files(all straight from the example) Integer.m3 Integer.i3 IList.m3 IList.i3 List.ig List.mg and then a file to use the list, say count.m3 I have all these files, copied straight out of the book for the most part, and then I have an M3 makefile like: import ("libm3") Generic_module("List") Module("IntegerE") Module("IList") implementation ("count") program ("count") IntegerE is exactly like the "Integer" module & interface the example describes on pg 193, but is renamed so that I don't get a name clash (?) with the Integer interface in (I am guessing) libm3. The compiler chokes on the two modules that supposedly instantiate it: IntegerE and IList with: "../src/IList.i3", line 1: syntax error: missing 'END' "../src/IList.i3", line 1: Initial module name doesn't match final name () 2 errors encountered new source -> compiling ../src/IntegerE.m3 "../src/IntegerE.m3", line 1: syntax error: missing 'BEGIN' "../src/IntegerE.m3", line 2: Initial module name doesn't match final name (, gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) writes: : >douglm@rpi.edu writes: : > > A more general solution might be some extension to the network objects : > > package which allows us to register our own new thread routine. One : > > parameter would be the typecode of the object for which the thread is : > > required (at least). : > > : >Another solution that doesn't require any changes to the network object's : >interfaces or runtime is for you to fork off your own thread in those cases : >where you know that you will need a large stack. That is, the method : >implementation in your server forks off a thread of its own with the size : >that you choose. It's a little more work on your part, but doesn't require : >any changes to the current interfaces. : But if you are passing complicated structures around, the Pickle : packacge may well exceed the available stack space whilst unmarshalling : parameters, before the user code is reached. Can't you get round this by providing a special Pickle agent, which calls you back first ? ( I forget the exact terminology, but for particular object types, you can tell pickle to call your code instead of the default ). : Paul : -- : Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk : 'One of its satellites, a green and insignificant planet, is now dead' Joel Cynicism, sarcasm, psychosis ======================================================================= 75 === Date: 13 Mar 1995 08:18:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Problems building 3.5.1/boot-LINUX kai@khms.westfalen.de wrote on 11.03.95 in <5heGuV7EcsB@khms.westfalen.de>: > So I tried that one ... unfortunately, the results seem to me to be a lot > worse than what I had! I think my slightly-patched 2.16 is a much better > prospect than your massively-patched 2.11 ... I think I got it now ... mostly. I'm still not through compiling, though - this is one big monster. Bundles still seem to exhibit some problems. Most problems I found so far are the parsing code in the dll tools - it's mighty sloppy. I think after I'm through, I'll make my version of tools 2.16 available somewhere. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ======================================================================= 76 === Date: 13 Mar 1995 10:57:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Why no multiple inheritance in Modula-3? gasboy@eskimo.com wrote on 12.03.95 in : > Have you looked into the Eiffel handling of MI? Yes, but that's been a long time ago - I don't remember any of it, so I can't comment on it. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 77 === Date: 13 Mar 1995 15:23:49 GMT From: chase@centerline.com (David Chase) Subject: Re: Why no multiple inheritance in Modula-3? gasboy@eskimo.com (Dan Wilder) writes: > kai@khms.westfalen.de (Kai Henningsen) writes: > >Don't forget the third type of reason - keeping the language definition > >short and clear. I've yet to see a definition of multiple inheritance > >(complete with clarification of all ramifications) that meets these > >criteria. It may well be impossible to do. > Have you looked into the Eiffel handling of MI? > Not sure quite what would pass "short," Eiffel stuff runs more > than a few sentences, but by most accounts it passes "clear." > Certainly some of the most serious ramifications, the name collision > and diamond (repeat) inheritance problems, are dealt with quite simply, > one might say summarily. It could be clearer. I'd worry about how they (Eiffel rules) interact with opaque inheritance, and how they interact with mix-in style programming. I gather that this is not what B. Meyer had in mind when he designed Eiffel, so mix-ins may not work well in Eiffel (I may gather wrongly), of course. David ======================================================================= 78 === Date: 13 Mar 1995 15:06:34 GMT From: chase@centerline.com (David Chase) Subject: Re: Language definition (overrides) Why? What purpose does this serve? How does this interact with the rest of the language? Do you have a proposed implementation technique for this change to the language? And, again, why? Can you at least motivate this change? Simply saying "I can't do this, but if I made this change to the language, then I could" is all well and good, but that holds for many things (complex numbers, unbounded integers, non-contiguous subarrays, distributed arrays on MPPs, first-class functions, method closures, continuations, inheritance among exception types, operator overloading, constrained generics ...). I suspect that this also might make programs slightly less readable -- whenever I say "O.m" I know that the function from the method suite is being referred to. Whenever I say "T.m" I know that the function statically bound to type T is being referred to (and it is my understanding that if T <: S, and T overrides method m visible in S, then T.m gets me the overriding method, even though the function name is not visible to me). I think this would also violate the reference manual rule, in that it would increase the size of the reference manual out of all proportion to its usefulness. Sorry for the skeptical tone, but I'm skeptical. My tendency is to resist changes to the language, even those there's quite a few changes I'd like to make myself (everything in the list above except continuations and operator overloading), and one that I even hope to propose when I get the time to write it up properly. I have similar reservations about your "READONLY" proposal -- as near as I can tell, it has only local effects (i.e., does not assist in the building of large systems or the reuse of code). If this was of tremendous concern to you, I might lobby for a pragma, but this seems like a tiny frob. It provides only minor assistance in the generation of efficient code, since it's fairly easy for an optimizer to verify that a variable is only assigned to once. yours, David Chase ======================================================================= 79 === Date: 13 Mar 95 09:09:32 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: looking for possibly existing generics The Set that I was looking for, would have been as consistent as possible, with the language's builtin set for Ordinal Types. Sure I can create this from the generic List, but there is plenty of room for procedural name conflicts between individual creation of this structure. What I mean, is ... Believe me, this has been more than a major pain-in-the-you-know-what for my group in our C++ work, and I would hate to see something similar happen to Modula-3 once enough people start using it and encounter more and more library "clashes". It has been so difficult to switch to a new library ... Hmm, I guess that I've rambled on a bit. From what I've learned so far of Modula-3 I've been pretty pleased. It's not the end-all language, but I can see where it would be the logical choice over C++ in many instances, and a potential loser in others. There are some pretty good arguments in there. It is of course difficult to strike the perfect balance between "simplicity and generality" and "adequation to the task and specialization". My proposition would be to collect interesting modules such that everyone knows what is available and therefore reduce/avoid duplication, and insure that proper feedback helps module designers improve their interface (implementation optimization can come gradually). The "wish list" section of the FAQ wanted to be a step in that direction. Perhaps i should put a more explicit entry in the FAQ saying: please contribute any interesting module you have to xxx, and insure that some people provide useful feedback. Note that DEC SRC has always been willing to receive such contributions but it does not seem to be a very popular channel. Something more interactive with an automated submission procedure (a forms being filled through the World Wide Web to insert a new module in the library database) may be more appealing. I will try to come up with something. The user base outside SRC seems to have grown quite a bit recently and it may be time to install an efficient module "sharing" mechanism. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 80 === Date: 13 Mar 1995 13:26:57 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Re: Network objects, threads and stacks In article , joel@bris.ac.uk (Joel Crisp) writes: >Paul Menage (pbm1001@cam.ac.uk) wrote: >: In article <9502281543.AA28627@cloyd.East.Sun.COM>, gwyant@cloyd.East.Sun.CO M (Geoffrey Wyant - Sun Microsystems Labs BOS) writes: >: >douglm@rpi.edu writes: >: > > A more general solution might be some extension to the network objects >: > > package which allows us to register our own new thread routine. One >: > > parameter would be the typecode of the object for which the thread is >: > > required (at least). >: > > >: >Another solution that doesn't require any changes to the network object's >: >interfaces or runtime is for you to fork off your own thread in those cases >: >where you know that you will need a large stack. That is, the method >: >implementation in your server forks off a thread of its own with the size >: >that you choose. It's a little more work on your part, but doesn't require >: >any changes to the current interfaces. > >: But if you are passing complicated structures around, the Pickle >: packacge may well exceed the available stack space whilst unmarshalling >: parameters, before the user code is reached. > >Can't you get round this by providing a special Pickle agent, which >calls you back first ? ( I forget the exact terminology, but for >particular object types, you can tell pickle to call your code instead >of the default ). > Yes, but it's a hassle, and tends to defeat the effect of having transparent access to network objects. Something like NetObj.MinDefaultStackSize() would be useful ( and can be simulated by calling Thread.MinDefaultStackSize(). ). Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 81 === Date: Mon, 13 Mar 95 23:29:10 GMT From: dh1@ukc.ac.uk (D.Hunt) Subject: FormsVBT Browsers and FileBrowsers We have a problem and we are hoping that someone out there can help. We are using FormsVBT to create a GUI for a small Modula 3 program. What we require is a Browser that acts like a FileBrowser, but the contents of the Browser are a limited number of filenames (that are the result of a search.) We have an S-expression that we believe will do the job, but we are trying to write the underlying Modula 3 code. The documentation that we have is sketchy at best and the only example program that we have is so complicated and involved that we cannot even find out what structure the Browser takes. We could appreciate any help that could be given, especially if anyone has a small example program that creates at runtime a variable length list and puts it into a Browser, that they could let us have a copy of. If it deals with the results of the Browser selection, all the better! Thanks for any help you can give David Hunt -- == Babylon 5 Mantra: == == Ivanova is always right. I will listen to Ivanova. I will not == == ignore Ivanova's recommendations. Ivanova is God. And if this == == ever happens again, Ivanova will personally rip your lungs out! == ======================================================================= 82 === Date: 14 Mar 1995 00:37:51 GMT From: jason_jb@postoffice.utas.edu.au (Idio) Subject: --- pascal user wants to know... --- Hiya! I just wanna know what the main imrovements that modula3 has over Modula2 and Pascal. Also, are there any good (ie:*fast* with good interface) for m3 which might compare with Borland Pascal ?? I love Pascal for it's structure and neatness (well ... it can be!) and hate C for similar reasons, so if m3 is any imrovment over Pascal then I might give it a try! ta ======================================================================= 83 === Date: Mon, 13 Mar 95 18:17:38 -0800 From: heydon@pa.dec.com Subject: Re: FormsVBT Browsers and FileBrowsers David Hunt writes: > What we require is a Browser that acts like a File Browser, but the > contents of the Browser are a limited number of filenames (that are > the result of a search.) > > We have an S-expression that we believe will do the job, but we are > trying to write the underlying Modula 3 code. The documentation that > we have is sketchy at best and the only example program that we have > is so complicated and involved that we cannot even find out what > structure the Browser takes. > > We could appreciate any help that could be given, especially if > anyone has a small example program that creates at runtime a variable > length list and puts it into a Browser, that they could let us have a > copy of. If it deals with the results of the Browser selection, all > the better! I don't know if this is what you're looking for, but it may give you a start. I have a program that reads a list of filenames from a file, sorts them, and then displays them in a FormsVBT "Browser". In my FormsVBT ".fv" file, the "Browser" is named "moduleBrowser": (Browser %moduleBrowser) In my Modula-3 code, I use the "Lex" interface to read names from a file, and "TextList.Cons" to prepend each name to a "TextList.T" (the details of this parsing are omitted here). Then I use the "ListSort" interface to sort the names and call a "FillBrowser" procedure to insert the sorted names into the browser: VAR modList: TextList.T; BEGIN (* Parse file here -- prepend each name to "modList" *) FillBrowser(FormsVBT.GetVBT(w, "moduleBrowser"), TextListSort.SortD(modList)); END; (In this code, "w" is the top-level "FormsVBT.T" window that contains the "Browser" component.) A FormsVBT "Browser" component corresponds to the Modula-3 type "ListVBT.T". Here is the "FillBrowser" procedure: PROCEDURE FillBrowser(v: ListVBT.T; modList: TextList.T) = (* Prepend the names in "modList" to "v". *) VAR i := 0; BEGIN v.insertCells(0, TextList.Length(modList)); WHILE modList # NIL DO v.setValue(i, modList.head); modList := modList.tail; INC(i) END END FillBrowser; As the comment says, this procedure *prepends* the names to the list. If the "ListVBT.T" is new, it will be empty initially, so this procedure will set the browser to contain exactly the names in "modList" (in order). If the "ListVBT.T" "v" already contains some names, you can delete them by writing: v.removeCells(0, v.count()); See the "ListVBT" interface for details. You will need to attach a Modula-3 callback procedure to the "Browser" (using "FormsVBT.AttachProc") to respond when the user selects one of the filenames. I hope this helps. Let me know if you have any other questions. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 84 === Date: 13 Mar 1995 14:57:55 GMT From: mbk@.seas.ucla.edu (Kennel) Subject: Re: Why no multiple inheritance in Modula-3? Kai Henningsen (kai@khms.westfalen.de) wrote: > gasboy@eskimo.com wrote on 12.03.95 in : > > Have you looked into the Eiffel handling of MI? > Yes, but that's been a long time ago - I don't remember any of it, so I > can't comment on it. Also see Sather, related to Eiffel. (http://www.icsi.berkeley.edu/Sather) Because it has implementation inheritance which does not imply subtyping, and subtyping which does not imply inheritance, the definition of each is quite clear and without hidden traps, even allowing for multiple inheritance and multiple subtyping. > Kai > -- > Internet: kh@ms.maus.de, kai@khms.westfalen.de > Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} > ## CrossPoint v3.02 ## ======================================================================= 85 === Date: Tue, 14 Mar 1995 08:35:09 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: re: --- pascal user wants to know... --- jason_jb@postoffice.utas.edu.au writes: > > Hiya! > > I just wanna know what the main imrovements that modula3 has over > Modula2 > and Pascal. > Also, are there any good (ie:*fast* with good interface) for m3 which > might > compare with Borland Pascal ?? > > I love Pascal for it's structure and neatness (well ... it can be!) > and hate C for similar reasons, so if m3 is any imrovment over Pascal > then > I might give it a try! > > ta Well, Modula-3 takes the basic Modula-2 structure and adds to it: 1. Exceptions 2. Garbage collection 3. Seperation of safe from unsafe code 4. Generic interfaces and modules 5. Threads, mutexes, and condition variable 6. dynamic typing (in addition to the normal static typing) 7. Object types I think those constitute the main language differences. There is an implementation that is freely available in source form that is being done by Digital Equipment Corporation's Systems Research Center (DEC SRC). The compiler is moderately fast, and there is a lot of work going on to speed it up. There is currently no Borland style GUI/IDE available, though there are several projects in the works to provide such a thing. The implementation provides a fairly well document and large set of libraries. There is a library for creating multithread GUIs together with a simple interactive GUI layout tool. There are libraries for peristent and distributed programming, and an embeddable distributed scripting language. The implementation can be gotten via anonymous ftp from: gatekeeper.dec.com:/pub/DEC/Modula-3/release-3.5.1 Geoff Wyant Geoff.Wyant@east.sun.com Sun Microsystems Laboratories, Inc. 2 Elizabeth Drive Chelmsford, Ma. 01824 ======================================================================= 86 === Date: 14 Mar 95 09:25:46 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: --- pascal user wants to know... --- I just wanna know what the main imrovements that modula3 has over Modula2 and Pascal. Modula-3 has Objects, generics, exception handling and garbage collection. For more details, check the FAQ at ftp.vlsi.polymtl.ca:pub/m3/m3-faq.ps Also, are there any good (ie:*fast* with good interface) for m3 which might compare with Borland Pascal ?? The current compiler on Unix platforms is reasonably fast, at least when compared with C++ compilers :-), although it goes through a GCC based backend. The compiler with the integrated backend, currently available on Windows NT and Windows 9X but hopefully soon on other platforms, is REAL FAST. The next step will be a nice graphical shell around the compiler and debugger. I know of a few people starting to work towards this but nothing is available as of yet. (A few people have expressed interest in working on modifying the NT386 integrated backend for LINUX ELF but no one had the time to do it until a few weeks. For a LINUX/80386 guru this may be a relatively small job of a few days, any takers?). -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 87 === Date: Tue, 14 Mar 1995 10:41:51 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Stacks overflows Stack overflows are a major concern when attempting to develop a reliable system. The nasty aspect of overflow is that it can go undetected for some time allowing programs to run incorrectly. The addition of guard pages to the end of the stack can be defeated by routines with a large stack frame which hops over the guard page into the unprotected memory following. Even when it does fail it's fairly unhelpful. What I usually see on the SPARC is Illegal Instruction or random segmentation faults. If what I say above is correct, then stack overflow presents a threat to program integrity, more so as we make increased use of threads. The point of all this, (other than to make people feel uneasy), is to ask what thought has been given to run time stack checking? I have seen this in action in an environment where it was probably much more difficult to implement and it worked well. Stack checking would involve a little extra overhead on program entry and thread switching but I feel the improvement in error reporting and reliability make it worthwhile. ======================================================================= 88 === Date: 14 Mar 1995 15:03:54 GMT From: bm@play.cs.columbia.edu (Blair MacIntyre) Subject: Re: looking for possibly existing generics >>>>> On 13 Mar 95 09:09:32, dagenais@notung.vlsi.polymtl.ca (Michel >>>>> Dagenais) said: Michel> My proposition would be to collect interesting modules such Michel> that everyone knows what is available and therefore Michel> reduce/avoid duplication, and insure that proper feedback Michel> helps module designers improve their interface (implementation Michel> optimization can come gradually). What I'm starting to do is put any potentially useful, standalone packages I write in a directory, run "m3browser" on the hierarchy, and attach it to my web page. We could do something similar, where anybody who wants to contribute a package submits it, we just put it in the directory tree, and less than 30 minutes later (m3browser default rescan interval) it's on the web. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 89 === Date: 14 Mar 95 08:46:18 From: nayeri@gte.com (Farshad Nayeri) Subject: Re: looking for possibly existing generics I agree with Spencer Allain and Michel that it is a good idea to settle on at least interfaces (and I would hope good implementations) to the basic generic types now, so that these trivial incompatibilities can be avoided later when they may affect many people. SRC Modula-3 libraries are one of its strengths, and it is important that it would stay that way. Generic datatypes are also easy to contribute, as they are well-separated from the core of the language, and well-understood problem by many. Michel goes on to say: Note that DEC SRC has always been willing to receive such contributions but it does not seem to be a very popular channel. Something more interactive with an automated submission procedure (a forms being filled through the World Wide Web to insert a new module in the library database) may be more appealing. I have often wondered about the lack of library contributions outside SRC. I think this is an important issue, because if Modula-3 is to become really popular, it needs the "power of multiples", as the case is for systems such as Linux, and tcl/Tk. Note that there is much outside contribution for porting to different systems. I personally don't tend to think it has as much to do with the lack of sharing mechanism. I can think of some other reasons, though: - The existing "core" libraries are quite nice and complete in many areas, as compared to many other *single* environments. The mode-of-operation for many Modula-3 programmers is just "get their work done" as was noted before on this group. - This "perfect balance between simplicity and generality" is hard to strike for many people outside SRC! Or at least outsiders may feel this, so they tend to not distribute what they have. I think to some extent, this push for "perfection" intimidates some people. (I hate to say this, but I think it is true.) - Possibly the type of people contributing; they may have been less application-programmer types, or numerical-programmer types and more systems-programmer types. (Whatever this means.) - Various company (and university) policies for outside distribution of developed programs. I think companies and people who are worried about "intellectual property" worry less about releasing porting information and bug reports than new library releases. Coupled with SRC releasing solid libraries, this tends to provide for less motivation for individuals within organizations to release code. - Lack of communication about priorities. This thread, Bill's todo list, and Michel's wanted list are good steps in resolving some of the issues, but you never know if SRC (or outside SRC for that matter) is going to release something next time that does exactly what your package does. I guess this is lack of communication is a backlash against vaporware, but maybe it is too far back? I am not saying this is SRC's responsibility , I am just observing that I have seen this happen. - Ratio of outside contributors to SRC contributors (just a speculation) - We are not considering summer intern contributions as outside contributions. VideoVBT, Visual Obliq, portions of Obliq, among other packages were written by summer visitors working with SRC folks. (May just be a technicality, but I do think it has to do with the points I made about communication and perfection.) I am not saying any of these are "bad", they just "are". I imagine some of these may have to change if Modula-3 is going to become "popular". -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 90 === Date: Wed, 15 Mar 1995 09:33:36 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: Stack overflows >Mike Douglass writes: > > Stack overflows are a major concern ... >Geoff Wyant writes >I think the addition of stack boundary checking would be good, though I'm >concerned about the cost, especially in the face of multithreading. I don't >know if you can get the stack end in a cheap manner on entry to a procedure. >Most processors don't keep that information in a register. > >How often do you see gaurd pages not being touched on a stack overflow ? > >Actually right now, I don't think the runtime allocates gaurd pages for >any thread. That might be a useful starting point for OSs with the >appropriate VM primitives. > I have experienced stack checking implemented in a relatively unfriendly environment, that is an operating system written many years ago where most of the system didn't follow any noticable coding convention. Furthermore, asyncronous entries could occur in routines as the result of system events, interrupts etc. However we managed to graft onto that a stack oriented run-time system which handled the problems of asynchronous entry into routines with the correct stack and global environment. I cannot remember all of the details but stack checking involved having a stack descriptor which was accessible at a known location (global base actually) and checking the current stack pointer against the top of the stack. The overhead is relatively low. I would guess that, machine architecture permitting, it would be easier to implement in Modula3 because we have more control over the run time environment. ======================================================================= 91 === Date: Wed, 15 Mar 1995 10:31:13 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: Re: Stack overflows Mike Douglass writes: > >Mike Douglass writes: > > > Stack overflows are a major concern ... > >Geoff Wyant writes > >I think the addition of stack boundary checking would be good, though I'm > >concerned about the cost, especially in the face of multithreading. I don't > >know if you can get the stack end in a cheap manner on entry to a procedure . > >Most processors don't keep that information in a register. > > > >How often do you see gaurd pages not being touched on a stack overflow ? > > > >Actually right now, I don't think the runtime allocates gaurd pages for > >any thread. That might be a useful starting point for OSs with the > >appropriate VM primitives. > > > > I have experienced stack checking implemented in a relatively unfriendly > environment, that is an operating system written many years ago where most > of the system didn't follow any noticable coding convention. Furthermore, > asyncronous entries could occur in routines as the result of system events, > interrupts etc. > > However we managed to graft onto that a stack oriented run-time system > which handled the problems of asynchronous entry into routines with the > correct stack and global environment. > > I cannot remember all of the details but stack checking involved having a > stack descriptor which was accessible at a known location (global base > actually) and checking the current stack pointer against the top of the > stack. > > The overhead is relatively low. > > I would guess that, machine architecture permitting, it would be easier to > implement in Modula3 because we have more control over the run time > environment. > > Thinking about it some more, it seems like it should be relatively straightforward. What you want is to have instantaneous access to the stack bounds (or at least how big the stack is allowed to grow). The easiest way to do this is to dedicate a register to it, which I suspect the code generator could do pretty easily. You wouldn't get stack checking when calling into a non-M3 routine, but at least you would have an indication of where it might have occurred. On a RISC machine, it is probabl y reasonable to do this, but it might create register pressure on the x86 architecture. Does the x86 maintain stack bounds in a register anyway ? If you can't put it in a register, then it may too expensive to do. On a machine with kernel support for threads, especially running on a multiprocessor , there isn't a single global variable where you could stick this information. You'd have to do some sort of table lookup based on the current thread to get this information or make an OS/system call to get it (on Solaris-2 and N T there is thread private storage where it could be stored), but the overhead would not be very acceptable, I suspect. When a thread is created, you would need to set the stack limit register which, while system dependent, is relatively straightforward for all but the root thre ad, since it is the runtime that allocates the thread stacks. The root thread stack is allocated by the OS, and it may not be possible to get the stack bounds for it. Under Solaris-2 it is, but I don't think it is for SunOS. I don't know about other OS 's. I don't know how hard it is to make the code generator generate code that is depe ndent on the target OS. It may be fairly straightforward. Bill K. do you know ? --geoff ======================================================================= 92 === Date: Thu, 16 Mar 1995 01:18:19 GMT From: nagle@netcom.com (John Nagle) Subject: Re: Stacks overflows douglm@rpi.edu (Mike Douglass) writes: >The point of all this, (other than to make people feel uneasy), is to ask >what thought has been given to run time stack checking? I have seen this in >action in an environment where it was probably much more difficult to >implement and it worked well. If each stack is in a separate segment, the hardware should do it for you. There are certain advantages to not having a flat address space. John Nagle ======================================================================= 93 === Date: Thu, 16 Mar 95 00:23:44 GMT From: ic4@ukc.ac.uk (I.Chatzigiannakis) Subject: Undefined number of arguments Do you have any idea how I can make a procedure that accepts many arguments without a preset number. I know how to code it in c++ (void myfunc(char *format,...)) but what about modula-3? Thanks for the help Yannis ======================================================================= 94 === Date: 16 Mar 1995 01:22:16 GMT From: birdi@ponder.csci.unt.edu (Arvinder S. Birdi ) Subject: m3makefiles, libraries Hello, I have just started using m3build. I can create simple m3makefiles that generate one item. (ie either one executable program or one library). Is it possible to have one m3makefile generate multiple executable files and libraries? thanks -birdi -- /////////////////////////////////////////////////////////////////////////////// )\& &/( ---oQQo-- (^) --oQQo--- U ======================================================================= 95 === Date: 16 Mar 1995 03:57:52 GMT From: schaub@ponder.csci.unt.edu (Stephen Schaub) Subject: Re: Undefined number of arguments I.Chatzigiannakis (ic4@ukc.ac.uk) wrote: : Do you have any idea how I can make a procedure that accepts many : arguments without a preset number. : I know how to code it in c++ (void myfunc(char *format,...)) but : what about modula-3? : Thanks for the help : Yannis As far as I know, Modula-3 doesn't permit this, but you can simulate it nicely under certain circumstances using default parameters. For an example, see the Fmt interface, particularly the F routine, defined as follows: PROCEDURE F(fmt: TEXT; t1, t2, t3, t4, t5: TEXT := NIL) : TEXT; This allows the user to call the routine like this: IO.Put(Fmt.F("Hello\n")); or IO.Put(Fmt.F("Hello, %s\n", name)); (* is a TEXT variable *) or IO.Put(Fmt.F("%s: %s\n", name, Fmt.Int(35))); Then the common way to deal with such a situation in, say, the definition of F, is to put all the parameters in an array so you can index them conveniently like this: PROCEDURE F(fmt: TEXT; t1, t2, t3, t4, t5: TEXT := NIL) : TEXT = VAR txtArr := ARRAY [1..5] OF TEXT{t1, t2, t3, t4, t5}; BEGIN FOR i := FIRST(txtArr) TO LAST(txtArr) DO IF txtArr[i] = NIL THEN EXIT END; ... END END F; It's a really nice example of how parameter defaults and array constructors can work together to provide high-level support for variable parameters without having to mess around with low-level stack stuff as is required in C/C++. Stephen Schaub schaub@cs.unt.edu ======================================================================= 96 === Date: Thu, 16 Mar 95 12:32:51 GMT From: buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409) Subject: Re: Stack overflows Geoffrey Wyant - Sun Microsystems Labs BOS (gwyant@cloyd.East.Sun.COM) wrote: : Mike Douglass writes: : > >Mike Douglass writes: : > > > Stack overflows are a major concern ... : > >Geoff Wyant writes : > >I think the addition of stack boundary checking would be good, though I'm : > >concerned about the cost, especially in the face of multithreading. I don 't : > >know if you can get the stack end in a cheap manner on entry to a procedu re. : > : > I cannot remember all of the details but stack checking involved having a : > stack descriptor which was accessible at a known location (global base : > actually) and checking the current stack pointer against the top of the : > stack. : > : > The overhead is relatively low. : Thinking about it some more, it seems like it should be relatively : straightforward. What you want is to have instantaneous access to the : stack bounds (or at least how big the stack is allowed to grow). The : easiest way to do this is to dedicate a register to it, which I suspect : the code generator could do pretty easily. You wouldn't get stack : checking when calling into a non-M3 routine, but at least you would have : an indication of where it might have occurred. On a RISC machine, it is proba bly : reasonable to do this, but it might create register pressure on the x86 : architecture. Does the x86 maintain stack bounds in a register anyway ? yes, there is a special segment register for the stack. You can have all necessary checking in hardware (It still takes time!) : If you can't put it in a register, then it may too expensive to do. On a : machine with kernel support for threads, especially running on a multiprocess or, : there isn't a single global variable where you could stick this information. : You'd have to do some sort of table lookup based on the current thread : to get this information or make an OS/system call to get it (on Solaris-2 and NT : there is thread private storage where it could be stored), but the overhead : would not be very acceptable, I suspect. If you want the stack bound in a register, you may become very processordependant. For every processor, there may be a fast and usable solution. But you 'll need a different one for every processorarchitecture. Guard pages are straight forward. Should be the same semantics on every paged mmu. Hope you have OS support for using them. If procedurecalls do not happen too frequently, a simple compare on procedure entry (and maybe exit) should be fast enough. You 'll need three to five loads and a compare. The stack bound can be kept in the thread global dataspace, and you don't sacrifice a register. possible Algorithm: r1 := thread id r2 := thread global dataspace [r1] r3 := offset of stack bound [r2] r4 := [r3] compare r4 and sp Ok, three to five loads isn't nothing, but shouldn't hurt to much as a generic implementation. If you want it faster, you 'll have to become processor specific. So how fast do you need it? Tschuess Andreas -- #include /|) Andreas Buschmann /-|) SEL Stuttgart US/END buschman@lts.sel.alcatel.d ======================================================================= 97 === Date: Thu, 16 Mar 1995 15:17:54 -0500 From: gwyant@cloyd.East.Sun.COM (Geoffrey Wyant - Sun Microsystems Labs BOS) Subject: re: stack checking Andreas Buschmann writes: > If you want the stack bound in a register, you may become very > processordependant. For every processor, there may be a fast and > usable solution. But you 'll need a different one for every > processorarchitecture. > The code generator could take care of some of this. Setting the register would be done in the runtime at thread startup. This would entail a little machine-specific code, but only a couple of lines. The runtime is already factored to support this. > Guard pages are straight forward. Should be the same semantics on > every paged mmu. Hope you have OS support for using them. > This whole discussion started because Mike Douglass felt that gaurd pages weren't sufficient. I don't know how frequently they fail in practice, > If procedurecalls do not happen too frequently, a simple compare on > procedure entry (and maybe exit) should be fast enough. You 'll need > three to five loads and a compare. The stack bound can be kept in the > thread global dataspace, and you don't sacrifice a register. > > possible Algorithm: > > r1 := thread id > r2 := thread global dataspace [r1] > r3 := offset of stack bound [r2] > r4 := [r3] > compare r4 and sp > > Ok, three to five loads isn't nothing, but shouldn't hurt to much as a > generic implementation. If you want it faster, you 'll have to become > processor specific. > On machines where you control the thread switching, and there is only one thread running at a time, you can do as you describe. On the NT implementation, which has kernel supported threads and multiprocessor support, I don't think you could as you described. I think you would need to stash the stack bound in thread private storage (or what ever it is called in NT), and make a call on procedure entrance to get it. I suspect that this would slow down procedure invocation quite a bit. Solaris also supports kernel level threads, and a call to get a value from thread private storage is a kernel call. You wouldn't want to make a kernel call on every procedure invocation. > So how fast do you need it? No more than a couple of instructions in the normal case. --geoff ======================================================================= 98 === Date: Thu, 16 Mar 1995 15:57:19 PST From: boehm.PARC@xerox.com Subject: Re: Stack overflows Let's say that the guard area between stacks is 10% of the stack size. I think that usually means (except on register window machines) that you can skip the guard page only if the size of a stack frame is at least 5% of the stack size. I rarely write such code, and I tend to be careful if I do. I'm not enough of a Modula 3 expert, but I suspect the compiler can eliminate nearly all call frames as safe, so that you should be able to insert explicit tests in only a small fraction of the functions, even if you do want to check. This argues that an explicit check should rely on guard pages. On a SPARC the constants are different, but I still believe you need exceptionally large frames to get into trouble. I don't have Modula 3 stats, but according to a tech report by Calder, Grunwald, and Zorn, the average dynamic function size in C++ was 46.1 instructions for the programs they measured. So 5-10 instructions per function call is likely to be more than 5%. Hans-J. Boehm (boehm@parc.xerox.com) Standard disclaimer ... ======================================================================= 99 === Date: Thu, 16 Mar 1995 15:44:48 GMT From: george@bcstec.ca.boeing.com (Harry G. George) Subject: Re: Undefined number of arguments In article <9543@merlin.ukc.ac.uk>, I.Chatzigiannakis wrote: > >Do you have any idea how I can make a procedure that accepts many >arguments without a preset number. >I know how to code it in c++ (void myfunc(char *format,...)) but >what about modula-3? > >Thanks for the help >Yannis > > I use: PROCEDURE myfunc(format:TEXT; parm1,parm2,parm3,parm4,parm5:REFANY:=NIL); If it may take more than an obvious maximum, then I go to dynamic arrays: PROCEDURE myfunc(format:TEXT; args:ARRAY OF REFANY); Of course then I need to set up an adequately large array (e.g., via a dynamic array), and then do an array constructor in the call: myfunc("my format here",Args{p1,p2,p3,p4,p5,p6,p7,p8,p9,p10}); -- Disclaimer: Any opinions expressed herein are my own and not those of The Boeing Company. Contact: Harry George, BCAG Advanced Software Technology Phone: (206) 237-6915 Org: 6-6541 M-S: 6H-WT ======================================================================= 100 === Date: 17 Mar 1995 11:47:59 GMT From: pbm1001@cam.ac.uk (Paul Menage) Subject: Re: Undefined number of arguments In article <9543@merlin.ukc.ac.uk>, ic4@ukc.ac.uk (I.Chatzigiannakis) writes: > >Do you have any idea how I can make a procedure that accepts many >arguments without a preset number. >I know how to code it in c++ (void myfunc(char *format,...)) but >what about modula-3? You can simulate it using default values for parameters, initialised to some suitably invalid value ( or with one parameter specifying the validity of the others ). E.g. For doing execution tracing, I have a procedure with the following signature: Trace(format:TEXT; i1,i2,i3,i4,i5:=0; f1,f2,f3,f4,f5:=0.0; r1,r2,r3,r4,r5:REFANY:=NIL); where format specifies a the string to be printed ( a la printf ) and the other parameters are substituted into the output as required. It is a little innefficient, in that up to 15 unecessary parameters are passed each time, but in a routine like this that does terminal output, this should hopefully not create a noticeable effect. Paul -- Paul Menage Magdalene College, Cambridge pbm1001@cam.ac.uk 'One of its satellites, a green and insignificant planet, is now dead' ======================================================================= 101 === Date: 16 Mar 1995 16:15:39 GMT From: nayeri@gte.com (Farshad Nayeri) Subject: Re: Dylan, Modula-3 and OMG > I'm interested in finding a good (better than C++) language for > developing ORB-based applications. There are a lot of factors to > consider, for example, the naturalness of the mapping to IDL; the > ease of providing 'proxies' for remote objects; the appropriateness > of the object creation paradigm to a distributed environment etc. > etc. > > Although I'd be interested people's views of Dylan's suitability in > general, to start with I was wondering whether Dylan offered useful > features that Modula-3 didn't (or vice-versa!). > > I read with interest a summary from Geoff Wyant a while ago > outlining Modula- 3's features, some of which seem appropriate to a > CORBA environment: > > [many nice Modula-3 features deleted.] > > How does Dylan compare? I expect that CORBA is a consideration for > the Apple developers, if only because OpenDoc is aligned with it. How do you build a reliable (and easily maintainable) distributed program in presence of generic dispatch anyway? Due to the emphasis on reliability, engineering a distributed program entails careful treatment of network calls. For me, this does not sit well with the nature of programming with generic functions, where I can add mixins to any of the parameters, and changing the nature of the distributed call in unpredictable ways. I am not refuting the value of having generic functions; I'd love to have them sometimes. I just don't know if I want them to get in my way of ensuring that my distributed program is robust! Maybe if it were possible to restrict their genericity for certain tasks... I am also not saying that it's impossible to do distributed programming in Dylan. I am just wondering how hard it would be. I wonder if this is simply not a priority for Dylan folks at the moment. Anyone trying to do this out there? What are your experiences? Finally, in response to the previous post, I'd like to note that stating that a programming language: - has an OMG IDL binding (or supports OpenDoc) - provides at least the minimal support for building of large-scale and reliable distributed applications - has no built-in support for distributed programming but it makes sure that it doesn't get in the way of distributed programming as the problems of building distributed systems were considered in the design of the language mean different things, each promising a different level of support for its ability to support large distributed systems. Am I correct to assume that Dylan has none of the above? -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 102 === Date: 17 Mar 1995 00:21:12 GMT From: egustafs@ecepc44.uccs.edu (Eric Gustafson) Subject: Q: raw or cbreak char input Is there some form of "curses" like module or a way to get unbuffered input from a terminal other than reverting to the C library? I dug through all of the m3 library interfaces and couldn't find anything that would let me get a character at a time from a stream. thanks, -- Eric Gustafson egustafs@ecepc44.uccs.edu Electrical & Computer Engineering egustafs@cpe.valpo.edu University of Colorado -- UCCS Phone: (719) 637-8022 ** Warning ** Planet is 97% full please remove unneeded inhabitants !! ======================================================================= 103 === Date: 17 Mar 1995 13:03:47 GMT From: normark@iesd.auc.dk (Kurt Noermark) Subject: Reminder: Demos at ECOOP'95. As the coordinator of the demonstrations at ECOOP'95 in Aarhus, Denmark, I would like to remind everyone that the deadline for submissions of demo proposals is April 12, 1995. The Aim of a Demo at Ecoop'95 is to demonstrate innovative concepts, techniques or tools within object-oriented software. Demonstrations will be selected on the basis of technical merits, novelty and relevance. Please send proposals to me, using the address below. The proposal must contain descriptions of the qualities of the demo (technical merits, novelty and relevance) as well as a description of the hardware requirements. Kurt Normark Department of Mathematics and Computer Science Institute for Electronic Systems Aalborg University Fredrik Bajers Vej 7, DK-9220 Aalborg DENMARK Phone: +45 98 158522 Fax: +45 98 158129 E-mail: normark@iesd.auc.dk ======================================================================= 104 === Date: 17 Mar 1995 11:24:35 -0500 From: pjensen@csi.compuserve.com (Phil Jensen) Subject: Re: stack checking Well, here's one way stack checking could work on Intel boxen. Keep the limit value always at -4(ebp). So the entry code would be (in MIT "source, dest" order): mov -4(ebp),eax push ebp mov esp,ebp push eax cmp eax,esp jb stack-overflow (or maybe you could arrange it so the test instruction caused overflow on failure and use the one-byte "into" instruction to trap it) Penalty: 4 instructions plus 2 memory references. ======================================================================= 105 === Date: Fri, 17 Mar 1995 12:09:22 GMT From: olaf@logware.de (Olaf Wagner) Subject: M3 rel. 3.5.1 and FreeBSD As some people already have run into problems, I feel it is time to post something about the state of M3 3.5.1 for FreeBSD. First of all: The boot-archives on gatekeeper.dec.com and its mirrors dated 14.02.1995 do NOT work! There is no way bo build a working system using these archives, if you don't have a running m3 compiler and all the sources. This is because of bugs in the Udir.i3 and Ustat.i3 interfaces for FreeBSD 1.1 and FreeBSD 2.0. The old compiler obviously didn't use the buggy definitions... The corrected interface definitions are appended to the end of this article. The binary distribution on ftp.vlsi.polymtl.ca is okay, but it also contains the buggy interfaces. The compiler is a release 3.3 compiler, and you cannot easily use it to compile the 3.5.1 source archives. You will have to build intermediate libraries and compilers, and of course you will have to use the corrected system interfaces. I have done that, but I really cannot remember all the steps I took do get things up... You can use the 3.3 binary distribution for FreeBSD 1.1(.5) together with the 3.3 source archives. Unfortunately these sources have disappeared from gatekeeper.dec.com, but they still should be carried on some mirror sites. One site I know of is ftp.germany.eu.net:/pub/programming/languages/modula-3 Probably there will be nearer sites for all those in the US. The new release (3.5.1) does (principally) work on FreeBSD 1.1.5 and FreeBSD 2.0, but I think my home site is the only one in the world at this moment where it is installed. There are still some problems I would like to tackle before I prepare another binary distribution. These include * multiple definition of _strtod when building standalone in the presence of shared libraries * a working debugger * lots of relocation warnings when using shared libraries I will do what I can, but it might take some time... Perhaps there is anybody else who would like to share the work with me? ;-) One last warning: The binary distribution on ftp.vlsi.polymtl.ca does NOT run on FreeBSD 2.0/2.1. This is due to changes in the size of off_t and some system interfaces. As of now, there is no easy way for anybody out there to get a working M3 system on these versions of the OS that I know of. You will have to wait for a corrected boot-archive or for a binary distribution. Perhaps I will prepare a minimal binary distribution regardless of the problems stated above, so that some more people can get started... Sorry for all the inconveniences, but it's really not that easy to distribute packages that install and run smoothly. Here are the source patches for the buggy interfaces: ---------------------------------------------------- First the interface definitions for FreeBSD 1.1.5: -------- Udir.i3 -------- (* Copyright (C) 1990, Digital Equipment Corporation. *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Sat Apr 16 by rrw1000@hermes.cam.ac.uk *) (* modified on Mon Apr 13 10:04:46 PDT 1992 by muller *) (* modified on Mon Jul 2 13:25:12 PDT 1990 by mjordan *) (* modified on Sat Feb 18 23:43:23 MET 1995 by ow *) UNSAFE INTERFACE Udir; (*** ***) IMPORT Ctypes; CONST MAXNAMLEN = 255; (* maximum length of component of file path name *) MAXPATHLEN = 1024; (* maximum length of file path name *) (* file types *) DT_UNKNOWN = 0; DT_FIFO = 1; DT_CHR = 2; DT_DIR = 4; DT_BLK = 6; DT_REG = 8; DT_LNK = 10; DT_SOCK = 12; (* * The dirent structure defines the format of directory entries returned by * the getdirentries(2) system call. * * A directory entry has a struct dirent at the front of it, containing its * inode number, the length of the entry, and the length of the name * contained in the entry. These are followed by the name padded to a 4 * byte boundary with null bytes. All names are guaranteed null terminated. * The maximum length of a name in a directory is MAXNAMLEN. *) TYPE dirent = RECORD (* describes directory entry *) d_fileno: Ctypes.long; (* inode number of entry *) d_reclen: Ctypes.unsigned_char; (* record length in bytes *) d_type: Ctypes.unsigned_char; (* file types, see above *) d_namelen: Ctypes.unsigned_short; (* name length in bytes *) d_name: ARRAY [0..MAXNAMLEN] OF Ctypes.char; (* name *) END; direct = dirent; (* backwards compatibility *) DIR = RECORD dd_fd: Ctypes.int; (* file descriptor associated with directory *) dd_loc: Ctypes.long; (* offset in current buffer *) dd_size: Ctypes.long; (* amount of data returned by getdirentries *) dd_buf: UNTRACED REF Ctypes.char; (* data buffer *) dd_len: Ctypes.int; (* size of data buffer *) dd_seek: Ctypes.long; (* magic cookie returned by getdirentries *) dd_ddloc: Ctypes.void_star; (* Linked list of ddloc structs for telldir/se ekdir *) END; DIR_star = UNTRACED REF DIR; direct_star = UNTRACED REF direct; <*EXTERNAL*> PROCEDURE opendir (filename: Ctypes.char_star): DIR_star; <*EXTERNAL*> PROCEDURE readdir (dirp: DIR_star): direct_star; <*EXTERNAL*> PROCEDURE telldir (dirp: DIR_star): Ctypes.long; <*EXTERNAL*> PROCEDURE seekdir (dirp: DIR_star; loc: Ctypes.long); <*EXTERNAL*> PROCEDURE rewinddir (dirp: DIR_star); <*EXTERNAL*> PROCEDURE closedir(dirp: DIR_star): Ctypes.int; <*EXTERNAL*> PROCEDURE getdirentries(fd : Ctypes.int; buf : UNTRACED REF Ctypes.char; nbytes : Ctypes.int; basep : UNTRACED REF Ctypes.long): Ctypes .int; END Udir. -------- Ustat.i3 -------- (* Copyright (C) 1989, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* Last modified on Mon Jan 10 13:32:59 PST 1994 by kalsow *) (* modified on Tue Mar 24 20:42:39 PST 1992 by muller *) (* modified on Sat Feb 18 19:20:16 MET 1995 by ow *) INTERFACE Ustat; FROM Ctypes IMPORT int, char_star; FROM Utypes IMPORT u_short, u_long, dev_t, ino_t, off_t; FROM Utypes IMPORT mode_t, nlink_t, uid_t, gid_t, time_t; CONST S_IFMT : u_short = 8_0170000; S_IFSOCK: u_short = 8_0140000; S_IFLNK : u_short = 8_0120000; S_IFREG : u_short = 8_0100000; S_IFPIPE: u_short = 8_0000000; (* no such constant in stat.h! *) S_IFBLK : u_short = 8_0060000; S_IFDIR : u_short = 8_0040000; S_IFCHR : u_short = 8_0020000; S_IFIFO : u_short = 8_0010000; S_IFPORT = S_IFIFO; S_ISUID : u_short = 8_0004000; S_ISGID : u_short = 8_0002000; S_ISVTX : u_short = 8_0001000; S_IREAD : u_short = 8_0000400; S_IWRITE: u_short = 8_0000200; S_IEXEC : u_short = 8_0000100; S_GREAD : u_short = 8_0000040; S_GWRITE: u_short = 8_0000020; S_GEXEC : u_short = 8_0000010; S_OREAD : u_short = 8_0000004; S_OWRITE: u_short = 8_0000002; S_OEXEC : u_short = 8_0000001; TYPE struct_stat = RECORD st_dev : dev_t; (* pad1 : u_short; *) st_ino : ino_t; st_mode : mode_t; st_nlink : nlink_t; st_uid : uid_t; st_gid : gid_t; st_rdev : dev_t; (* pad2 : u_short; *) st_size : off_t; st_atime : time_t; st_spare1 : u_long; st_mtime : time_t; st_spare2 : u_long; st_ctime : time_t; st_spare3 : u_long; st_blksize: u_long; st_blocks : u_long; st_flags : u_long; st_gen : u_long; END; struct_stat_star = UNTRACED REF struct_stat; <*EXTERNAL*> PROCEDURE stat (path: char_star; buf: struct_stat_star): int; <*EXTERNAL*> PROCEDURE lstat (path: char_star; buf: struct_stat_star): int; <*EXTERNAL*> PROCEDURE fstat (fd: int; buf: struct_stat_star): int; END Ustat. ----------------------------------------------------- And now the interface definitions for FreeBSD 2.0/2.1 ----------------------------------------------------- Udir.i3 -------- (* Copyright (C) 1990, Digital Equipment Corporation. *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* modified on Sat Apr 16 by rrw1000@hermes.cam.ac.uk *) (* modified on Mon Apr 13 10:04:46 PDT 1992 by muller *) (* modified on Mon Jul 2 13:25:12 PDT 1990 by mjordan *) (* modified on Sat Feb 18 23:43:23 MET 1995 by ow *) UNSAFE INTERFACE Udir; (*** ***) IMPORT Ctypes; CONST MAXNAMLEN = 255; (* maximum length of component of file path name *) MAXPATHLEN = 1024; (* maximum length of file path name *) (* file types *) DT_UNKNOWN = 0; DT_FIFO = 1; DT_CHR = 2; DT_DIR = 4; DT_BLK = 6; DT_REG = 8; DT_LNK = 10; DT_SOCK = 12; (* * The dirent structure defines the format of directory entries returned by * the getdirentries(2) system call. * * A directory entry has a struct dirent at the front of it, containing its * inode number, the length of the entry, and the length of the name * contained in the entry. These are followed by the name padded to a 4 * byte boundary with null bytes. All names are guaranteed null terminated. * The maximum length of a name in a directory is MAXNAMLEN. *) TYPE dirent = RECORD (* describes directory entry *) d_fileno: Ctypes.long; (* inode number of entry *) d_reclen: Ctypes.unsigned_char; (* record length in bytes *) d_type: Ctypes.unsigned_char; (* file types, see above *) d_namelen: Ctypes.unsigned_short; (* name length in bytes *) d_name: ARRAY [0..MAXNAMLEN] OF Ctypes.char; (* name *) END; direct = dirent; (* backwards compatibility *) DIR = RECORD dd_fd: Ctypes.int; (* file descriptor associated with directory *) dd_loc: Ctypes.long; (* offset in current buffer *) dd_size: Ctypes.long; (* amount of data returned by getdirentries *) dd_buf: UNTRACED REF Ctypes.char; (* data buffer *) dd_len: Ctypes.int; (* size of data buffer *) dd_seek: Ctypes.long (* magic cookie returned by getdirentries *); dd_rewind: Ctypes.long; (* magic cookie for rewinding *) END; DIR_star = UNTRACED REF DIR; direct_star = UNTRACED REF direct; <*EXTERNAL*> PROCEDURE opendir (filename: Ctypes.char_star): DIR_star; <*EXTERNAL*> PROCEDURE readdir (dirp: DIR_star): direct_star; <*EXTERNAL*> PROCEDURE telldir (dirp: DIR_star): Ctypes.long; <*EXTERNAL*> PROCEDURE seekdir (dirp: DIR_star; loc: Ctypes.long); <*EXTERNAL*> PROCEDURE rewinddir (dirp: DIR_star); <*EXTERNAL*> PROCEDURE closedir(dirp: DIR_star): Ctypes.int; <*EXTERNAL*> PROCEDURE getdirentries(fd : Ctypes.int; buf : UNTRACED REF Ctypes.char; nbytes : Ctypes.int; basep : UNTRACED REF Ctypes.long): Ctypes .int; END Udir. -------- Ustat.i3 -------- (* Copyright (C) 1989, Digital Equipment Corporation *) (* All rights reserved. *) (* See the file COPYRIGHT for a full description. *) (* *) (* modified on Tue Mar 24 20:42:39 PST 1992 by muller *) INTERFACE Ustat; FROM Ctypes IMPORT int, char_star, long; FROM Utypes IMPORT u_short, u_long, dev_t, ino_t, off_t; FROM Utypes IMPORT mode_t, nlink_t, uid_t, gid_t, time_t, quad_t; CONST S_IFMT : u_short = 8_0170000; S_IFSOCK: u_short = 8_0140000; S_IFLNK : u_short = 8_0120000; S_IFREG : u_short = 8_0100000; S_IFPIPE: u_short = 8_0000000; (* no such constant in stat.h!*) S_IFBLK : u_short = 8_0060000; S_IFDIR : u_short = 8_0040000; S_IFCHR : u_short = 8_0020000; S_IFIFO : u_short = 8_0010000; S_IFPORT = S_IFIFO; S_ISUID : u_short = 8_0004000; S_ISGID : u_short = 8_0002000; S_ISVTX : u_short = 8_0001000; S_IREAD : u_short = 8_0000400; S_IWRITE: u_short = 8_0000200; S_IEXEC : u_short = 8_0000100; S_GREAD : u_short = 8_0000040; S_GWRITE: u_short = 8_0000020; S_GEXEC : u_short = 8_0000010; S_OREAD : u_short = 8_0000004; S_OWRITE: u_short = 8_0000002; S_OEXEC : u_short = 8_0000001; TYPE struct_stat = RECORD st_dev : dev_t; st_ino : ino_t; st_mode : mode_t; st_nlink : nlink_t; st_uid : uid_t; st_gid : gid_t; st_rdev : dev_t; st_atime : time_t; st_spare1 : u_long; st_mtime : time_t; st_spare2 : u_long; st_ctime : time_t; st_spare3 : u_long; st_size : off_t; st_pad1 : long; st_blocks : quad_t; st_blksize: u_long; st_flags : u_long; st_gen : u_long; st_lspare : long; st_qspare1: quad_t; st_qspare2: quad_t; END; struct_stat_star = UNTRACED REF struct_stat; <*EXTERNAL*> PROCEDURE stat (path: char_star; buf: struct_stat_star): int; <*EXTERNAL*> PROCEDURE lstat (path: char_star; buf: struct_stat_star): int; <*EXTERNAL*> PROCEDURE fstat (fd: int; buf: struct_stat_star): int; END Ustat. ------------------------- All this is of course without any guarantee, and there may still be numerous bugs. But it is working for me... Olaf -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \ Olaf Wagner at Logware GmbH Schwedenstrasse 9 \ \ olaf@logware.de (work) 13359 Berlin 65 \ \ wagner@luthien.in-berlin.de (private) Germany / Deutschland \ \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\ \ Olaf Wagner at Logware GmbH Schwedenstrasse 9 \ \ olaf@logware.de (work) 13359 Berlin 65 \ \ wagner@luthien.in-berlin.de (private) Germany / Deutschland \ ======================================================================= 106 === Date: 18 Mar 1995 02:12:49 GMT From: schaub@ponder.csci.unt.edu (Stephen Schaub) Subject: Modula-3 info file available I've created an info file for Modula-3 for the benefit of my students. It consists of a simplified language reference and a guide to using the SRC implementation. It's available in both .info and .html formats via anonymous ftp: replicant.csci.unt.edu/pub/m3info.tar.gz The information is basically a boiled-down and reworked version of what's on the Modula-3 home page, hopefully more accessible to the beginning Modula-3 user. Some language features are not discussed (generics, unsafe features, several built-in operators) because my students don't need them. If there's enough interest shown I'll consider adding them. Errata reports and other comments are welcome. Stephen Schaub schaub@cs.unt.edu ======================================================================= 107 === Date: Sat, 18 Mar 1995 21:53:13 GMT From: eric@telebit.com (Eric Smith) Subject: Re: Stacks overflows In article douglm@rpi.edu (Mike Douglas s) writes: > Stack checking would involve a little extra overhead on program entry and > thread switching but I feel the improvement in error reporting and > reliability make it worthwhile. To guard against the scenario you suggested where a function has a huge stack frame, you need stack limit checking everywhere that stack frames are created (i.e., in function prologs), not just on program entry and thread switching. On an experimental port of the NetBlazer router to an AMD 29000 RISC processor a few years ago, I added a limit check to the spill handler (which pushes stack frames from the internal registers to main memory). On the 29000 this can be done by a single assert instruction, which takes only one cycle to execute unless the assertion fails, in which case it traps. This seemed like a reasonably small performance hit since the spill handler isn't executed for every function call. On the 29K each process actually has two stacks. The "other" stack is used for any locals beyond the first 124 32-bit words. To limit check this stack required a change to the prolog which the compiler generates for functions that use this stack to add an assert instruction. The NetBlazer is unfortunately written in C rather than Modula 3, but the same changes would have worked for Modula 3. Other processors with assert or trap-on-compare instructions would offer similar efficiency for the stack checking. Cheers, Eric ======================================================================= 108 === Date: Sat, 18 Mar 95 19:28:10 TZ From: bryant@microsoft.com (Bryan Tuttle) Subject: re: stack checking | > Guard pages are straight forward. Should be the same semantics on | > every paged mmu. Hope you have OS support for using them. | |This whole discussion started because Mike Douglass felt that |gaurd pages weren't sufficient. I don't know how frequently they |fail in practice, I didn't see this message. Can someone forward to me? | > If procedurecalls do not happen too frequently, a simple compare on | > procedure entry (and maybe exit) should be fast enough. You 'll need | > three to five loads and a compare. The stack bound can be kept in the | > thread global dataspace, and you don't sacrifice a register. | > | > possible Algorithm: | > | > r1 := thread id | > r2 := thread global dataspace [r1] | > r3 := offset of stack bound [r2] | > r4 := [r3] | > compare r4 and sp | > | > Ok, three to five loads isn't nothing, but shouldn't hurt to much as a | > generic implementation. If you want it faster, you 'll have to become | > processor specific. | |On machines where you control the thread switching, and there is only |one thread running at a time, you can do as you describe. On the NT |implementation, which has kernel supported threads and multiprocessor |support, I don't think you could as you described. I think you would |need to stash the stack bound in thread private storage (or what ever it |is called in NT), and make a call on procedure entrance to get it. I suspect |that this would slow down procedure invocation quite a bit. Solaris also |supports kernel level threads, and a call to get a value from thread private |storage is a kernel call. You wouldn't want to make a kernel call on every |procedure invocation. Assuming M3 works like it did the last time I looked (ie: the C compiler ultimately generates the objects), this isn't an issue on NT. The compiler will add stack probes for functions who's local storage requirements exceeds the range of the guard page (4k on x86/Mips/PPC, 8k on Alpha). The only time this won't work is if you manipulate the stack pointer outside the bounds of the code generator w/o observing this rule. In that case, you get what you deserve. You still run the risk of exceeding the reserved stack size, but there are simple workarounds for that also (reserve a larger stack or add a handler for EXCEPTION_STACK_OVERFLOW to deal with it). There's no need to make a kernel transition and for most cases, the probe isn't needed. Bryan ======================================================================= 109 === Date: 19 Mar 1995 23:26:34 GMT From: ljw1004@thor.cam.ac.uk (L.J. Wischik) Subject: Re: try-finally-except In article <3jm8js$lf8@wolfe.wimsey.com>, Taj Khattra wrote: >Why does Modula 3 have TRY-EXCEPT and TRY-FINALLY statements instead >of a single TRY-FINALLY-EXCEPT statement ? >Is the following case the main reason why ? > TRY > RAISE e; > FINALLY > IF (foobar) RAISE e; > EXCEPT > e => (* this may or may not be executed *) > END I find that I myself more often use TRY TRY something-or-other EXCEPT exceptions-that-are-normal-and-signify-the-end-of-something END FINALLY just-in-case-there-were-unusual-exceptions; the tidy-up code for whatever iterators also goes here. END; So, perhaps Modula-3 has separate try-except and try-finally simply so both formations can be used. -- Lucian ======================================================================= 110 === Date: Mon, 20 Mar 1995 15:38:16 MET From: rudy@cs.rug.nl Subject: Re: Language definition (overrides) Reaction on "Re: Language definition (overrides)" of David Chase > Why? What purpose does this serve? I can not tell you the full story of my implementation problems, because it is to complicated to explain it on one page. So I will try to show you the problems I have. I am developing an image processing programming environment. Images can be of the type RGB (red, green and blue), complex, real grayscale, integer grayscale, byte grayscale or black and white. To implement the appropriate type conversions an object hierarchy between the image types is helpful. This means a real grayscale image is a subtype of a complex image, an integer grayscale image is a subtype of a real grayscale image and soon. On the other hand complex, real and integer images have so much in common, that it is possible to use generics to implement the major part of them. So I obtain an object hierarchy like A(complex) / \ / \ B(complex) A(real) / \ / \ B(real) A(integer) / / B(integer) In the generic interfaces A and B an object type T (image) is defined. The objects in the A interfaces are objects which define Abstract Data Types and they can not be allocated. The actual implementation of every objecttype is done in the B interfaces and implementations. Every object has two methods "put" and "get" to manipulate pixels. So A(real) has the methods: put(x:real); get():real; In the implementation B(integer) I want to override for example the method A(complex).get to obtain an complex pixel from an integer image. I can give up the abstract "put" and "get" and replace them by something like "putcomplex" and "getcomplex". If I do so, I can not benifit from the generic character of A. I have not been able to solve this problem satisfactory with the current definition of Modula-3. > How does > this interact with the rest of the language? > Do you have a proposed implementation > technique for this change to the language? Handling qualified identifiers instead of not qualified identifiers is no problem. The compiler does this in case of expression evaluation, references to existing types and soon. The code generation is simple if all methods (hidden or not) are members of the method suite. (See the suggested implementation in Harbison). In this case the hidden pointer refering to a procedure must be changed. The method suite is an array of pointers. The index can be computed by using the parent type. Notice: as far as methods are member of both the child and the parent, they have the same indices. > And, again, why? Can you at least motivate > this change? Simply saying "I can't do this, > but if I made this change to the language, > then I could" is all well and good, but that > holds for many things (complex numbers, > unbounded integers, non-contiguous subarrays, > distributed arrays on MPPs, first-class > functions, method closures, continuations, > inheritance among exception types, operator > overloading, constrained generics ...). In complex data structures using both generics and objects, you must be able to override hidden methods. If you are only using objects, you can better choose different names for your identifiers. The generics make this impossible. > I suspect that this also might make programs > slightly less readable -- whenever I say > "O.m" I know that the function from the method > suite is being referred to. Which method suite (parent of child)? TYPE Parent OBJECT METHOD m():=P1 END; Child OBJECT OVERRIDES m:=P2 END: VAR O:Parent; BEGIN O:=NEW(Child); O.m(); O:=NEW(Parent); O.m(); Can you tell me to which procedure (P1 or P2) your "O.m" is refering to? > Whenever I say > "T.m" I know that the function statically > bound to type T is being referred to (and it > is my understanding that if T <: S, and T > overrides method m visible in S, then T.m > gets me the overriding method, even though > the function name is not visible to me). This correct and should remain so. > I think this would also violate the reference > manual rule, in that it would increase the > size of the reference manual out of all > proportion to its usefulness. The same argument is valid for all qualified identifiers. We could also import them using FROM X IMPORT Y. I can even state that now in the reference manual you have to forbid explicitely qualified identifiers at certain places. > Sorry for the skeptical tone, but I'm > skeptical. My tendency is to resist changes > to the language, even those there's quite a > few changes I'd like to make myself > (everything in the list above except > continuations and operator overloading), and > one that I even hope to propose when I get > the time to write it up properly. You must be very careful if you propose changes in the language definition. I only want to open the discussion about minor changes which improve the language. In case of the READONLY proposal I have only had positive reactions and reactions like "you can also do it by this way". I am waiting for the first negative reaction! > I have similar reservations about your > "READONLY" proposal -- as near as I can tell, > it has only local effects (i.e., does not > assist in the building of large systems or > the reuse of code). Debugging programs cost a lot of time. Often it costs more time to debug a program then to write a program. If there is a simple and efficient mechanism to detect bugs, you must use it. READONLY declarations are with respect to the produced code equivalent to VAR declarations. But the author also states, I have introduced this variable with the intension that nobody should change its value. If the READONLY variable is changed, the bug will be detected at compile time and not after a painful dubugging procedure. > If this was of > tremendous concern to you, I might lobby for > a pragma, but this seems like a tiny frob. Sorry for the skeptical tone, but now I'm skeptical. As a consequence it seems to be an improvement to the language to introduce <* CONSTANT *> VAR x := 3; instead of CONST x = 3; > It provides only minor assistance in the > generation of efficient code, since it's > fairly easy for an optimizer to verify that a > variable is only assigned to once. Efficiency is not important and it has never been an argument to introduce READONLY variables. But it is unknown to the compiler that it was the intention of the author that a variable is only assigned to once. yours, R. Moddemeijer ======================================================================= 111 === Date: 20 Mar 1995 15:44:47 -0600 From: beede@gateway.sctc.com (Mike Beede) Subject: Installing boot-SOLgnu I've been trying to install the boot-SOLgnu package on a Solaris 2.3 system. I had to modify a makefile to use gcc to build quake. After that, things work till we get to m3. At that time, I get an error from gcc saying it doesn't recognize "-compat-bsd" and a link error as follows: gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a ../../m3core/SOLgnu/libm3core.a -lsocket -lnsl -lm gcc: unrecognized option `-compat-bsd' Undefined first referenced symbol in file getdtablesize ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o) getwd ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o) _longjmp ../../m3core/SOLgnu/libm3core.a(RTThreadC.o) _setjmp ../../m3core/SOLgnu/libm3core.a(RTThreadC.o) Well, there is a "setjmp" and "longjmp" in the libraries, but none with underscores. getdtablesize and getwd are easier -- I could write them from the man pages. However, the idea I got was that the 3.5.1 Solaris versions had been checked. If they have, I'm probably doing something wrong. I was suspicious when I saw it looking for the /usr/ucb/cc compiler. Is it supposed to build just with gcc? On a related note, I got the Linux version installed after getting the patched DLL tools. That works fine (except for some packages that don't compile -- I'm happy because I can compile and run). Thanks for any suggestions, Mike -- Mike Beede - (612) 628-2720 SCC beede@sctc.com ======================================================================= 112 === Date: 17 Mar 1995 11:28:11 GMT From: kanze@us-es.sel.de (James Kanze US/ESC 60/3/141 #40763) Subject: Re: Stack overflows In article <1995Mar16.123251.10988@lts.sel.alcatel.de> buschman@slsv4ot (Andreas Buschmann US/END3 60/1/29 #40409) writes: |> Geoffrey Wyant - Sun Microsystems Labs BOS (gwyant@cloyd.East.Sun.COM) wrote : |> : Mike Douglass writes: |> : > >Mike Douglass writes: |> : > > > Stack overflows are a major concern ... |> : > >Geoff Wyant writes |> : > >I think the addition of stack boundary checking would be good, though I'm |> : > >concerned about the cost, especially in the face of multithreading. I don't |> : > >know if you can get the stack end in a cheap manner on entry to a proc edure. |> : > |> : > I cannot remember all of the details but stack checking involved having a |> : > stack descriptor which was accessible at a known location (global base |> : > actually) and checking the current stack pointer against the top of the |> : > stack. |> : > |> : > The overhead is relatively low. |> : Thinking about it some more, it seems like it should be relatively |> : straightforward. What you want is to have instantaneous access to the |> : stack bounds (or at least how big the stack is allowed to grow). The |> : easiest way to do this is to dedicate a register to it, which I suspect |> : the code generator could do pretty easily. You wouldn't get stack |> : checking when calling into a non-M3 routine, but at least you would have |> : an indication of where it might have occurred. On a RISC machine, it is pr obably |> : reasonable to do this, but it might create register pressure on the x86 |> : architecture. Does the x86 maintain stack bounds in a register anyway ? |> yes, there is a special segment register for the stack. You can have |> all necessary checking in hardware (It still takes time!) This is actually a simplistic answer, although it is the solution I generally used on 8086/80186. Note that in this case, the stack bound is a compile time constant (0), so you don't have to worry about allocating a register for it. Most of the implementations for 80386 up in protected mode use a flat memory model. In this case, stack checking is exactly the same as it would be on most RISC machines. Except that given the paucity of registers, you really don't want to dedicate one for the bounds. Does anyone have any thoughts on how to handle stack overflow in a virtual memory environment? Generally (Sparc, Motorola 68K,88K and Intel 80386 up), we have the stack at the top growing down, and the heap at the bottom growing up. Given the address range of these processors, there is no worry that they cross, and no point in checking the stack against the top of heap. At some point in time, however, the process will core dump because there is no more virtual memory available to allocate to the stack. Does anyone know of a way to convert this into an exception (or code that would somehow detect the condition before it arrises, and generate an exceptions)? -- James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France Conseils en informatique industrielle -- -- Beratung in industrieller Datenverarbeitung ======================================================================= 113 === Date: Wed, 22 Mar 95 12:37:30 GMT From: pda1@ukc.ac.uk (P.D.Austin) Subject: Re: Most efficient way to handle strings In my previous article I forgot to initialise the s variable so the VAR line should be VAR s : TEXT :=""; or VAR s :=" ";. Paul Austin ======================================================================= 114 === Date: 21 Mar 95 16:23:22 From: nayeri@gte.com (Farshad Nayeri) Subject: SRC M3 3.5.1 on AIX 3.1 with gcc 2.6.0 I am trying to compile SRC Modula-3 3.5.1 on AIX 3.1. I have gcc 2.6.0 for AIX, and /bin/cc but no other compiler that I know of (the templates refer to bsdcc, which I don't have.) Has anyone had any success in building the AIX port lately? I used the m3cc that uses gcc 2.6.3. In my first attempt, I was able to build boot-IBMR2 and ship it, but when I strated building m3core, the "m3" driver would core dump with a nil dereference. If you have done this, and have any pointers, please send them to me. This is the first time I have touched an AIX machine. I will be happy to make the binary release available on the net once I get it working. Thank you in advance, -- Farshad -- Farshad Nayeri nayeri@gte.com ======================================================================= 115 === Date: Wed, 22 Mar 95 10:45:46 GMT From: pda1@ukc.ac.uk (P.D.Austin) Subject: Most efficient way to handle strings I was doing a simple program wich required the procedure below and I was wondering if there was any difference in execution times between having s:=s & " " or s:=" " & s or if it made any difference at all. PROCEDURE spaces(num : CARDINAL) : TEXT = VAR s : TEXT; BEGIN FOR loop := 1 TO num DO s:=s & " "; END; END; If anyone has an answer I would appriciate it, the speed is not really a major issue but it would be nice to know. thanks in advance Paul Austin "Improving the little things can also improve the bigger things..." ======================================================================= 116 === Date: 22 Mar 1995 13:24:34 GMT From: rrw1000@cus.cam.ac.uk (Richard Watts) Subject: Re: Problems building 3.5.1/boot-LINUX In article <5hmz4B0EcsB@khms.westfalen.de>, Kai Henningsen wrote: >kai@khms.westfalen.de wrote on 11.03.95 in <5heGuV7EcsB@khms.westfalen.de>: > >> So I tried that one ... unfortunately, the results seem to me to be a lot >> worse than what I had! I think my slightly-patched 2.16 is a much better >> prospect than your massively-patched 2.11 ... > >I think I got it now ... mostly. I'm still not through compiling, though - >this is one big monster. > >Bundles still seem to exhibit some problems. Most problems I found so far >are the parsing code in the dll tools - it's mighty sloppy. There's a copy of some patched 2.16 DLL tools under : http://www.cl.cam.ac.uk/m3doc/linux/m3.html In the 3.5.1 binary archive. They're just a quick hack I slammed together, but they seem to work for compiling 3.5.1. Sorry I didn't post earlier - only just had time to read this group thoroughly :-(((. > >I think after I'm through, I'll make my version of tools 2.16 available >somewhere. > :-))). Thanks ! :-). I, for one, would be grateful for some purposeful patches (I just hacked Michel Dagenais' patches into 2.16). Richard. -- `There comes a time when you look into the mirror and you realise that what you see is all that you will ever be. And then you accept it. Or you kill yourself. Or you stop looking in mirrors.' The University of Cambridge can't have these opinions even if it wants them. ======================================================================= 117 === Date: 22 Mar 1995 22:09:16 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: Most efficient way to handle strings In article <9607@merlin.ukc.ac.uk>, pda1@ukc.ac.uk (P.D.Austin) writes: > I was doing a simple program wich required the procedure below and I was > wondering if there was any difference in execution times between having > s:=s & " " or s:=" " & s or if it made any difference at all. > > PROCEDURE spaces(num : CARDINAL) : TEXT = > VAR s : TEXT; > BEGIN > FOR loop := 1 TO num DO > s:=s & " "; > END; > END; The order makes no difference. The SRC Modula-3 runtime represents TEXTs as flat arrays of char. So, your loop will allocate "num" arrays, each with a 12-byte fixed overhead. The total space allocated will be about num*(num+25)/2. All but 1 array, 12+num bytes, will be reclaimed by the garbage collector. The program below allocates 2 arrays with a total space of 24+2*num bytes, half of which is reclaimed. PROCEDURE spaces (num: CARDINAL) : TEXT = VAR a := NEW (REF ARRAY OF CHAR, num); BEGIN FOR i := 0 TO num-1 DO a[i] := ' '; END; RETURN Text.FromChars (a^); END spaces; And finally, if there's a reasonable bound on "num", the following allocates only the final result: CONST Blanks := " "; PROCEDURE spaces (num: CARDINAL) : TEXT = BEGIN <*ASSERT num <= Text.Length (Blanks)*> RETURN Text.Sub (Blanks, 0, num); END spaces; - Bill Kalsow ======================================================================= 118 === Date: 23 Mar 1995 01:55:19 GMT From: ljw1004@thor.cam.ac.uk (L.J. Wischik) Subject: Proposal---network objects, impurity, and partial revelations PROPOSAL FOR MODIFICATION TO NETWORK OBJECTS ------------------------------------------------ Network objects are, at the moment, limited to being totally pure, and to being fully revealed. I propose a small modification to network objects, and to stubgen in particular, to permit partial revelations and semi-impure objects to be used. I shall start with a concise statement of my proposal. Next, I shall give a brief illustration of what it means, in a more readable form. After this, I shall give a practical illustration of where current network objects are inadequate and of how my solution would help. A few notes and general observations of the impact and significance of these changes comes next, and finally I shall conclude. 1. PROPOSAL That a new command be added for m3makefiles, viz. `netobjp' (the `p' is for `partial'). It takes three parameters: netobjp(interface_with_type,object_name,interface_with_revelations) The `interface_with_type' is the interface in which the type of the object was first declared. The `interface_with_revelations' is some interface, in which as many revelations as are wanted are revealed. Only the methods present in these revelations will be stubgen-ed: all the rest will be left as local methods. It is required that what appears of the object through these partial revelations is a pure object (ie. with no fields). It is a compile-time error to try to netobj one object with more than one `netobjp'. Exporting and importing work just as they do now. Suppose you invoke a method that was revealed to the stubgen. This would cause a network call, as normal. Suppose you invoke a method that was not revealed to stubgen. The network object type would not have overwritten this method; so, the method invocation would be handled locally and normally. 2. ILLUSTRATION Suppose we have this object hierarchy: +--> C --> D A --> B -+ +--> E --> F and suppose further that the revelations were split into interfaces, and that there happened to be an interface X in which was visible public methods for A and C, and an interface Y in which was visible A, E and F. If we did netobjp(.., D, X) and netobjp(.., F, Y), then we would have a hierarchy that, including the objects generated by stubgen, would look like this: /A',C' +--> C --> D --+ A --> B -+ /E',F' +--> E --> F ---+ where /A',C' is an object which has stub-overrides for all the methods declared in A and in C. If the user imported the /E',F' object, then method invocations for methods in A and B would be done locally, and those for methods in E and F would be done remotely. Hopefully, somewhere between A,B and E,F, would be implementations for the methods in A and B, as well as whatever fields were needed for these. The fields would initially be set to the state in which they would be set if we had called NEW(F). It is up to the user to initialise fields to appropriate values after a NetObj.Import call. 3. EXAMPLE OF USE Consider a penumbra-object. (The penumbra is the region of partial-shadow, which surrounds the full shadow, or umbra, which is cast when an object is illuminated by an extended light source such as a fluorescent strip-light). This penumbra is an item in a special sort of client-server database, in which each client maintains a penumbra and the server maintains a central version. Some methods of the penumbra, such as reads (which occur frequently) are handled by the penumbra and it's data fields itself; other methods are farmed off to the server. Also, there is some property that is specific to each client, and is stored in the 'local' part of the object. So, things look like this: Object, with two aspects. _______________ / //// | \\\\\\ \ | ///// | \\\\\\\ | -------> | local | network | -------> Some calls are farmed off | \\\\\ | /////// | -------> to the server. \_\\\\_|_//////_/ ^ ^ ^ | | | | | | method invocations come to the object. The user of the object may or may not be aware of which calls go where. The local calls are handled internally. The hierarchy to represent this object could be this: NetObj.T --> network-interface --> local-interface -->local-implement. --> T The problem (under the existing scheme) comes when we want to descend new types from this one. Suppose the object I have described is a 'Cell', and I wish to descend a 'path' from it: | v The hierarchy now looks like this: NetObj.T --> Cell.Local --> Cell.Network --> Cell.Impl. --> Cell.T --> Path.Local --> Path.Network --> Path.Impl. --> Path.T The Path.Network here cannot be made into a network object under the existing scheme, because Cell.Impl. (the implementation for Cell, along with various fields) comes above it. But, under my scheme, we could simply declare Path.Network in an interface that happened also to import Cell.Network. The network-object that was created, would then include stubs for Path.Network and for Cell.Network, but calls to Path.Local or to Cell.Local would still be handled locally. 4. NOTES I am not trying to introduce multiple-inheritance by the back door. The narrowing procedure currently used still works with no modifications. (Exports work by finding the closest ancestor that has been stubgened, and exporting this; Imports work by examining the ancestry of the imported object and finding the narrowest match). The mechanism I have proposed is not overly restrictive. Indeed, it can be seen that the current regime is a subcase of my proposal. I suspect too that it is not overly generous; but I do not know how to justify this assertion. The only major change required would be to stubgen. It would have to be made to search only the specified interfaces, and to work with partial revelations. I do not expect this to be difficult, but find it hard to tell. In the example I gave above, a solution using current network objects could be found; but it would involve maintaining three parallel object hierarchies and would involve many, many method duplications. 5. CONCLUSION This proposal has come from a very real limitation up against which I have come. I do feel that network objects are castrated by their current limitations, which seem unnecessarily restrictive. The changes I have suggested do seem sufficiently minor and useful that their implementation would be worthwhile. If my proposal was born of a flawed understanding of the current capabilities of network objects, then please forgive me for wasting time. If there are flaws or inconsistencies, or if I have misestimated the effect of these changes or their difficulty, then please do tell me. If not, and if it is felt that these changes would be worthwhile, then please do tell me as well. (And---would anyone care to implement them?) -- Lucian Wischik, Queens' College, U of Cambridge. ljw1004@cam.ac.uk ======================================================================= 119 === Date: 23 Mar 1995 17:46:22 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: SRC Modula-3 release 3.5.2 Release 3.5.2 of SRC Modula-3 is now on gatekeeper. Here are the differences that I can remember: + m3browser contains the enhancements contributed by Peter Klein + the FreeBsd bootstrap uses the new Ustat and Udir interfaces + the HPPA bootstrap was built with m3cc-2.5.7 + m3zume is shipped properly + miscellaneous bug fixes We still don't have the HPPA platform working with the backend based on gcc 2.6.3. You must use the m3cc-2.5.7.tar.gz archive with HPPA. - Bill Kalsow ======================================================================= 120 === Date: 23 Mar 1995 12:05:03 GMT From: rga1002@cus.cam.ac.uk (R.G. Anteleme) Subject: NetObj.Export question Hi I'm trying to NetObj.Export a method and I get the following error messages: Binding TCP socket: Address already in use Error: Fatal server error! Error: Cannot establish any listening socketsError: Abort (core dumped) Any ideas as to what's going on?! Thanks in advance for any suggestions. ======================================================================= 121 === Date: 23 Mar 1995 22:26:22 GMT From: Subject: Re: SRC Modula-3 release 3.5.2 > Release 3.5.2 of SRC Modula-3 is now on gatekeeper. > > Here are the differences that I can remember: > > + m3browser contains the enhancements contributed by Peter Klein > + the FreeBsd bootstrap uses the new Ustat and Udir interfaces > + the HPPA bootstrap was built with m3cc-2.5.7 > + m3zume is shipped properly > + miscellaneous bug fixes > > We still don't have the HPPA platform working with the backend based > on gcc 2.6.3. You must use the m3cc-2.5.7.tar.gz archive with HPPA. What kind of errors are to be expected if it is compiled with gcc 2.6.3? Also, what is m3cc for and why does it include a version of gcc? I have managed to compile modula 3 for HPPA using gcc 2.6.3. Some included programs ran although the X stuff was screwed up, some ran fine, and some have run-time errors possibly due to hp keyboard or character set stuff and other things. Are these normal symptoms of using gcc 2.6.3 or are they unrelated? Perhaps someone can answer a few of these. Thanks, Andrew -- Andrew Brown Class of '97 System Administrator Swarthmore College Engineering ======================================================================= 122 === Date: Thu, 23 Mar 1995 03:17:06 GMT From: ras@dynastar.princeton.edu (Robert Shillner) Subject: m3gdb crashing problem I'm using SRC Modula-3 v3.3 on an alpha running OSF/1. m3gdb crashes with a segmentation fault almost every time the program I'm debugging stops, whether from a breakpoint, segfault, CTRL-C or whatever. I have used m3gdb with v3.3 at SRC with only the usual problems; the current situation is completely different. The smallest example for which the problem exists is "hello, world". Has anyone seen this problem before? Any ideas on how to fix it? -- *********************************************************************** (___) * Rob Shillner Princeton University Computer Science * |===| * ras@cs.princeton.edu http://www.cs.princeton.edu/~ras/ * \_/ *********************************************************************** RoboCow ======================================================================= 123 === Date: 23 Mar 1995 23:22:21 GMT From: montjoy@thor.ece.uc.edu (Robert Montjoy) Subject: Re: Installing boot-SOLgnu You need a newer version of gcc that understands -compat-bsd flag. Than all will work. Now why Modula-3 needs to be linked with the Berkeley libraries at all is the question. It should not need them to work. A purely native port is possible. In article <3kkt0f$chv@gateway.sctc.com>, Mike Beede wrote: >I've been trying to install the boot-SOLgnu package on a Solaris 2.3 >system. I had to modify a makefile to use gcc to build quake. After >that, things work till we get to m3. At that time, I get an error >from gcc saying it doesn't recognize "-compat-bsd" and a link error as >follows: > > gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o > Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o > Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o > ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a > ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a > ../../m3core/SOLgnu/libm3core.a -lsocket -lnsl -lm > gcc: unrecognized option `-compat-bsd' > Undefined first referenced > symbol in file > getdtablesize > ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o) > getwd > ../../libm3/SOLgnu/libm3.a(ProcessPosix_m.o) > _longjmp > ../../m3core/SOLgnu/libm3core.a(RTThreadC.o) > _setjmp > ../../m3core/SOLgnu/libm3core.a(RTThreadC.o) > >Well, there is a "setjmp" and "longjmp" in the libraries, but none >with underscores. getdtablesize and getwd are easier -- I could write >them from the man pages. However, the idea I got was that the 3.5.1 >Solaris versions had been checked. If they have, I'm probably doing >something wrong. I was suspicious when I saw it looking for the >/usr/ucb/cc compiler. Is it supposed to build just with gcc? > >On a related note, I got the Linux version installed after getting the >patched DLL tools. That works fine (except for some packages that >don't compile -- I'm happy because I can compile and run). > >Thanks for any suggestions, > > Mike > >-- >Mike Beede - (612) 628-2720 >SCC >beede@sctc.com -- Rob Montjoy - Systems Engineer University of Cincinnati - Electrical/Computer Engineering/Computer Science E-Mail: Rob.Montjoy@UC.EDU - Personal or Other E-Mail ecehelp@ece.uc.edu - For Network and UNIX Workstation Support. ======================================================================= 124 === Date: 23 Mar 1995 23:21:08 GMT From: fraser@wingham.com (Fraser Campbell) Subject: Should I learn Modula-3? How? I want to learn how to program. I have dabbled in C and understand the basics but have never done anything very significant. What I am wondering is whether Modula-3 is worth learning ... that article in Linux Journal made it sound very good! Any advice on how to learn modula-3 would be appreciated - books, text files, newsgroups, etc. Also, I need some help with basic (language independant) program development. I have a couple of apps in mind and just need some advice to get me of the ground ... then I plan to learn as I go along (probably not the best way ;). I realize that eventually C is a language I must become comfortable with especially using UNIX ... but Modula-3 sounds intriguing! So if you know of any good books (or whatever) outlining basic programming concepts and perhaps on Modula-3 please share your knowledge. Thanks ... ======================================================================= 125 === Date: 24 Mar 1995 00:07:16 -0600 From: sysop@kitana.org (JL Gomez) Subject: Re: Should I learn Modula-3? How? I suggest you get the FAQ. It will list several publications. And don't forget the WWW M3 home page too. :) -- sysop@kitana.org ======================================================================= 126 === Date: 23 Mar 1995 22:59:59 GMT From: chase@centerline.com (David Chase) Subject: Re: Language definition (overrides) rudy@cs.rug.nl writes: [in support of a language change] > In complex data structures using both generics and objects, you must be able > to override hidden methods. If you are only using objects, you can better > choose different names for your identifiers. The generics make this > impossible. This begins to make more sense. However, could you possibly expand your generic interface slightly to get the same effect? That is, in your generic, could you also make use of a procedure (not a method) that would accomplish what your change to overrides might do? (I'm not entirely certain of this, I'm just asking.) What I gather (your original post has vanished, sorry) is that for objects of a type T, you wish to dispatch using the method suite, except in those cases where the variable or expression is also of type T, in which case you wish to use a static binding that can be found in the declaration of a type T. Couldn't you do this with a procedure, along the lines of GENERIC INTERFACE Thing(Elem); (* All the derivation stuff is omitted. *) (* Expect PROCEDURE Elem.static_method(x:Elem.T):Elem.U *) That is, this procedure "static_method" is something that the generic expects "Elem" to have defined. In those cases where you want the non-dispatched binding (where, already, you have an object of type Elem.T), you call static_method. > > I think this would also violate the reference > > manual rule, in that it would increase the > > size of the reference manual out of all > > proportion to its usefulness. > The same argument is valid for all qualified identifiers. We could also > import them using FROM X IMPORT Y. ... Ah, but that is very often useful. So far, you've shown us one difficult-to-understand example. > You must be very careful if you propose changes in the language definition. > I only want to open the discussion about minor changes which improve the > language. In case of the READONLY proposal I have only had positive > reactions and reactions like "you can also do it by this way". I am waiting > for the first negative reaction! Ok, call this a negative reaction. Any change that is not a whole-lot-better than no change is a Bad Idea, simply because it is change. Bad because people have to (perhaps) whack on their compilers, bad bacause they might have to whack on their existing code (seems unlikely in this case, though) bad because language implementations get out of sync. > > I have similar reservations about your > > "READONLY" proposal -- as near as I can tell, > > it has only local effects (i.e., does not > > assist in the building of large systems or > > the reuse of code). > Debugging programs cost a lot of time. Often it costs more time to debug a > program then to write a program. If there is a simple and efficient > mechanism to detect bugs, you must use it. READONLY declarations are with > respect to the produced code equivalent to VAR declarations. But the author > also states, I have introduced this variable with the intension that nobody > should change its value. If the READONLY variable is changed, the bug will > be detected at compile time and not after a painful dubugging procedure. In the case of parameters, this documents something at an interface. It helps specify the behavior of an interface. For WITH-READONLY, as near as I can tell, you are only specifying behavior within a single source file. This is a benefit, but a minor one. A comment serves nearly as well. The compiler can whine at you if you pass one of these as a VAR parameter, but it's unlikely to do more than that. In theory, it could somehow impose checks on modifications to the referenced data across procedure boundaries, but this is not something I expect to see happen often. In which case, let it be a pragma. (Have I misunderstood something here? It looks to me like your READONLY proposal will only flag errors of the form: READONLY foo := ; ... foo := ; (* This will be rejected. *) ... proc_with_var_param(foo); (* This will generate a warning. *) ... WITH bar = foo DO (* This will perhaps generate a warning *) bar := (* or else perhaps this will. *) END Is there something else that you expect will be detected? yours, David Chase ======================================================================= 127 === Date: 23 Mar 1995 19:03:06 -0500 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: Re: SRC Modula-3 release 3.5.2 >>>>> On 23 Mar 1995 22:26:22 GMT, Andrew Brown said: >> Release 3.5.2 of SRC Modula-3 is now on gatekeeper. >> >> Here are the differences that I can remember: >> >> + m3browser contains the enhancements contributed by Peter Klein >> + the FreeBsd bootstrap uses the new Ustat and Udir interfaces >> + the HPPA bootstrap was built with m3cc-2.5.7 >> + m3zume is shipped properly >> + miscellaneous bug fixes >> >> We still don't have the HPPA platform working with the backend based >> on gcc 2.6.3. You must use the m3cc-2.5.7.tar.gz archive with HPPA. Andrew> What kind of errors are to be expected if it is compiled with Andrew> gcc 2.6.3? Also, what is m3cc for and why does it include a Andrew> version of gcc? m3cc is the code-generation backend for the compiler, which is based on gcc. It is this that must be based on gcc 2.5.7. I tried using one based on 2.6.3 and one based on the 2.6.3-u6 release for the HPPA from utah, both of which failed ... the generated modula3 code does not work. It's not important which version of gcc you use to actually _build_ the compiler. (well, that may not be true, but I used the latest gcc without problem.) ======================================================================= 128 === Date: 24 Mar 1995 01:16:51 GMT From: joringer@cs.sunysb.edu (Jonathan Oringer) Subject: HP/UX vs LINUX How come the Interfaces in the HP/UX distrib are different from the Interfaces in the LINUX distributions? LINUX does not have Filename.i3 or FileStream.i3. Instead it has WrFile.i3 and RdFile.i3. Are they different versions? Is there a way to make them completely compatable? please respond via email: joringer@mathlab.sunysb.edu Thanks in advance! -Jon Oringer ======================================================================= 129 === Date: 24 Mar 1995 16:34:21 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: HP/UX vs LINUX In article <3kt6i3$h1e@adam.cc.sunysb.edu>, joringer@cs.sunysb.edu (Jonathan Or inger) writes: > How come the Interfaces in the HP/UX distrib are different > from the Interfaces in the LINUX distributions? LINUX does not > have Filename.i3 or FileStream.i3. Instead it has WrFile.i3 and > RdFile.i3. Are they different versions? Filename and FileStream are quite old. FileWr and FileRd are the current interfaces. > Is there a way to make them completely compatable? Yes, upgrade your HP/UX version to something more recent. - Bill ======================================================================= 130 === Date: 24 Mar 95 12:41:27 EST From: PJENSEN@CSI.compuserve.com Subject: NT binary? I was disappointed to find that the "bootstrap" compile process for NT involved running "cl". I strenuously avoid giving money to Bill G wherever possible (I have to use NT for work - left to myself I'd be Linux all the way). Does anyone have an NT binary available for ftp? Thanks. Phil Jensen :: pjensen@csi.compuserve.com ======================================================================= 131 === Date: Fri, 24 Mar 1995 10:28:17 GMT From: gildeam@dcs.glasgow.ac.uk (Martin Gildea, MG,,,,JUN95, ) Subject: The Zeus Animation Package Zeus but I am having a few problems with it. On all of the sample animations I have managed to get my hands on, the user ent ers input by sliding a bar up and down to a certain value and then the program gene rates the appropriate amount of random numbers. What I wish to do is to allow the use r to enter their own sequence of numbers, but I don't have any idea how to modify the Zeus input panel to allow the user to do this. Any help would be appreciated. Cheers Martin. ======================================================================= 132 === Date: Fri, 24 Mar 95 12:36:32 -0800 From: mhb@pa.dec.com ("Marc H. Brown") Subject: Re: The Zeus Animation Package Martin, Zeus is domain-independent, and is not involved in providing "input" to any of the algorithms. Each algorithm specifies some way to get input, usually using a FormsVBT expression, and then interprets the data provided int he FormsVBT expression in some way. Which animation ("Session" name) are you interested in? I'll show you how to change that algorthm's input panel. Also, I just added a link on the Zeus home page http://www.research.digital.com/SRC/zeus/home.html to a Zeus tutorial that Marc Najork (with some help from me) did. It isn't complete, but it gives a good picture of what's happening and it's very readable. ======================================================================= 133 === Date: Sun, 26 Mar 1995 12:56:28 -0500 From: Jonathan Oringer Subject: Re: HP/UX vs LINUX In article <3kusad$j00@src-news.pa.dec.com> you wrote: : In article <3kt6i3$h1e@adam.cc.sunysb.edu>, joringer@cs.sunysb.edu (Jonathan Oringer) writes: : > How come the Interfaces in the HP/UX distrib are different : > from the Interfaces in the LINUX distributions? LINUX does not : > have Filename.i3 or FileStream.i3. Instead it has WrFile.i3 and : > RdFile.i3. Are they different versions? : Filename and FileStream are quite old. FileWr and FileRd are : the current interfaces. : > Is there a way to make them completely compatable? : Yes, upgrade your HP/UX version to something more recent. : - Bill Is there any way I can get an old version of Modula-3 for my linux system? I am not root at my school and I cannot just update their version even though it would be helpful for everybody :) -Jon Oringer ======================================================================= 134 === Date: 26 Mar 1995 20:40:00 +0100 From: kai@khms.westfalen.de (Kai Henningsen) Subject: Re: Problems building 3.5.1/boot-LINUX rrw1000@cus.cam.ac.uk wrote on 22.03.95 in <3kp8ei$662@lyra.csx.cam.ac.uk>: > In article <5hmz4B0EcsB@khms.westfalen.de>, > Kai Henningsen wrote: > >I think after I'm through, I'll make my version of tools 2.16 available > >somewhere. Well, I am sort-of through. Made some more changes, including some to the M3 stuff (for example, no getdirentries() on Linux - trivially fixed by calling libm3 instead of re-inventing the wheel). I've still to find some time to diff and package the patches. > :-))). Thanks ! :-). I, for one, would be grateful for some purposeful > patches (I just hacked Michel Dagenais' patches into 2.16). Well, I'm not so certain mine are that much "purposeful" :-) In the main part, it's make-all-the-arrays-a-lot-larger and correct-the- identifier-character-set. Kai -- Internet: kh@ms.maus.de, kai@khms.westfalen.de Bang: major_backbone!{ms.maus.de!kh,khms.westfalen.de!kai} ## CrossPoint v3.02 ## ======================================================================= 135 === Date: Mon, 27 Mar 95 09:31:23 -0800 From: najork@pa.dec.com (Marc Najork) Subject: Re: NT binary? > I was disappointed to find that the "bootstrap" compile process for NT involv ed > running "cl". I strenuously avoid giving money to Bill G wherever possible > (I have to use NT for work - left to myself I'd be Linux all the way). Does > anyone have an NT binary available for ftp? > > Thanks. > > Phil Jensen :: pjensen@csi.compuserve.com Phil, unfortunately, "cl", "link", and "lib" are needed for every compile, not only for bootstrapping the compiler. This means that you have to buy Microsoft Visual C++ 2.0, or another 32-bit C compiler, linker, and librarian. We would like to make the Modula-3 compiler completely stand-alone, but given our resource-constraints, it is not clear if we will actually be able to do so. -- Marc ----- Marc Najork ---- najork@src.dec.com ---- (415) 853-2153 ----- DEC Systems Research Center, 130 Lytton Avenue, Palo Alto, CA 94301 -------- http://www.research.digital.com/SRC/people/najork -------- ======================================================================= 136 === Date: 27 Mar 1995 22:08:18 GMT From: gabrius@riker.cig.mot.com (David M. Gabrius) Subject: Sample animation source w/Trestle? I'm working on an application (for a model railroad) that's going to require moving graphics. Is there any source code available that shows how to do moving graphics under Trestle? (One of the applications is sort of dispatcher's board, and I'm going to want to show the trains as they're moving around, states of switches, etc.) Thanks! -- David Gabrius -- Motorola Cellular \\ gabrius@cig.mot.com \\ 708-632-5944 Software Engineer \\"You miss too much these days if you stop to think" -U2 "And you can find/Your own way out/You can build/And I can will..." -U2 "Some days take less but most days take more" \\ #include ======================================================================= 137 === Date: Sun, 26 Mar 1995 20:42:57 GMT From: lalbers@hrz.uni-bielefeld.de ( Leif Albers) Subject: Q: Command-line Parameters, how? Hello out there, can anyone tell me how to reach command line parameters my (own) program was called with? Thanks in advance... Leif ======================================================================= 138 === Date: Tue, 28 Mar 95 09:02:41 GMT From: I.C.A.Buckner@ukc.ac.uk (Ian Buckner) Subject: Calling Modula3 from C Hi, can anyone out there help me? If I have some module that declares some operation such as (excuse the over-used names): Foo.Bar() How can this be called from a C program? I have tried using a header file defining: extern void Foo__Bar(); then #including as usual but the linker comes back with an unknown symbol error; I've even dumped out the symbols in the object files but still can't get anywhere. Any help gratefully received. Ian University of Kent Canterbury, England p.s. I don't suppose there are any Distributed Systems people out there who have looked at the Modula3 ANSAware implementation? ======================================================================= 139 === Date: 28 Mar 1995 01:32:47 GMT From: dsims@don.ece.uc.edu (David Sims (Hensgen)) Subject: Error instantiating a generic with a generic parameter :-( I'm trying to use the Table and SortedTable generic interfaces without much success. I'm trying to create a SortedTable, one of whose generic parameters is a Table. I'd appreciate a pointer on what I'm doing wrong. First, I instantiate a generic Table like so: (* this is in the file 'MyTable.i3' *) INTERFACE MyTable = Table(Integer, Integer) END MyTable. (* this is in the file 'MyTable.m3' *) MODULE MyTable = Table(Integer, Integer) END Table_Database. ** All of this compiles just fine. Next, I try to instantiate a ** generic SortedTable like so: (* this is in the file 'MySortedTable.i3' *) INTERFACE MySortedTable = SortedTable(Integer, MyTable) END MySortedTable. ** This one compiles fine too. (* this is in the file 'MySortedTable.m3' *) MODULE MySortedTable = SortedTable(Integer, MyTable) END MySortedTable. ** I get a compilation error on this one. It says: line 1: number of actuals doesn't match number of generic formals *** So ... I can't figure this one out. What am I doing wrong? thanks for the help, dave sims -- Dave Sims I'm an anarchist, and I vote. sims@usa.acsys.com Don't tread on me. http://www.acsys.com/~sims/ Finger or WWW for PGP key. KC5JKN ======================================================================= 140 === Date: 28 Mar 1995 10:06:22 GMT From: pr@cl.cam.ac.uk (Peter Robinson) Subject: Re: Calling Modula3 from C Calling Modula-3 from C is tricky because M3 has a more elaborate run-time environment. The simplest solution is to make the main program M3 and then call C via EXTERNAL routines. Calling back into M3 is then relatively straightforward. Here's an example. It calls the C code to lodge the identity of the M3 procedure to be called back which avoids having to know the actual name used by the linker. First a little M3 module to be called from C: (* M3code.i3 *) INTERFACE M3code; IMPORT Ctypes; PROCEDURE put (a: Ctypes.char_star); END M3code. (* M3code.m3 *) UNSAFE MODULE M3code; IMPORT Ctypes, IO, M3toC; PROCEDURE put (a: Ctypes.char_star) = BEGIN IO.Put (M3toC.StoT (a) & "\n"); END put; BEGIN END M3code. Now a C "module" to be called from M3: (* Ccode.i3 *) <*EXTERNAL*> INTERFACE Ccode; IMPORT Ctypes; PROCEDURE set (p: PROCEDURE (a: Ctypes.char_star)); PROCEDURE act (a: Ctypes.char_star); END Ccode. /* Ccode.c */ typedef void (*PROC)(); static PROC action; void set (p) PROC p; { action = p; } void act (a) char *a; { action (a); }; Finally, a main program: (* Main.m3 *) UNSAFE MODULE Main; IMPORT Ccode, M3code, M3toC; BEGIN Ccode.set (M3code.put); Ccode.act (M3toC.TtoS ("Hello world")); END Main. Tie it all together with an m3makefile: m3_option("-commands") import(libm3) interface ("Ccode") c_source ("Ccode") module ("M3code") implementation("Main") program("mixed") Build and run. > p.s. I don't suppose there are any Distributed Systems people out there > who have looked at the Modula3 ANSAware implementation? Sure, it was written here. Mind you, we tend to use network objects now. -- Peter Robinson Telephone: +44 1223 334637 University of Cambridge Computer Laboratory Facsimile: +44 1223 334678 New Museums Site Pembroke Street Telex: via 81240 CAMSPL-G Cambridge CB2 3QG England E-mail: pr@cl.cam.ac.uk ======================================================================= 141 === Date: 28 Mar 95 09:07:52 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Q: Command-line Parameters, how? In article lalbers@hrz.uni-bielefeld.d e ( Leif Albers) writes: Hello out there, can anyone tell me how to reach command line parameters my (own) program was called with? Look at the Params.i3 interface. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 142 === Date: 28 Mar 95 09:06:01 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Sample animation source w/Trestle? I'm working on an application (for a model railroad) that's going to require moving graphics. Is there any source code available that shows how to do moving graphics under Trestle? GraphVBT, used mostly in Zeus/Mentor applications is pretty neat for moving graphics. You can use it from Obliq too for rapid prototyping. Examples are provided in the mentor subtree or in my cache memory animation program (ftp.vlsi.polymtl.ca:pub/m3/cache-anim-1.1.tar.gz. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 143 === Date: Tue, 28 Mar 1995 11:48:00 -0500 From: Dick Orgass Subject: Re: Q: Command-line Parameters, how? In addition to the library described by Spencer Allain, there's another interface, ParseParams which is libm3parseparams.a which does much more of the parsing work than you get in a typical C program. It also deals with lots of error messages, etc. It's trivial to learn to use the interface. Once learned, it's very easy to write command line parsing code that's much simpler and more reliable than the C like code that one writes with Params. I strongly recommend ParseParams over Params. Dick ======================================================================= 144 === Date: 28 Mar 95 09:07:52 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Q: Command-line Parameters, how? In article lalbers@hrz.uni-bielefeld.d e ( Leif Albers) writes: Hello out there, can anyone tell me how to reach command line parameters my (own) program was called with? Look at the Params.i3 interface. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 145 === Date: 28 Mar 1995 14:39:27 GMT From: sims@linux.acsys.com (dave sims) Subject: Error instantiating a generic with a generic parameter :-( I'm trying to use the Table and SortedTable generic interfaces without much success. I'm trying to create a SortedTable, one of whose generic parameters is a Table. I'd appreciate a pointer on what I'm doing wrong. First, I instantiate a generic Table like so: (* this is in the file 'MyTable.i3' *) INTERFACE MyTable = Table(Integer, Integer) END MyTable. (* this is in the file 'MyTable.m3' *) MODULE MyTable = Table(Integer, Integer) END Table_Database. ** All of this compiles just fine. Next, I try to instantiate a ** generic SortedTable like so: (* this is in the file 'MySortedTable.i3' *) INTERFACE MySortedTable = SortedTable(Integer, MyTable) END MySortedTable. ** This one compiles fine too. (* this is in the file 'MySortedTable.m3' *) MODULE MySortedTable = SortedTable(Integer, MyTable) END MySortedTable. ** I get a compilation error on this one. It says: line 1: number of actuals doesn't match number of generic formals *** So ... I can't figure this one out. What am I doing wrong? thanks for the help, dave sims -- Dave Sims I'm an anarchist, and I vote. sims@usa.acsys.com Don't tread on me. http://www.acsys.com/~sims/ Finger or WWW for PGP key. KC5JKN ======================================================================= 146 === Date: Tue, 28 Mar 1995 14:49:43 GMT From: spencer@ERA.COM (Spencer Allain) Subject: Re: Q: Command-line Parameters, how? In article lalbers@hrz.uni-bielefeld.d e ( Leif Albers) writes: > Hello out there, > can anyone tell me how to reach command line parameters my > (own) program was called with? > > Thanks in advance... > > Leif Unless things have changed, there should be a module called "Params", that is part of libm3, designed to grab command line parameters. There is a CARDINAL variable called "Params.Count", that will tell you the number of parameters, including the name used to invoke the program. The only procedure is "Params.Get(CARDINAL)" that simply returns the nth parameter. NOTE: parameters run from 0 .. Params.Count - 1, where 0 is the program name. Hope this helps. ======================================================================= 147 === Date: Tue, 28 Mar 1995 16:18:56 GMT From: shang@corp.mot.com (David L. Shang) Subject: Re: Undefined number of arguments In article <3kbstf$lc0@lyra.csx.cam.ac.uk> pbm1001@cam.ac.uk (Paul Menage) writes: > In article <9543@merlin.ukc.ac.uk>, ic4@ukc.ac.uk (I.Chatzigiannakis) writes: > > > >Do you have any idea how I can make a procedure that accepts many > >arguments without a preset number. > >I know how to code it in c++ (void myfunc(char *format,...)) but > >what about modula-3? > In Cluster-2, variable number of argumnets is provided, but unlike C++, it is safe. No low-level byte-wise coding (e.g. va_start, va_args ...) is required. The variable number of argumnets will be composed into a heterogeneous list without losing type information. For a simple print with default format, you are not necessary to provide a format at all. David ======================================================================= 148 === Date: 30 Mar 1995 16:11:46 -0500 From: hosking@cs.purdue.edu (Tony Hosking) Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS >>>>> "Guido" == Guido Muesch writes: Guido> I tried compiling Modula-3 on a Solaris 2.3 machine with gcc Guido> (SOLgnu release). I get the follwoing error: ---- building m3 ---- Guido> gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Guido> Arg_i.o Arg_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Guido> Unit_m.o Utils_i.o Utils_m.o WebFile_i.o WebFile_m.o Main_m.o Guido> ../../m3front/SOLgnu/libm3front.a ../../m3linker/SOLgnu/libm3link.a Guido> ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3.a Guido> ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS Guido> -lsocket -lnsl -lm ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS: Guido> not found ld: fatal: File processing errors. No output written to Guido> m3 *** error code 1 Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line Guido> 58: command execute failed *** call stack *** Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line Guido> 58: call to built-in exec "./make.boot", line 31: call to procedure Guido> boot_prog Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to Guido> gcc. Well, I installed gcc 2.6.3 hoping this will solve the Guido> problem, but it doesn't. I installed it using Sun's as and ld. Just delete the line: boot_import ("-lDYNAMIC_LINKING_AFTER_THIS") from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be away and laughing. -- Tony Hosking Voice: (317) 494-6001 Department of Computer Sciences Fax: (317) 494-0739 Purdue University Email: hosking@cs.purdue.edu West Lafayette, IN 47907URL: http://www.cs.purdue.edu/people/hosking ======================================================================= 149 === Date: Thu, 30 Mar 95 13:43:04 -0800 From: mcjones@pa.dec.com Subject: Re: Error instantiating a generic with a generic parameter :-( Dave, You say: (* this is in the file 'MySortedTable.m3' *) MODULE MySortedTable = SortedTable(Integer, MyTable) END MySortedTable. ** I get a compilation error on this one. It says: line 1: number of actuals doesn't match number of generic formals Your problem is caused by the fact that SortedTable.mg takes 3 parameters instead of 2: GENERIC MODULE SortedTable (Key, Value, Tbl); (* Where "Key.T" and "Value.T" are types, "Tbl=Table(Key, Value)", and "Key.Compare(READONLY k1, k2: Key.T): [-1..1]" is a total order. *) So write: MODULE MySortedTable = SortedTable(Integer, Integer, MyTable) END MySortedTable. (It would have been good for us to mention this in SortedTable.ig and "Some Useful Modula-3 Interfaces".) Paul McJones DEC Systems Research Center mcjones@pa.dec.com ======================================================================= 150 === Date: Wed, 29 Mar 1995 20:05:04 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: help wanted converting code from m3 v2.11 to v3.x I'm trying to bring a large application into the modern world, and I noticed some things missing from the old version 2.11 libm3. First of all, the functionality of Filename.FileIsReadable Filename.SearchPath Filename.RdFromPath seems to be missing. Not a big problem since I can write that stuff myself. The showstopper is that RTHeap.Duplicate is gone. Does anybody know how to copy a heap object in m3 v3.x? (The version I actually have is Michel Dagenais's Linux version 3.3.) Norman -- Norman Ramsey norman@bellcore.com ======================================================================= 151 === Date: 29 Mar 1995 14:49:13 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Opinions on M3->C interface "consistency" I'd like some other opinions on a good way to deal with the following somewhat trivial issue. In making an interface to a C library (OpenGL, in particular), there is a tradeoff between "consistency" with the original C constant/variable names and consistency with the way typical .i3 files are written, as illustrated here: GL.h: #define GL_ACCUM 0x0100 GL.i3: CONST GL_ACCUM: INTEGER = 16_0100; But, then to reference the constants, we write GL.GL_ACCUM, which is long (writing GL.ACCUM would be nicer, I'd think). The problem is, when the GL_ prefixes are stripped, we end up with invalid identifiers, such as 2_BYTES, or reserved words, such as RETURN. Of course, these can just have something prepended to them (which has to be done in some cases anyway). The advantage of blind conversion (as shown above) is that users of the package have a well defined way of converting C examples/documentation they read (just stick the GL. on the front). But, some people here complain it's too wordy. :-) Anybody have any other arguments one way or the other? -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 152 === Date: 29 Mar 1995 21:15:42 GMT From: 7231780@mcimail.com Subject: Re: Static vs Dynamic Typing: Effects on Productivity? In <3536sa$5se@cantaloupe.srv.cs.cmu.edu>, rwh@cs.cmu.edu (Robert Harper) write s: >For example, one cannot tell >by the bit pattern whether the value in a variable represents a "set" >or a "time of day" or a "favorite color of the author of the program". >Nor can one check at run-time properties of, say, functions that can be >enforced by a static type discipline. In a dynamically typed system such as Smalltalk (or, untyped), I don't have to examine the bit pattern to determine the value. The class lookup mechanism kno ws the value representation and invokes the class that will process the variabl e. (polymorphism). This increases programmer productivity factorially over st atically typed compilers. Therefore, the argument is flawed by the response "I, the programmer, do not ca re." Also, dynamically typed languages also have "isKindOf" queries to determi ne type if they have to. Your argument is flawed. ======================================================================= 153 === Date: 30 Mar 1995 17:43:27 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS >>>>> On 30 Mar 1995 13:16:18 GMT, >>>>> odiug@manray.informatik.rwth-aachen.de (Guido Muesch) said: Guido> I tried compiling Modula-3 on a Solaris 2.3 machine with gcc Guido> (SOLgnu release). I get the follwoing error: Guido> ---- building m3 ---- Guido> gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o Ar g_m.o Msg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o Utils_i.o Utils_m .o WebFile_i.o WebFile_m.o Main_m.o ../../m3front/SOLgnu/libm3front.a ../../m3l inker/SOLgnu/libm3link.a ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu /libm3.a ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS -lsocket -lnsl -lm Guido> ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS: not found Guido> ld: fatal: File processing errors. No output written to m3 Guido> *** error code 1 Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: command execute failed Guido> *** call stack *** Guido> "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: call to built-in exec Guido> "./make.boot", line 31: call to procedure boot_prog Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to gcc. Guido> Well, I installed gcc 2.6.3 hoping this will solve the problem, but it Guido> doesn't. I installed it using Sun's as and ld. Guido> Or is this just a bug in the templates file? Might be. First, the compile command up there should not have been gcc, but m3-gcc. m3-gcc should be something like the following shell script: ------------------------------- #!/bin/sh CMD="gcc " for x do if [ "-lDYNAMIC_LINKING_AFTER_THIS" = "$x" ]; then CMD="$CMD -Xlinker -Bdynamic " else CMD="$CMD $x " fi done exec $CMD ------------------------------- The purpose of this is to get around a shortcoming in m3 and the Solaris libraries, namely that you can't entirely statically link on Solaris (there are name conflicts libbsd.a and libc.a, and no libaio.a at all!) Check that the build_standalone entry in the SOLgnu template looks like this: proc build_standalone() is % --- reset the linker to avoid shared libraries. % In SOLgnu we cannot do this completely, because the -lbsd and -lc % libraries clash when linked statically, and there is no static -laio. % So we link try to do it, and fail miserably. Finish by hand. Sigh. M3_CONFIG += "-Y2@m3-gcc@-compat-bsd@-Xlinker@-dy@-Xlinker@-Bstatic@" M3_CONFIG += "-z2@-lDYNAMIC_LINKING_AFTER_THIS@-lsocket@-lnsl@-lm@" M3_CONFIG += "-Y6@" & LIB_USE & "/m3cgc1@-quiet@" M3_CONFIG += "-Y7@/usr/ccs/bin/as@-s@" end -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 154 === Date: 30 Mar 1995 16:48:00 GMT From: odiug@manray.informatik.rwth-aachen.de (Guido Muesch) Subject: Solaris 2.3: more fun building m3 Still have some more Problems with SOLgnu: ---------------------- building netobjd ---------------------- mkdir SOLgnu --- building in SOLgnu --- m3 -w1 -why -g -o netobjd -F/tmp/qkAAAa004IC new source -> compiling ../src/NMonRegistrySvr.i3 new source -> compiling ../src/NMonRegistrySvr.m3 new source -> compiling ../src/NetObjDaemon.m3 -> linking netobjd ld: fatal: library -laio: not found ld: fatal: symbol `_mkarglst' is multiply defined: (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o) ); ld: fatal: symbol `_doprnt' is multiply defined: (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o) ); ld: fatal: symbol `_getarg' is multiply defined: (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(doprnt.o) ); ld: fatal: File processing errors. No output written to netobjd Fatal Error: program "/opt/m3/lib/m3/SOLgnu/m3-gcc" failed, exit status = 256 Why does it need -laio? And why does it want to link with /usr/ucblib/libucb.a? Can anybody give me any hints on compiling Modula-3 on a Solaris machine with gcc? Ciao Guido "just wanted to install M3, fast" ======================================================================= 155 === Date: 30 Mar 1995 13:16:18 GMT From: odiug@manray.informatik.rwth-aachen.de (Guido Muesch) Subject: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS I tried compiling Modula-3 on a Solaris 2.3 machine with gcc (SOLgnu release). I get the follwoing error: ---- building m3 ---- gcc -compat-bsd -o m3 _m3main.o M3Backend_i.o M3BackPosix_m.o Arg_i.o Arg_m.o M sg_i.o Msg_m.o M3Path_i.o M3Path_m.o Unit_i.o Unit_m.o Utils_i.o Utils_m.o WebF ile_i.o WebFile_m.o Main_m.o ../../m3front/SOLgnu/libm3front.a ../../m3linker/S OLgnu/libm3link.a ../../m3middle/SOLgnu/libm3middle.a ../../libm3/SOLgnu/libm3. a ../../m3core/SOLgnu/libm3core.a -lDYNAMIC_LINKING_AFTER_THIS -lsocket -lnsl - lm ld: fatal: library -lDYNAMIC_LINKING_AFTER_THIS: not found ld: fatal: File processing errors. No output written to m3 *** error code 1 "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: command execute failed *** call stack *** "/opt/src/modula-3/boot-SOLgnu/m3build/templates/COMMON.BOOT", line 58: call to built-in exec "./make.boot", line 31: call to procedure boot_prog Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to gcc. Well, I installed gcc 2.6.3 hoping this will solve the problem, but it doesn't. I installed it using Sun's as and ld. Or is this just a bug in the templates file? Can somebody enlighten me? Thanx Guido ======================================================================= 156 === Date: 30 Mar 1995 12:05:31 -0600 From: beede@gateway.sctc.com (Mike Beede) Subject: Modula-3 on LINUX reresolving DLLs Well, I was happy that the distribution finally installed (with the patched DLL tools) and would compile and linke m3 programs. Now I find I was premature in my celebration. I wrote a little "hello, world" program and it works fine. As I recall it depended on Wr and Stdio. I add an object definition and try to print one of the internal values (this means importing Fmt, too), and I suddenly get : can't find libm3.so.3.5 When I run it under strace, I find odd things happening. First, it _finds_ libm3 and several other libraries (libm, libc, and another one that escapes me). It does some things that look initialization-like (allocates memory, gets the time of day, some fstats, etc.) and suddenly starts looking for shared libraries again (starting with the first one)! Apparently it isn't using LD_LIBRARY_PATH, because it doesn't look in the directory that the bootstrap installed the library in this time. I ran BadBricks under strace and it looked the same, except it never called uselib() again. However, I notice an odd thing about BadBricks--one in a while it dies suddenly and emits the error message : can't find libm3ui.so (or something like that -- it had "ui" in it). Thing was, it found ui earlier if it behaved the same as the straced version of itself. It seems that something makes an m3 program lose its mind and begin the dynamic linking process over again. Anyone have a suggestion on how I should proceed? I guess one possibility is waiting for the ELF tools and hoping that rectifies the problem.... Thanks, Mike Beede -- Mike Beede - (612) 628-2720 SCC beede@sctc.com ======================================================================= 157 === Date: 30 Mar 95 08:45:29 From: dagenais@notung.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: help wanted converting code from m3 v2.11 to v3.x The showstopper is that RTHeap.Duplicate is gone. Does anybody know how to copy a heap object in m3 v3.x? (The version I actually have is Michel Dagenais's Linux version 3.3.) Well, you can Pickle in and out of a TEXT or Pipe. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 158 === Date: Fri, 31 Mar 95 15:48:53 -0800 From: heydon@pa.dec.com Subject: Re: Error instantiating a generic with a generic parameter :-( Dave, Paul is right, you weren't providing enough parameters to the instantiation of the generic module. The easiest way to instantiate generics --- and one that would have helped you to avoid this problem --- is to use the quake template that comes with the generic package. To do this, you would write something like: table("IntInt", "Integer", "Integer") sorted_table("IntIntIntTbl", "Integer", "IntIntTbl") in your m3makefile. Each of the quake procedures "table" and "sorted_table" takes as a first parameter a string that is used to construct the name of the table. If we use "" to denote the first parameter, then the names for each of the tables is: table: Tbl sorted_table: SortedTbl Hence, the two lines above will create the following four files in the *derived* directory and compile them automatically: IntIntTbl.i3, IntIntTbl.m3, SortedIntIntIntTblTbl.i3, SortedIntIntIntTblTbl.m3 [Note: The type "IntIntTbl" is pre-instantiated in libm3, so your type "MyTable.T" is actually equivalent to "IntIntTbl.T" and could be omitted. The "table" line in the m3makefile to instantiate an "IntIntTbl" would also have to be omitted, or else an error would probably occur at link-time.] The quake templates are included in the packages of their corresponding generic interfaces. For example, the template files for the "Table" and "SortedTable" interfaces are: table/src/table.tmpl sortedtable/src/sortedtable.tmpl Most of the quake templates in the Modula-3 distribution could stand to be better documented. - Allan -------------------------------------------------------------------- Allan Heydon Digital Equipment Corporation heydon@pa.dec.com Systems Research Center (415) 853-2142 130 Lytton Avenue (415) 853-2104 (FAX) Palo Alto, CA 94301 ======================================================================= 159 === Date: 31 Mar 1995 16:27:00 GMT From: bm@shadow.cs.columbia.edu (Blair MacIntyre) Subject: Re: Solaris 2.3: -lDYNAMIC_LINKING_AFTER_THIS >>>>> On 30 Mar 1995 16:11:46 -0500, hosking@cs.purdue.edu (Tony >>>>> Hosking) said: Guido> Should this -lDYNAMIC_LINKING_AFTER_THIS be a special option to Guido> gcc. Well, I installed gcc 2.6.3 hoping this will solve the Guido> problem, but it doesn't. I installed it using Sun's as and ld. Tony> Just delete the line: Tony> boot_import ("-lDYNAMIC_LINKING_AFTER_THIS") Tony> from the file m3/SOLgnu/make.boot in boot-SOLgnu and you will be away and Tony> laughing. Well, laughing might not be the right word. You cannot statically link an m3 binary on solaris without this option and without using the m3-gcc script (or something like it). If you remove it, remove all "build_standalone()" commands from your m3makefiles. -- Blair MacIntyre (bm@cs.columbia.edu), Graduate Student (Graphics and UI Lab) smail: Dept. of Computer Science, 450 Computer Science Building, 500 W 120 St. Columbia University, New York, NY 10027 ======================================================================= 160 === Date: 31 Mar 1995 11:25:03 -0500 From: bm@news.cs.columbia.edu (Blair MacIntyre) Subject: Solaris 2.3: more fun building m3 >>>>> On 30 Mar 1995 16:48:00 GMT, >>>>> odiug@manray.informatik.rwth-aachen.de (Guido Muesch) said: Guido> Still have some more Problems with SOLgnu: Guido> ---------------------- building netobjd ---------------------- Guido> mkdir SOLgnu Guido> --- building in SOLgnu --- Guido> m3 -w1 -why -g -o netobjd -F/tmp/qkAAAa004IC Guido> new source -> compiling ../src/NMonRegistrySvr.i3 Guido> new source -> compiling ../src/NMonRegistrySvr.m3 Guido> new source -> compiling ../src/NetObjDaemon.m3 -> linking netobjd Guido> ld: fatal: library -laio: not found Guido> ld: fatal: symbol `_mkarglst' is multiply defined: Guido> (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do prnt.o)); Guido> ld: fatal: symbol `_doprnt' is multiply defined: Guido> (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do prnt.o)); Guido> ld: fatal: symbol `_getarg' is multiply defined: Guido> (file /usr/ucblib/libucb.a(doprnt.o) and file /usr/lib/libc.a(do prnt.o)); Guido> ld: fatal: File processing errors. No output written to netobjd Guido> Fatal Error: program "/opt/m3/lib/m3/SOLgnu/m3-gcc" failed, exit status = 256 Guido> Why does it need -laio? And why does it want to link with Guido> /usr/ucblib/libucb.a? The problems you see there are exactly the problems that the m3-gcc script (with the -lDYNAMIC_LINKING_AFTER_HERE in the template) are designed to solve. As I said before, there is no libaio.a (only libaio.so), and libucb and libc have name conflicts. That is why I set up the scripts to link those 3 libraries dynamically. Did you remove the -lDYNAMIC_LINKING_AFTER_HERE flag and not use m3-gcc?? Add m3_option("-commands") to your m3makefile and make sure it is using m3-gcc ... Blair ======================================================================= 161 === Date: 31 Mar 1995 22:07:26 GMT From: kalsow@src.dec.com (Bill Kalsow) Subject: Re: help wanted converting code from m3 v2.11 to v3.x In article , norman@flaubert.bellcore.com (Norm an Ramsey) writes: > > Does anybody know how to copy a heap object in m3 v3.x? > (The version I actually have is Michel Dagenais's Linux version 3.3.) I don't remember exactly what RTHeap.Duplicate did, but the following code should produce a shallow copy of any traced reference: PROCEDURE Duplicate (r: REFANY): REFANY = VAR tc := TYPECODE (r); n_dims : INTEGER; res : REFANY; shape : RTHeapRep.ArrayShape; BEGIN IF (r = NIL) THEN RETURN NIL END; (* allocate a new object of the same type (and shape) as the old one *) RTHeapRep.UnsafeGetShape (r, n_dims, shape); IF (n_dims <= 0) THEN res := RTAllocator.NewTraced (tc); ELSE res := RTAllocator.NewTracedArray (tc, SUBARRAY(shape^, 0, n_dims )); END; (* copy the old data into the new object *) RTMisc.Copy (RTHeap.GetDataAdr (r), RTHeap.GetDataAdr (res), RTHeap.GetDataSize (r)); RETURN res; END Duplicate; Of course, you can use Pickle to produce deep copies. - Bill Kalsow ======================================================================= 162 === Date: Wed, 29 Mar 1995 09:23:41 -0500 From: douglm@rpi.edu (Mike Douglass) Subject: Re: SRC M3 3.5.1 on AIX 3.1 with gcc 2.6.0 >Farshad Nayeri wrote: >I am trying to compile SRC Modula-3 3.5.1 on AIX 3.1. I have gcc 2.6.0 >for AIX, and /bin/cc > ... >I will be happy to make the binary release available on the net once I >get it working. > I'd be interested in knowing how the AIX port of m3 3.5.1 to AIX goes. It's beginning to look as if I have to get around to installing m3 on our RS6000s. We have AIX 3.2.5 but it looks like we will be seeing AIX 4.1 in the not too distant future. Thanks for any information. Mike Douglass ======================================================================= 163 === Date: 31 Mar 95 15:14:54 From: dagenais@gutrune.vlsi.polymtl.ca (Michel Dagenais) Subject: Re: Modula-3 on LINUX reresolving DLLs In article <3lertb$8l7@gateway.sctc.com> beede@gateway.sctc.com (Mike Beede) wr ites: Well, I was happy that the distribution finally installed (with the patched DLL tools) and would compile and linke m3 programs. Humm, did you compile it yourself, which patches did you apply to the DLL tools... Now I find I was premature in my celebration. ... When I run it under strace, I find odd things happening. First, it _finds_ libm3 and several other libraries (libm, libc, and another one that escapes me). It does some things that look initialization-like (allocates memory, gets the time of day, some fstats, etc.) and suddenly starts looking for shared libraries again (starting with the first one)! Apparently it isn't using LD_LIBRARY_PATH, because it doesn't look in the directory that the bootstrap installed the library in this time. If the addresses you reserved for shared libraries do overlap, all sorts of strange things may happen. how I should proceed? I guess one possibility is waiting for the ELF tools and hoping that rectifies the problem.... ELF is definitely a huge improvement over the current DLLs. It is working now and well. They have started planning the great LINUX switch to ELF. These things take time though until popular LINUX distributions get everything recompiled under ELF. -- Prof. Michel Dagenais http://www.vlsi.polymtl.ca/dagenais/home/home.html Dept of EE and Computer Eng. dagenais@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4029 ======================================================================= 164 === Date: 31 Mar 1995 21:51:50 GMT From: umesh@fugue.lcs.mit.edu (Umesh Maheshwari) Subject: need font-lock support for modula3 mode in lemacs Does anyone have a nice "modula3-font-lock-keywords" to color modula-3 programs in lucid emacs? umesh -- ================================================================== umesh@lcs.mit.edu Umesh Maheshwari Office: 545 Tech Square, #527 Home: 341 Hurley St, #3 Cambridge, MA 02139 Cambridge, MA 02141 Phone 617-253-6015 Phone 617-492-3717 ================================================================== ======================================================================= 165 === Date: 31 Mar 1995 10:42:14 GMT From: michael seitz Subject: what is modula 3 Hi, i often writing programs in an Modula 2 Environment (DOs) can you help me what is modula 3 ? micha ======================================================================= 166 === Date: Fri, 31 Mar 1995 21:20:46 GMT From: norman@flaubert.bellcore.com (Norman Ramsey) Subject: Quake/m3build question -- installing resources I'd like to make ``resources'' (arbitrary binary files) available in a standard place for an application that needs them. (A location analogous to /proj/pkg/foo-rsrc/src would be just fine.) Unfortunately, I don't see any way to do this with m3build and quake (I have version 3.3). Note well that I do *not* want to use m3bundle to turn the resources into a module; I expect the resources to change more rapidly than the program that uses them, so I want to get them out of the file system dynamically. Suggestions appreciated. Norman -- Norman Ramsey norman@bellcore.com ======================================================================= 167 === Date: 29 Mar 1995 06:49:07 GMT From: Horst Stenzel Subject: Problem with Random Integers w/M3 3.3 / LINUX 1.0.9 We are faced with false results from Random`s "rand.integer(min,max)" when running under LINUX: Instead of yielding results in the range (min,max), the results are produced in the range (0,max-min). There seems to bee some erroneous bit tweeking involved. Is it worth while getting a newer version, or do we have to look at the internals of the package? Please respond directly to : isa009@advs2.gm.fh-koeln.de (Martina Rothkamp-Schriefl)