From @taunivm.tau.ac.il:flibedin@taurus.bitnet Sun Jan 19 11:30:38 1992 Received: from TAUNIVM.TAU.AC.IL by optima.cs.arizona.edu (4.1/15) id AA14766; Sun, 19 Jan 92 11:30:38 MST Received: from TAURUS.BITNET by TAUNIVM.TAU.AC.IL (IBM VM SMTP V2R1) with BSMTP id 9224; Sun, 19 Jan 92 20:29:31 IST From: flibedin%taurus.bitnet@taunivm.tau.ac.il Return-Path: Received: from virgo (virgo.math.tau.ac.il) by math.tau.ac.il (4.1/TAU-4.8) id AA07694; Sun, 19 Jan 92 20:32:49+020 Comments: If you have trouble reaching this host as math.tau.ac.il Please use the old address: user@taurus.bitnet Reply-To: Received: by virgo (4.0/TAUSUB-2.0) id AA01940; Sun, 19 Jan 92 20:32:49+020 Date: Sun, 19 Jan 92 20:32:49+020 From: flibedin%taurus.bitnet@taunivm.tau.ac.il Message-Id: <9201191832.AA01940@virgo> To: info-sr@cs.arizona.edu Subject: Current status of SR?? I would like to know the current status of the SR development at Arizona and other sites. Some time ago I heard about a inminent new release and bare machine implementations, however to date nothing has happened. thanks, Fernando Libedinsky CS Dept, Tel-Aviv University flibedin@math.tau.ac.il From gmt Tue Jan 21 15:01:52 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15) id AA27470; Tue, 21 Jan 92 15:01:52 MST Date: Tue, 21 Jan 92 15:01:50 MST From: "Gregg Townsend" Message-Id: <9201212201.AA03919@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Tue, 21 Jan 92 15:01:50 MST To: info-sr Subject: Re: Current status of SR?? Work on Version 2 of SR has progressed well in recent months, and we will release a preliminary version in March. This will contain nearly all of the planned new features and will run on a much wider variety of machines than Version 1. New features in Version 2 include shared global variables and operations; circular imports; real numbers and math functions; formatted I/O; a more general syntax with fewer special cases; a more robust system with better error checking; and many other changes. Version 2 of the SR Language will be documented in the book "The SR Programming Language: Concurrency in Practice", by Greg Andrews and Ron Olsson, which is scheduled for publication by Benjamin/Cummings in July of 1992. For the preliminary release of V2 we will provide notes outlining the new features. V2, like V1, runs under Unix. An experimental, bare machine version of SR has been implemented on top of the x-kernel (also distributed by Arizona), but it is not part of the distribution. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From gmt Mon Mar 23 14:51:09 1992 Date: Mon, 23 Mar 92 14:51:09 MST From: "Gregg Townsend" Message-Id: <9203232151.AA17720@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (4.1/15) id AA17720; Mon, 23 Mar 92 14:51:09 MST To: info-sr Subject: Announcing SR Version 2 Version 2 of the SR programming language is now available from the University of Arizona by anonymous FTP or by mail. New features include shared global variables and operations, circular imports, real numbers and math functions, formatted I/O, a more general syntax with fewer special cases, a more robust system with better error checking, true multiprocessing when run on a Sequent Symmetry, and many additional enhancements. Version 2 is tested on Sun4, Sun3, DECstation, SGI Iris, HP RISC and 9000/300, NeXT, and Sequent Symmetry platforms. Code is also included for the DG AViiON, IBM RS/6000, DEC VAX, Encore Multimax, Apollo DN, and others. This is a "preliminary" release of version 2 in that we have a few more things to do before we will consider 2.0 complete. However, even in current form it is much more robust and feature-rich than version 1.1. We anticipate the official release of version 2.0 this summer, in conjunction with the publication by Benjamin/Cummings of "The SR Programming Language: Concurrency in Practice", by Gregory R. Andrews and Ronald A. Olsson SR is available by anonymous FTP from cs.arizona.edu. There are two compressed tar files; be sure to transfer them in binary (image) mode. The files are: /sr/sr.tar.Z: The SR programming language, including source code, documentation in PostScript and troff form, checkout programs, and examples. /sr/vs.tar.Z: The extended verification suite, needed only if you're going to modify the system or port it to a new architecture. Electronic mail interfaces to FTP are available at BITFTP@PUCC.BITNET (for BITNET members) or ftpmail@decwrl.dec.com (for anyone). For details, send either server a message with ``help'' in the body. If you pick up SR by FTP, please send mail to sr-project@cs.arizona.edu to let us know. We'll also put you on the INFO-SR mailing list (see below) if you so request. SR is also available by mail on tape, Sun cartridge, or two 1.44 MB diskettes. For details and an order blank, contact the SR project at the email address above, or call (602) 621-8448, or send a FAX to (602) 621-4246, or write to: SR Project Department of Computer Science University of Arizona Tucson, AZ 85721 An electronic mailing list is in place for discussing SR topics. You can join by sending your email address to info-sr-request@cs.arizona.edu or uunet!arizona!sr-project. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From LCMI1JHS@BRUFSC.BITNET Mon Apr 13 07:04:18 1992 Received: from Arizona.edu (Merlin.Telcom.Arizona.EDU) by optima.cs.arizona.edu (4.1/15) id AA24733; Mon, 13 Apr 92 07:04:18 MST Received: from BRUFSC.BITNET (MAILER@BRUFSC) by Arizona.edu (PMDF #12663) id <01GISG6ZVA0GA9PVOT@Arizona.edu>; Mon, 13 Apr 1992 07:03 MST Received: by BRUFSC (Mailer R2.08) id 2209; Mon, 13 Apr 92 10:59:09 BRA Date: Mon, 13 Apr 92 10:55:43 BRA From: Jorge Hermogenes de Souza To: info-sr@cs.arizona.edu Message-Id: <01GISG6ZVA0GA9PVOT@Arizona.edu> Organization: Nucleo de processamento de Dados-UFSC/BRASIL X-Envelope-To: info-sr@cs.Arizona.edu @ ftp cs.arizona.edu netdata @ user anonymous @ cd sr @ dir @ binary @ get sr.tar sr.tar @ get vs.tar vs.tar @ quit Jorge Isto eh um teste From shartley@king.mcs.drexel.edu Mon Apr 13 07:28:25 1992 Received: from mcs.drexel.edu (KING.MCS.DREXEL.EDU) by optima.cs.arizona.edu (4.1/15) id AA25378; Mon, 13 Apr 92 07:28:25 MST Received: by mcs.drexel.edu (4.1/SMI-4.0) id AA02957; Mon, 13 Apr 92 10:27:49 EDT Date: Mon, 13 Apr 92 10:27:49 EDT From: shartley@KING.MCS.DREXEL.EDU (Stephen J. Hartley) Message-Id: <9204131427.AA02957@mcs.drexel.edu> To: info-sr@cs.arizona.edu Subject: a little puzzling In converting some of my example programs from SR 1.1 to SR 2.0, I came across the following, which was a little puzzling. Is there an explanation? If the process do_it end do_it pair is left out of the program below, then only one helper resource seems to be created no matter the value of number. Stephen J. Hartley, Visiting Assistant Professor, office ph: (215) 895-2678 Math and Computer Science, Drexel University, Philadelphia, PA 19104 shartley@mcs.drexel.edu =============================================================================== resource helper(id : int) write("helper", id, "is alive") # The "process" below is necessary. Without it, no matter what "number" is # below in "resource user", only one helper is created and running. process do_it var napping : int do true -> napping := int(random(3000)) writes("age=", age(), ", helper ", id, " is napping for ", napping, "ms\n") nap(napping) od end do_it end helper resource user import helper body user() const NUMBER := 5 var number : int := NUMBER var hc : cap helper # const seeded := 42.0 # Change to 0.0 or leave out these # seed(seeded) # two lines altogether to get # irreproducible random nuumbers getarg(1, number) write("resource user starting", number, "helpers") fa i := 1 to number -> hc := create helper(i) af end user From gmt Mon Apr 13 08:11:33 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (4.1/15) id AA27368; Mon, 13 Apr 92 08:11:33 MST Date: Mon, 13 Apr 92 08:11:31 MST From: "Gregg Townsend" Message-Id: <9204131511.AA22361@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 13 Apr 92 08:11:31 MST To: info-sr@cs.arizona.edu, shartley@king.mcs.drexel.edu Subject: Re: a little puzzling Resource creation completes when the new resource exits its initialization code; in version 2 this is the top-level body code. With the "process...end" bracketing, the "do true" loop is spun off as a separate process, the body code falls off the end, and the creator proceeds to its next iteration. Without the bracketing, process creation never completes because the new helper resource is still initializing in an infinite loop. The user resource remains blocked on the creation of the first resource and so it never creates another. Another way to make this work is to add a "reply" in helper before entering the loop. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From uunet!pluto.crd.ge.com!bownes Mon Apr 13 20:21:32 1992 Received: from univers.cs.arizona.edu by optima.cs.arizona.edu (4.1/15) id AA01337; Mon, 13 Apr 92 20:21:32 MST Received: from uunet.UUCP by univers.cs.arizona.edu; Mon, 13 Apr 92 20:21:30 MST Received: from crdgw1.ge.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA16090; Mon, 13 Apr 92 12:22:27 -0400 Received: by crdgw1.ge.com (5.57/GE 1.137) id AA10457; Mon, 13 Apr 92 12:17:18 EDT Received: from peterpan.wdw by pluto.crd.Ge.Com (4.1/SMI-4.0/GE-CRD @(#)sun4.ease 1.13 4/13/89) id AA13391; Mon, 13 Apr 92 12:17:13 EDT From: uunet!pluto.crd.ge.com!bownes (Robert M. Bownes) Message-Id: <9204131617.AA13391@pluto.crd.Ge.Com> Subject: please remove me from the list To: arizona!info-sr Date: Mon, 13 Apr 92 12:13:49 EDT X-Mailer: ELM [version 2.3 PL0] please remove uunet!ssi!rmb from the list. I have moved and am no longer involved in sr thanks, bob iii From dilger@cs.ucdavis.edu Thu Apr 23 17:30:04 1992 Received: from toadflax.cs.ucdavis.edu by optima.cs.arizona.edu (4.1/15) id AA28876; Thu, 23 Apr 92 17:30:04 MST Received: by toadflax.cs.ucdavis.edu (4.1/UCD.CS.1.1) id AA17938; Thu, 23 Apr 92 17:30:01 PDT Date: Thu, 23 Apr 92 17:30:01 PDT From: dilger@cs.ucdavis.edu (Mike Dilger) Message-Id: <9204240030.AA17938@toadflax.cs.ucdavis.edu> To: info-sr@cs.arizona.edu Subject: curses and SR I am about to embark upon creating an sr file that defines all the curses types and functions so that curses routines can be called from sr code. I am curious if this has already been done. I don't want to re-invent the wheel -Mike Dilger (dilger@toadflax.cs.ucdavis.edu) From @udel.edu:carroll@cis.udel.edu Thu Apr 23 19:20:59 1992 Received: from udel.edu (louie.udel.edu) by optima.cs.arizona.edu (4.1/15) id AA06475; Thu, 23 Apr 92 19:20:59 MST Received: from sol.cis.udel.edu by louie.udel.edu id aa25232; 23 Apr 92 22:14 EDT Received: from relay.udel.edu by sol.cis.udel.edu id aa00146; 24 Apr 92 2:14 GMT To: info-sr@cs.arizona.edu Subject: SR and Xwindows From: "Mark C. Carroll" Date: Thu, 23 Apr 92 22:13:58 -0400 Sender: carroll@cis.udel.edu Message-Id: <9204240214.aa00146@sol.cis.udel.edu> Very soon, I'll be implementing a simulation of a rather bizzare parallel architecture, distributed through a network of Suns, using SR. One machine will be acting as a manager, and maintaining a graphic display of the machine state. I'd _really_ like to be able to do this under X, but I don't have the time to build the library. So, has anyone explored the possibility of building an X-windows library for SR? From root Thu Jul 2 03:10:58 1992 Received: from cheltenham.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA18618; Thu, 2 Jul 1992 10:10:59 -0700 Date: Thu, 2 Jul 1992 10:10:58 -0700 From: "Root on Cheltenham" Message-Id: <199207021710.AA05962@cheltenham.cs.arizona.edu> Received: by cheltenham.cs.arizona.edu; Thu, 2 Jul 1992 10:10:58 -0700 Apparently-To: beacker@mips.com Apparently-To: Info-SR Apparently-To: mailing Apparently-To: list We have added your name to the info-sr mailing list; welcome aboard! Info-sr is a mailing list for discussing all aspects of the SR programming language and its implementation. Your participation is encouraged; the list is *not* restricted to SR "experts". Messages sent to "info-sr@cs.arizona.edu" are immediately redistributed to all members of the mailing list. It's good practice to include a signature giving your name and email address, because not all mailers preserve these. Administrative requests (e.g. changes of address, removal from list) should be sent to "info-sr-request@cs.arizona.edu" and not to the general mailing list. Other questions that are not of general interest can be sent directly to "sr-project@arizona". If you should submit an item to info-sr and get back failure notifications from distant mailers, you can help us eliminate such problems by sending these notification messages to the request address above. Our software tries to arrange for failure notifications to be sent to us, but this isn't foolproof. From sgccdux@citecuc.citec.oz.au Mon Jul 13 08:35:46 1992 Received: from bunyip.cc.uq.oz.au by optima.cs.arizona.edu (5.65c/15) via SMTP id AA29112; Sun, 12 Jul 1992 20:38:38 -0700 Received: from cc.uq.oz.au by bunyip.cc.uq.oz.au id <13373-0@bunyip.cc.uq.oz.au>; Mon, 13 Jul 1992 13:37:49 +0000 Received: by citecuc (5.61/4.7) id AA28524; Mon, 13 Jul 92 13:35:47 +1000 From: Devetir Unix section Message-Id: <9207130335.AA28524@citecuc> Subject: My name in AUTHORS.... To: info-sr@cs.arizona.edu Date: Mon, 13 Jul 92 13:35:46 EST X-Mailer: ELM [version 2.3 PL11] Sender: sgccdux@citecuc.citec.oz.au It was with some amusement that I noticed my name has been not correctly entered in the AUTHORS file in the preliminary release of SRv2. It is actually Stephen Hocking, not STephen Shocking. Ican iunderstand the confusion, as my login was shocking. This name was chosen because when written as S.Hocking, most people realise what happens. Rather than hide this, I decided to flaunt it so I wouldn't be plagued by millions of inane comments from people who had just realised how the 2 go together. At least I'm not as bad off as a Steven Wheatley I knew.... Cheers, Stephen From gmt Mon Jul 13 01:36:06 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA24565; Mon, 13 Jul 1992 08:36:06 -0700 Date: Mon, 13 Jul 1992 08:36:06 -0700 From: "Gregg Townsend" Message-Id: <199207131536.AA04073@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 13 Jul 1992 08:36:06 -0700 To: info-sr@cs.arizona.edu, sgccdux@citecuc.citec.oz.au Subject: Re: My name in AUTHORS.... Stephen -- My sincere apologies for entering your name incorrectly. I've already corrected it so that it will be right in the next release. If anyone else notices that their name has been inadvertently misspelled or omitted I hope that they will also let us know. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From gmt Fri Aug 28 09:23:29 1992 Date: Fri, 28 Aug 1992 09:23:29 MST From: "Gregg Townsend" Message-Id: <199208281623.AA05128@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA05128; Fri, 28 Aug 1992 09:23:29 MST To: info-sr Subject: Announcing Version 2.0 of SR SR (Synchronizing Resources) is a language for writing concurrent programs. The main language constructs are resources and operations. Resources encapsulate processes and variables they share; operations provide the primary mechanism for process interaction. SR provides a novel integration of the mechanisms for invoking and servicing operations. Consequently, all of local and remote procedure call, rendezvous, message passing, dynamic process creation, multicast, and semaphores are supported. An overview of version 1 of the language and implementation appeared in the January, 1988, issue of TOPLAS (ACM Trans. on Prog. Languages and Systems 10, 1, 51-86). Version 2.0 of SR is now available from The University of Arizona by anonymous FTP or by mail. New features include shared global variables and operations, circular imports, real numbers and math functions, formatted I/O, a more general syntax with fewer special cases, a more robust system with better error checking, true multiprocessing when run on a Sequent Symmetry or Silicon Graphics Iris, distributed termination detection, and many additional enhancements. Version 2.0 is significantly improved over the preliminary version, 2.A, that was released in March. Version 2 is described in detail in the just-published book Gregory R. Andrews and Ronald A. Olsson The SR Programming Language: Concurrency in Practice Benjamin/Cummings Publishing Company, 1993 ISBN 0-8053-0088-0 It is tested on Sun4, Sun3, DECstation, SGI Iris, HP RISC and 9000/300, NeXT, and Sequent Symmetry platforms. Code is also included for the DG AViiON, IBM RS/6000, DEC VAX, Encore Multimax, Apollo DN, and others. SR has been used at a number of universities and labs for course work and research projects involving concurrent programming. It has been used in concurrent programming courses to reinforce concepts with small programming projects and with larger projects such as experiments with parallel algorithms, replicated databases, distributed simulations, and parts of distributed operating systems such as file systems and command interpreters. SR has also been used as a tool in several masters theses and doctoral dissertations to conduct experiments in parallel and distributed programming and to implement larger systems such as a system for mixed language programming, one for distributed implementation of graph algorithms, experiments with load balancing algorithms, and experiments with upcall program structures. SR is available by anonymous FTP from cs.arizona.edu. There are two compressed tar files; be sure to transfer them in binary (image) mode. The files are: /sr/sr.tar.Z: The SR programming language, including source code, documentation in PostScript and troff form, checkout programs, and examples. /sr/vs.tar.Z: The extended verification suite, needed only if you're going to modify the system or port it to a new architecture. Electronic mail interfaces to FTP are available at BITFTP@PUCC.BITNET (for BITNET members) or ftpmail@decwrl.dec.com (for anyone). For details, send either server a message with ``help'' in the body. If you pick up SR by FTP, please send mail to sr-project@cs.arizona.edu to let us know. We'll also put you on the INFO-SR mailing list (see below) if you so request. SR is also available by mail on tape, Sun cartridge, or two 1.44 MB diskettes. For details and an order blank, contact the SR project at the email address above, or call (602) 621-8448, or send a FAX to (602) 621-4246, or write to: SR Project Department of Computer Science University of Arizona Tucson, AZ 85721 An electronic mailing list is in place for discussing SR topics. You can join by sending your email address to info-sr-request@cs.arizona.edu or uunet!arizona!sr-project. From dkl Tue Sep 29 06:58:33 1992 From: "David K. Lowenthal" Message-Id: <199209291358.AA23515@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA23515; Tue, 29 Sep 1992 06:58:33 MST Subject: Machine request To: info-sr@cs.arizona.edu Date: Tue, 29 Sep 92 6:58:33 MST X-Mailer: ELM [version 2.3 PL11] We have developed a series of tests to discern the important differences between 8 different thread management schemes. These tests have been developed on an SGI Iris with 4 processors. Because of the difficultly in drawing conclusions from so few data points, we would like to request the use of an Iris with more processors. Our tests take approx 4 hrs to run, and could be done in multi, or single user mode. Thank you, Greg Andrews David Lowenthal Dawson Engler From timbomb@cs.uq.oz.au Thu Oct 8 14:43:46 1992 Received: from uqcspe.cs.uq.oz.au ([130.102.192.8]) by optima.cs.arizona.edu (5.65c/15) via SMTP id AA10159; Wed, 7 Oct 1992 21:43:14 MST Received: from weevil.cs.uq.oz.au by uqcspe.cs.uq.oz.au id ; Thu, 8 Oct 92 14:43:10 +1000 Message-Id: <9210080443.AA06080@uqcspe.cs.uq.oz.au> To: info-sr@cs.arizona.edu Subject: Possibly dumb crash question... Date: Thu, 08 Oct 92 14:43:46 +1000 From: Tim Mansfield The SR that follows is two resources called eftpos2 and main. Main is just there to call initiate() on eftpos2 to test the resource. The problem is that the resource crashes with a Memory Fault at the last line in bank() ("send pget(5)"). The code makes sense to me. Does anyone have any ideas why it should crash? We're running SRv2. tim ------- resource eftpos2 op initiate() optype get(i: int) optype put(i: int; pget: cap get) op pos(cput: cap put) returns q: cap get op bank() returns p: cap put body eftpos2() proc initiate() var pc: cap get var bc: cap put bc:= bank() pc:= pos(bc) end proc bank() returns p op bankput: put var pget: cap get p:= bankput reply in bankput(banktest, pget) -> write("banktest", banktest) ni send pget(5) # memory fault here end proc pos(bankput) returns q op posget: get q:= posget reply send bankput(5, posget) in posget(postest) -> write("postest", postest) ni end end eftpos2 resource main import eftpos2 body main() process maintest var ec: cap eftpos2 var key: int write("type a number to continue....") read(key) ec := create eftpos2() ec.initiate() end end main From olsson@cs.ucdavis.edu Thu Oct 8 00:01:38 1992 Received: from ivy.cs.ucdavis.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA16078; Thu, 8 Oct 1992 00:01:58 MST Received: by ivy.cs.ucdavis.edu (5.57/UCD.CS.2.0) id AA22242; Thu, 8 Oct 92 00:01:38 -0700 Date: Thu, 8 Oct 92 00:01:38 -0700 From: olsson@cs.ucdavis.edu (Ron Olsson) Message-Id: <9210080701.AA22242@ivy.cs.ucdavis.edu> To: timbomb@cs.uq.oz.au Cc: info-sr@cs.arizona.edu In-Reply-To: Tim Mansfield's message of Thu, 08 Oct 92 14:43:46 +1000 <9210080443.AA06080@uqcspe.cs.uq.oz.au> Subject: Possibly dumb crash question... The problem is in the code proc bank() returns p op bankput: put var pget: cap get p:= bankput reply in bankput(banktest, pget) -> write("banktest", banktest) ni send pget(5) # memory fault here end The input statement's two parameters -- banktest and pget -- have values from the invocation of bankput; their scope is the input statement; they disappear at the ni. The value of variable pget (different from parameter pget) is unchanged by the input statement. Since variable pget was never initialized, its value is unknown, so the send invocation is erroneous. By chance, the particular (garbage) value of pget is causing the problem you saw. (More typically, it would cause a "null invocation" error.) You probably meant to code the above as proc bank() returns p op bankput: put #### no longer needed: var pget: cap get p:= bankput reply in bankput(banktest, pget) -> write("banktest", banktest) send pget(5) ni end or as proc bank() returns p op bankput: put var pget: cap get var banktest: int #### new decl p:= bankput reply receive bankput(banktest, pget) write("banktest", banktest) send pget(5) end From steve@dcs.ex.ac.uk Mon Oct 12 09:42:37 1992 Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (5.65c/15) via SMTP id AA09587; Mon, 12 Oct 1992 09:42:37 MST Via: uk.ac.exeter.dcs; Mon, 12 Oct 1992 17:42:12 +0100 Received: from mira by izar.dcs.exeter.ac.uk; Mon, 12 Oct 92 17:42:00 +0100 From: Stephen Turner Date: Mon, 12 Oct 92 17:41:56 BST Message-Id: <9524.9210121641@mira.dcs.exeter.ac.uk> To: info-sr@cs.arizona.edu Subject: sr-mode for emacs Has anyone produced a new version of the sr-mode for GNU emacs? The current version assumes SR 1.1 and doesn't recognise keywords such as procedure. (It is not too difficult to alter, but I thought someone else may already have done this). Steve Turner ------------------------------------------------------------------------------- Email: steve@dcs.exeter.ac.uk | Department of Computer Science Fax: +44 392 264067 | University of Exeter Tel: +44 392 264048 | Prince of Wales Road Telex: 42894 EXUNIV G | Exeter EX4 4PT England ------------------------------------------------------------------------------- From davidm Sat Oct 17 15:09:46 1992 Received: from antigua.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA21086; Sat, 17 Oct 1992 15:09:47 MST Date: Sat, 17 Oct 1992 15:09:46 MST From: "David Mosberger" Message-Id: <199210172209.AA02018@antigua.cs.arizona.edu> Received: by antigua.cs.arizona.edu; Sat, 17 Oct 1992 15:09:46 MST To: info-sr Subject: announcing srlatex -------------------------------------- Announcing the Availability of srlatex -------------------------------------- The program "srlatex" is an enhanced version of "srtex" distributed with the SR source suite. It typesets an SR program such that it can be included into a LaTeX document. Typesetting aspects are defined via a style file called "srlatex." For example, the fonts for the various classes of strings (keywords, identifiers, comments, strings) are all defined in the style file. This allows a user to redefine fonts as desired. Style files for both the old and the new font selection scheme of LaTeX are provided. If the program is invoked under the name "pllatex" it can be used to typeset programs in "Programming Logic" (see Greg Andrews, "Concurrent Programming: Principles and Practice", Benjamin/Cummings, 1991). In essence, pllatex recognizes more keywords and the sequence "##" can be used to pass "string" to LaTeX literally. For more information, refer to the man page appended to this announcement. The compressed tar file containing the source and supporting files is available via ftp as cs.arizona.edu:/sr/srlatex.tar.Z. Electronic mail interfaces to ftp are available at BITFTP@PUCC.BITNET (for BITNET members) or ftpmail@decwrl.dec.com (for anyone). For details, send either server a message with ``help'' in the body. Please note that this is an alpha release. I welcome all bug reports (or better yet: bug fixes) or suggestions for improvements and I'll will try incorporate them as time permits. --david -- David Mosberger; Department of CS; The University of Arizona; Tucson, AZ 85721 Internet: davidm@cs.arizona.edu UUCP: uunet!arizona!davidm <--srlatex.1--><--srlatex.1--><--srlatex.1--><--srlatex.1--><--srlatex.1--> NAME srlatex - format SR program for LaTeX pllatex - format PL program for LaTeX SYNOPSIS srlatex [ -efps ] [ -a n ] [ -t n ] [ file ... ] DESCRIPTION The command srlatex formats an SR program for use with latex(1). To include an SR program formatted with srlatex, use document-style option srlatex and include the file with the output generated by srlatex with an \input{ filename } command. The document style option defines various parame- ters concerning the typesetting aspects. For example, fonts for keywords, identifiers, literal strings, and comments are defined there. Input is read from the named files, or from standard input if none are given. Output is written to standard output. Srlatex tries hard to keep indentation and alignment the same as the original program. Horizontal positioning is recalculated (to preserve vertical columns) after reading a tab character or three consecutive spaces. The average character width used to calculate columns is fixed (as defined by \srTeXcw in the style file). If text exceeds this average length, a warning will be printed and the text will be typeset in its natural width. The following options are accepted: -e Enable escape sequence. Text between the delimiters #< and ># is passed to the typesetting program directly. The delimiters themselves are not printed. This allows to include arbitrary LaTeX commands in a program. Note that the SR compiler will regard the whole line as a comment. This option is set by default if the program name is pllatex. -p Produce a wrapper allowing output to be fed directly into LaTeX. By default, srlatex produces output to be included in a larger document. -s The program is plain SR as opposed to PL (programming logic). The only differences are that PL has the addi- tional keywords await, barrier, chan, cond, empty, min- rank, monitor, region, signal, signal_all, wait, when. This option is set by default if the program name is srlatex. -t n Set tab stops every n columns. The default is every eight columns. University of Arizona Last change: 24 September 1992 1 -a n Set the number of spaces that will force column align- ment. The default is three. A large value inhibits alignment and usually looks ugly. SEE ALSO sr(1), latex(1), srgrind(1) DIAGNOSTICS Error messages are intended to be self-explanatory. CAVEATS Erroneous programs may exhibit strange spacing and/or pagi- nation. Extremely long program tokens will overflow lex buffers and cause core dumps. It is possible to overflow TeX buffers. University of Arizona Last change: 24 September 1992 2 <--srlatex.1--><--srlatex.1--><--srlatex.1--><--srlatex.1--><--srlatex.1--> From azhao Mon Oct 19 16:17:26 1992 From: "Qiang Alex Zhao" Message-Id: <199210192317.AA14858@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA14858; Mon, 19 Oct 1992 16:17:28 MST Subject: Announcing SRWin - Simple Graphics/Windows Package for SR To: info-sr Date: Mon, 19 Oct 92 16:17:26 MST Cc: azhao (Qiang Alex Zhao) X-Mailer: ELM [version 2.3 PL11] SRWin - Simple Graphics/Windows Package for SR ============================================== INTRODUCTION SRWin is a simple supporting tool for the SR (Synchronizing Resources) programming language. It combines the graphics/windows features of the underlying X Window System, with concurrent programming features of SR. Application programs use SRWin send requests to the X server; user inputs are dispatched to the application program by SRWin; window contents redrawing is handled automatically by the package. Refer to the manpage of srwin(3) included in this distribution for details. SRWin has been test on Sun4 (SunOS 4.1.1), SGI Iris (IRIX 4.0.1), Sequent Symmetry (DYNIX 3.2.0). BUILDING SRWIN You must have SR and X Window System installed first in order to use SRWin. Note SRWin only uses Xlib part of the X Window System. Unpack the distribution in the directory where you want SRWin to reside. Then follow the instructions stated in the README file. MISC SRWin is available by anonymous FTP from cs.arizona.edu: /sr/srwin.tar.Z The SRWin package, including source code, documentation (manual pages) and examples. The SR programming language V2.0 implementation can be found at the same location. Questions, bug reports, and comments should be addressed to: azhao@cs.arizona.edu or Qiang A. Zhao Department of Computer Science University of Arizona Tucson, AZ 85721 From eric@cs.sfu.ca Thu Nov 19 14:27:36 1992 Received: from aquarius.cs.sfu.ca by optima.cs.arizona.edu (5.65c/15) via SMTP id AA17906; Thu, 19 Nov 1992 15:29:07 MST Received: by aquarius.cs.sfu.ca id AA27946 (5.65c/IDA-1.4.4 for info-sr@cs.arizona.edu); Thu, 19 Nov 1992 14:27:36 -0800 Date: Thu, 19 Nov 1992 14:27:36 -0800 From: Eric Kolotyluk Message-Id: <199211192227.AA27946@aquarius.cs.sfu.ca> To: info-sr@cs.arizona.edu Subject: Priorities in SR I'm working on an SR program to simulate the interaction of a disk, disk controller, and computer system. I started off using the Discrete Event Simulation example program in Chapter 18 od the SR Programming Language book. I wasn't very happy with the implementation of the Scheduler because of having to keep track of active processes, etc. When I realized that the sole point of keeping track of active processes was to lock-out the Scheduler while other tasks were still ready to run, I felt the same effect could be achieved by simply running the Scheduler at a lower process priority than every other process in the program. I reworked my program to explicitly set the scheduler's priority lower than everything else, but it has only partially the desired effect. In particular I think I'm seeing a situation where the scheduler is still running when other processes of higher priority are definitely `ready'. Could someone please tell me if this a `bug' in SR's dispatching mechanisms or a misunderstanding on how I read the description in the book. What follows is a copy of the program and some sample output. The point where I think something is wrong is right after the main resource starts up a couple of tasks. Each task calls scheduler.delay and the delay proc registers both of these. At this point control should transfer back to the main resource so it can call delay, but in fact the event_manager in the scheduler imediately processes its event list... This should not happen if the scheduler is `really' running at a lower priority than the main process. A further troubling point in the example output below suggests that the task with the largest delay gets the first go_ahead??? ./disk main: my priority = 1 event_manager: my priority = 0 controller: my priority = 1 main: creating tasks... task: my priority = 1 scheduler: delay = 0.00000 9524.97 9524.97 Task 1 created. task: my priority = 1 scheduler: delay = 0.00000 3077.64 3077.64 event_manager: go ahead 9524.97 event_manager: go ahead 3077.64 Task 2 created. scheduler: delay = 3077.64 1.00000e+08 1.00003e+08 event_manager: go ahead 1.00003e+08 disk seek to cylinder 564 scheduler: delay = 1.00003e+08 1575.00 1.00005e+08 main: shutting down event_manager: go ahead 1.00005e+08 disk seek to cylinder 1092 scheduler: delay = 1.00005e+08 1645.21 1.00006e+08 scheduler: delay = 1.00005e+08 9938.55 1.00015e+08 event_manager: go ahead 1.00006e+08 event_manager: go ahead 1.00015e+08 Controller: disk_manager shutting down scheduler: delay = 1.00015e+08 31.9262 1.00015e+08 event_manager: go ahead 1.00015e+08 Scheduler: event_manager shutting down RTS warning: blocked process: Task.task RTS warning: blocked process: Task.task ######################################################################### # # # Disk Simulation Program # # # ######################################################################### global System import Scheduler, Controller const tasks := 2 var scheduler: cap Scheduler var controller1: cap Controller var active_tasks: int := tasks end System ######################################################################### # # # Scheduler resource # # # ######################################################################### resource Scheduler op time() returns t: real op delay(t: real) op shutdown() import System body Scheduler() op event_list(go_ahead: cap(); t: real) var clock := 0.0 # the simulation clock process event_manager var priority: int setpriority(-1) priority := mypriority() write("event_manager: my priority =", priority) do true -> in time() returns t -> t := clock [] event_list(go_ahead,t) by t -> clock := t write("event_manager: go ahead", t) send go_ahead() setpriority(-1) [] shutdown() -> exit ni od write("Scheduler: event_manager shutting down") end event_manager # provide a simple call interface for processors proc delay(t) write("scheduler: delay =", clock, t, clock+t) op go_ahead() send event_list(go_ahead, t+clock) receive go_ahead() end end Scheduler ######################################################################### # # # Disk resource # # # ######################################################################### # # The Disk resource simulates a raw disk drive in terms of seek time and # rotational latency. resource Disk op seek(cyl: int), read(sec: int) import System body Disk( cylinders: int; tracks: int; sectors: int; bytes: int; rpm: real; seekMin: real; seekAvg: real; seekMax: real) var cylinder: int := 0 /* Current cylinder position (0 = outermost) */ var theta: real := 0.0 /* Current Angle of the disk platters */ var velocity: real := cylinders / (seekMax - seekMin) proc seek(cyl) var distance: int := abs(cylinder - cyl) write("disk seek to cylinder", cyl) scheduler.delay( distance * velocity + seekMin ) end seek proc read(sec) end read end Disk ######################################################################### # # # Controller resource # # # ######################################################################### resource Controller op blocks() returns highest_block: int op block_request(block: int) op shutdown() import System, Disk body Controller() var disk: cap Disk disk := create Disk(2460, 15, 66, 512, 5400, 1500, 10000, 20000) proc blocks() returns highest_block highest_block := 2460 * 15 * 66 - 1 end blocks process disk_manager var priority: int priority := mypriority() write("controller: my priority =", priority) do true -> in block_request(block) -> disk.seek(block / 15 / 66) [] shutdown() -> exit ni od write("Controller: disk_manager shutting down") end disk_manager end Controller ######################################################################### # # # Task resource # # # ######################################################################### resource Task import System, Controller body Task(accesses: int) var cblocks: int := controller1.blocks() process task var priority: int priority := mypriority() write("task: my priority =", priority) fa f := 1 to accesses -> scheduler.delay(random(10000.0)) controller1.block_request(int(random(cblocks))) af --active_tasks end task end Task ######################################################################### # # # main resource # # # ######################################################################### resource main() import System, Scheduler, Controller, Task const stime: int := 100000000 # Simulation Time, 100 Seconds var task[tasks]: cap Task var i: int var priority: int priority := mypriority() write("main: my priority =", priority) scheduler := create Scheduler() controller1 := create Controller() write("main: creating tasks...") fa i := 1 to tasks -> task[i] := create Task(10) write("Task", i, "created.") af scheduler.delay(stime) write("main: shutting down") controller1.shutdown() scheduler.shutdown() end main From azhao Thu Nov 19 21:52:27 1992 From: "Qiang Alex Zhao" Message-Id: <199211200452.AA08021@optima.cs.arizona.edu> Received: by optima.cs.arizona.edu (5.65c/15) id AA08021; Thu, 19 Nov 1992 21:52:28 MST Subject: Anybody using SRWin? To: info-sr Date: Thu, 19 Nov 1992 21:52:27 -0700 (MST) X-Mailer: ELM [version 2.4 PL6] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 517 Hi there, I'm curious about how many people are using SRWin... Any comments, suggestions? What do you think of some nice things which should be included in SRWin? Thanks in advance and have a nice weekend/holiday/vacation/etc... ;o) = Qiang Alex Zhao ___ . ______ Computer Science Dept / ) /| ) __// ) University of Arizona / / /_| / _ // /_ _. ._ azhao@cs.arizona.edu (__)(_o / (_(_(-'_)( ((____/ (_(_(_(_) From gmt Fri Nov 20 14:24:34 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA06698; Fri, 20 Nov 1992 14:24:41 MST Date: Fri, 20 Nov 1992 14:24:34 MST From: "Gregg Townsend" Message-Id: <199211202124.AA02478@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Fri, 20 Nov 1992 14:24:34 MST To: eric@cs.sfu.ca Subject: Re: Priorities in SR Cc: info-sr There was a problem in the scheduler when awakening blocked processes. It is fixed by adding a few lines of code to rts/process.c (see below). There is another unresolved problem when processes of different priorities are blocked simultaneously waiting for input from the same operation class, for example when using an array of semaphores or ops. I don't think this problem affects your program. We're not aware of any problems involving the "by" clause of an input statement, but if you have a small example that shows an error we'll be glad to look at it. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m ------------------------------------------------------------------------------ *** /usr/sr/v2/rts/process.c Wed Aug 19 20:19:46 1992 --- /usr/gmt/v2/rts/process.c Fri Nov 20 10:48:33 1992 *************** *** 457,462 **** --- 457,467 ---- Procq *pl; Proc pr; { + if (pl == &sr_ready_list) { + sr_add_readyq (pr); + return; + } + LOCK_QUEUE ("sr_enqueue"); if ((pl == NULL) || (pr == NULL)) From gmt Mon Nov 30 10:51:47 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA22627; Mon, 30 Nov 1992 10:51:49 MST Date: Mon, 30 Nov 1992 10:51:47 MST From: "Gregg Townsend" Message-Id: <199211301751.AA09736@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 30 Nov 1992 10:51:47 MST To: J.Crowcroft@cs.ucl.ac.uk, info-sr, rossi@dm.unibo.it, wade@cs.utk.edu Subject: SR v2 on IBM RS6000? Has anyone succeeded in installing Version 2 of SR on an IBM RS/6000? We've received a few queries and problem reports, but nobody's reported success or sent back the necessary modifications. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From J.Crowcroft@cs.ucl.ac.uk Tue Dec 1 08:39:51 1992 Message-Id: <199212010840.AA13088@optima.cs.arizona.edu> Received: from bells.cs.ucl.ac.uk by optima.cs.arizona.edu (5.65c/15) via SMTP id AA13088; Tue, 1 Dec 1992 01:40:07 MST Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 1 Dec 1992 08:39:58 +0000 To: Gregg Townsend Cc: J.Crowcroft@cs.ucl.ac.uk, info-sr@cs.arizona.edu, rossi@it.unibo.dm, wade@cs.utk.edu Subject: Re: SR v2 on IBM RS6000? In-Reply-To: Your message of "Mon, 30 Nov 92 10:51:47 MST." <199211301751.AA09736@owl.cs.arizona.edu> Date: Tue, 01 Dec 92 08:39:51 +0000 From: Jon Crowcroft >Has anyone succeeded in installing Version 2 of SR on an IBM RS/6000? We've >received a few queries and problem reports, but nobody's reported success Gregg, please feel free to point people at me - it is possible that people are running more recent versions of AIX than we are...though i'm not sure why this would pose problems, I am happy to investiage jon From jmwagner@ucdavis.edu Wed Dec 2 12:57:25 1992 Received: from ucdavis.ucdavis.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA08872; Wed, 2 Dec 1992 13:59:45 MST Received: from ike.ucdavis.edu by ucdavis.ucdavis.edu (5.61/UCD2.04) id AA08519; Wed, 2 Dec 92 12:49:33 -0800 Received: by ike.ucdavis.edu (4.1/UCD2.02) id AA18015; Wed, 2 Dec 92 12:57:25 PST Date: Wed, 2 Dec 1992 12:57:25 -0800 (PST) From: John Michael Wagner Subject: R4000 Indigo implementation To: info-sr@cs.arizona.edu Message-Id: Does anyone know if version 2.0 of SR will run on the (new) R4000-based SGI Iris Indigo? If not, is anyone working on porting it? I haven't tried to install it, I am asking before committing a chunk of time... John Wagner Institute of Theoretical Dynamics University of California, Davis Disclaimer: NOBODY at UCD agrees with ANYTHING I say... +------------------------------------+------------------------------+ | jmwagner@ucdavis.edu | Wake me up early, be good to | | jmwagner@ucdavis | my dogs, and teach my child- | | {ucbvax, lll-crg}!ucdavis!jmwagner | ren to pray. John Anderson | +------------------------------------+------------------------------+ From gmt Wed Dec 2 16:44:16 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA17957; Wed, 2 Dec 1992 16:44:17 MST Date: Wed, 2 Dec 1992 16:44:16 MST From: "Gregg Townsend" Message-Id: <199212022344.AA13549@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Wed, 2 Dec 1992 16:44:16 MST To: info-sr@cs.arizona.edu, jmwagner@ucdavis.edu Subject: Re: R4000 Indigo implementation I can't say for sure, but I wouldn't anticipate any special problems. The odds are good enough to make it worth at least starting it up and seeing how far it gets. The biggest risk may be in the operating system; you're probably running something newer than the Irix 4.0.1 we tested it with, and new versions sometimes introduce minor incompatibilities. If you do try it, please let us know how it goes. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From cook@bebop.esd.sgi.com Wed Dec 2 19:40:00 1992 Received: from sgi.sgi.com (SGI.COM) by optima.cs.arizona.edu (5.65c/15) via SMTP id AA01661; Wed, 2 Dec 1992 20:40:09 MST Received: from relay.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for info-sr@cs.arizona.edu id AA10363; Wed, 2 Dec 92 19:40:04 -0800 Received: from bebop.esd.sgi.com by relay.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgi.sgi.com:info-sr@cs.arizona.edu id AA14373; Wed, 2 Dec 92 19:40:03 -0800 Received: by bebop.esd.sgi.com (920330.SGI/920502.SGI.AUTO) for @sgi.sgi.com:info-sr@cs.arizona.edu id AA16122; Wed, 2 Dec 92 19:40:00 -0800 Date: Wed, 2 Dec 92 19:40:00 -0800 From: cook@bebop.esd.sgi.com (Doug Cook) Message-Id: <9212030340.AA16122@bebop.esd.sgi.com> To: info-sr@cs.arizona.edu Subject: Re: R4000 Indigo implementation > The biggest risk may be in the operating system; you're probably running > something newer than the Irix 4.0.1 we tested it with, and new versions > sometimes introduce minor incompatibilities. You're probably running Irix 4.0.5F; there shouldn't be any major differences (except perhaps fewer bugs) between this and 4.0.1. -Doug Doug Cook (cook@sgi.com) | Software Engineer, ISD Digital Media | "Exuberance is Beauty." Silicon Graphics, Inc. | -Wm. Blake From steve@dcs.ex.ac.uk Thu Dec 3 09:54:45 1992 Received: from sun2.nsfnet-relay.ac.uk by optima.cs.arizona.edu (5.65c/15) via SMTP id AA20625; Thu, 3 Dec 1992 02:55:21 MST Via: uk.ac.exeter.dcs; Thu, 3 Dec 1992 09:55:01 +0000 Received: from sirius by izar.dcs.exeter.ac.uk; Thu, 3 Dec 92 09:54:47 GMT From: Stephen Turner Date: Thu, 3 Dec 92 09:54:45 GMT Message-Id: <16057.9212030954@sirius.dcs.exeter.ac.uk> To: jmwagner@ucdavis.edu Cc: info-sr@cs.arizona.edu In-Reply-To: John Michael Wagner's message of Wed, 2 Dec 1992 12:57:25 -0800 (PST) Subject: R4000 Indigo implementation We are running version 2.0 of SR quite happily on an R4000 SGI under Irix 4.0.5E operating system. We had no problems in installing it using the usual Configuration file, etc for SGI machines. Steve ------------------------------------------------------------------------------- Parallel Systems Research Group | Stephen Turner Email: steve@dcs.exeter.ac.uk | Department of Computer Science Fax: +44 392 264067 | University of Exeter Tel: +44 392 264048 | Prince of Wales Road Telex: 42894 EXUNIV G | Exeter EX4 4PT England ------------------------------------------------------------------------------- From Chalmers@europarc.xerox.com Fri Dec 4 10:35:28 1992 Received: from alpha.Xerox.COM by optima.cs.arizona.edu (5.65c/15) via SMTP id AA11036; Fri, 4 Dec 1992 11:37:18 MST Received: from gonzo.EuroPARC.Xerox.COM ([13.1.252.121]) by alpha.xerox.com with SMTP id <11639>; Fri, 4 Dec 1992 10:37:00 PST Received: by gonzo.EuroPARC.Xerox.COM with SMTP (5.65c/IDA-1.2.9) id AA00351; Fri, 4 Dec 1992 18:35:30 GMT Message-Id: <199212041835.AA00351@gonzo.EuroPARC.Xerox.COM> To: info-sr@cs.arizona.edu Subject: Heterogeneity and SR Date: Fri, 4 Dec 1992 10:35:28 PST From: Chalmers@europarc.xerox.com Hello - I was looking through the SR book and (at first glance) came across no discussion of heterogeneous networks, and whether having a variety of machines (with different byte orders &c) was within the scope of SR. Does SR do XDR-like marshalling of data when sending data between machines? Thanks for any help, --Matthew Matthew Chalmers Xerox EuroPARC, 61 Regent St., Cambridge, CB2 1AB, United Kingdom Tel. [44] 223 341546 Fax [44] 223 341510 From gmt Fri Dec 4 12:55:15 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA17340; Fri, 4 Dec 1992 12:55:16 MST Date: Fri, 4 Dec 1992 12:55:15 MST From: "Gregg Townsend" Message-Id: <199212041955.AA16187@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Fri, 4 Dec 1992 12:55:15 MST To: Chalmers@europarc.xerox.com, info-sr@cs.arizona.edu Subject: Re: Heterogeneity and SR No, the current implementation of SR provides no support for mixing architectures. It would take just what you suggest, and that simply isn't done now. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m From isc40002@ccpx11.nus.sg Sat Dec 19 11:57:57 1992 Received: from nuscc.nus.sg by optima.cs.arizona.edu (5.65c/15) via SMTP id AA06500; Fri, 18 Dec 1992 20:58:28 MST Received: from [137.132.10.55] by nuscc.nus.sg (5.65/1.34) id AA06454; Sat, 19 Dec 92 11:57:59 +0800 Received: by ccpx11.nus.sg (5.57/Ultrix3.0-C) id AA19037; Sat, 19 Dec 92 11:57:57 +0800 Date: Sat, 19 Dec 92 11:57:57 +0800 From: isc40002@ccpx11.nus.sg (CHEONG LAI HONG) Message-Id: <9212190357.AA19037@ccpx11.nus.sg> To: info-sr@cs.arizona.edu Hello, I am not familiar in the use of makefile but I guess that it is possible to have makefile for sr. Thus I would like to ask if anybody could send me a copy of a sample makefile for sr. Lai-Hong Cheong isc40002@ccpx11.nus.sg From olsson@cs.ucdavis.edu Fri Dec 18 21:31:58 1992 Received: from ivy.cs.ucdavis.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA08950; Fri, 18 Dec 1992 22:31:48 MST Received: by ivy.cs.ucdavis.edu (5.57/UCD.CS.2.0) id AA27904; Fri, 18 Dec 92 21:31:58 -0800 Date: Fri, 18 Dec 92 21:31:58 -0800 From: olsson@cs.ucdavis.edu (Ron Olsson) Message-Id: <9212190531.AA27904@ivy.cs.ucdavis.edu> To: isc40002@nusunix1.nus.sg Cc: info-sr@cs.arizona.edu In-Reply-To: CHEONG LAI HONG's message of Sat, 19 Dec 92 11:57:57 +0800 <9212190357.AA19037@ccpx11.nus.sg> Subject: makefiles Date: Sat, 19 Dec 92 11:57:57 +0800 From: isc40002@ccpx11.nus.sg (CHEONG LAI HONG) I am not familiar in the use of makefile but I guess that it is possible to have makefile for sr. Thus I would like to ask if anybody could send me a copy of a sample makefile for sr. The srm tool will generate a makefile for you. E.g., "srm a.sr b.sr" will create a makefile that represents the dependencies found in a.sr and b.sr. For further details, try "man srm". From lamq@a570.usal.es Mon Dec 21 13:24:31 1992 Received: from relay.rediris.es by optima.cs.arizona.edu (5.65c/15) via SMTP id AA27763; Mon, 21 Dec 1992 05:39:52 MST Received: from rediris.es by relay.rediris.es (PMDF #2585 ) id <01GSKUZTE0GG8X0ALC@relay.rediris.es>; Mon, 21 Dec 1992 13:27:50 GMT+1 Date: Mon, 21 Dec 1992 13:24:31 UTC+0200 From: lamq@a570.usal.es Subject: C functions with SR? To: info-sr@cs.arizona.edu Message-Id: <92-12-21-13:24> Content-Identifier: 92-12-21-13:24 Content-Transfer-Encoding: 7BIT X400-Content-Type: P2-1984 (2) X400-Mts-Identifier: [/PRMD=IRIS/ADMD=MENSATEX/C=ES/;SUUSAL CUASUBMM12211324310012] X400-Received: by mta iris-dcp in /PRMD=iris/ADMD=mensatex/C=es/; Relayed; Mon, 21 Dec 1992 13:27:20 UTC+0100 X400-Received: by /PRMD=IRIS/ADMD=MENSATEX/C=ES/; Relayed; Mon, 21 Dec 1992 13:24:31 UTC+0200 X400-Recipients: non-disclosure:; X400-Originator: lamq@a570.usal.es Is it possible starting with a SR source program to generate one C function wich you can call directly from another C program, instead of generating a executable program? Luis Antonio Miguel Quintales Departamento de Fisica Aplicada Universidad de Salamanca e-mail: lamq@a570.usal.es From gmt Mon Dec 21 10:41:03 1992 Received: from owl.cs.arizona.edu by optima.cs.arizona.edu (5.65c/15) via SMTP id AA11291; Mon, 21 Dec 1992 10:41:04 MST Date: Mon, 21 Dec 1992 10:41:03 MST From: "Gregg Townsend" Message-Id: <199212211741.AA08170@owl.cs.arizona.edu> Received: by owl.cs.arizona.edu; Mon, 21 Dec 1992 10:41:03 MST To: lamq@a570.usal.es Subject: Re: C functions with SR? Cc: info-sr Date: Mon, 21 Dec 1992 13:24:31 UTC+0200 From: lamq@a570.usal.es Is it possible starting with a SR source program to generate one C function wich you can call directly from another C program, instead of generating a executable program? No. SR programs assume they're running in a specialized environment established and maintained by the SR runtime system. Although it's possible to execute most C functions in this environment, it's not possible to remove SR procs and execute them in a plain C environment. Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721 +1 602 621 4325 gmt@cs.arizona.edu 110 57 16 W / 32 13 45 N / +758m