mp1u+@andrew.cmu.edu (Michael Portuesi) (04/18/88)
Excerpts from: 16-Apr-88 Re: REZ questions. Kim DeVaughn@amdahl.uts. (2471) > Hmmmmm ... I've been using REZ for awhile, but haven't noticed this since > the commands that I tell REZ to rez are sitting in vd0: (REZ is still > "on trial" with me, so I haven't changed my environment around to take > full advantage of it yet). If you are going to keep the commands in vd0: why bother having REZ around in the first place? I realize you are merely evaulating REZ, but it seems pointless to have two copies of a program around in memory so that you can only execute one of them. If that were the solution I were looking for, I would simply copy a batch of commands to ram:c and say "path add ram:c". > When you issue the command "rez foo" (or "rez -a foo"), REZ only adds the > There is another command-line option for REZ ... -l, as I recall ... that > causes the command(s) to also be loaded *now*. (I haven't used -l yet, but > I think that's correct.) So try something like "rez -l glop1 glop2 ...", > and see if that doesn't takes care of things. If not, then I must not > understand your problem. Using -l was the very first thing I tried. Remember, my goal is to not require the Workbench disk in my only disk drive during normal use. > BTW, you really ought to blow-off all that BCPL junk, and start using > the ARP equivalents. Backwardly compatible, smaller, faster, and also > provide additional functionality! If REZ had worked the way I had expected it to, I would be more than happy to blow off the BCPL junk and go with ARP. But right now the 1.2 Gamma Resident is the only thing that does what I want, and it only works reliably with BCPL programs. Are there any other suggestions? Does anybody know about the other "resident" options (especially the one that's supposed to come with 1.3)? --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (04/18/88)
In article <8WOJNQy00VQFQHaEU7@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > If you are going to keep the commands in vd0: why bother having REZ around in > the first place? I realize you are merely evaulating REZ, but it seems > pointless to have two copies of a program around in memory so that you can only > execute one of them. If that were the solution I were looking for, I would > simply copy a batch of commands to ram:c and say "path add ram:c". I was simply explaining why I might not have seen the problem you describe. I certainly wasn't suggesting it as a solution. I've no intention of having things I make resident in vd0: as well (eventually), but before I go to the (considerable) trouble of reorganizing my normal environment, I want to be fairly sure that such a major change isn't going to give me a headache later on. > Using -l was the very first thing I tried. Remember, my goal is to not require > the Workbench disk in my only disk drive during normal use. Mine too! I just tried a couple quick experiments ... First, picked a pure and shareable command (ARP's info), and made sure there was no copy anywhere in my path, and took it off the rez list. Tried issuing "info" (just to be sure), and got "command not found", as expected. Put a floppy in df0:, and cd'd to the directory with "info" in it. Did a "rez -l info", and noted that the file seemed to load. Cd'd to my "home" directory in vd0:, removed the floppy, and entered "info". Got the usual "info" output, without any problems. This is what I (and I think, you) expect "rez -l" to do, right? Second, tried something (arc) that was neither pure, nor sharable. Following the same methodology as above, I got a little different results (but no file requesters, or such). Once "arc" had been loaded ("rez -l arc"), I entered the command "arc", to get the arc's familier instructions. If the floppy(s) in the drives were NOT the floppy I loaded arc from (or if the drives were empty), I got the instructions after a short pause (while a working copy was made from the resident area, I presume ... just as if arc had been in vd0: or ram:). If however, the floppy I'd loaded arc from was in either drive (it had previously been removed, so there was nothing in any of Facc's buffers, etc.), the drive was accessed briefly (only a second, or so ... far less time than is needed to load/copy arc), then out came arc's instructions on the screen. Hmmmmm ...? Tried one other thing with arc ... pop'd another CLI window open, and tried issuing "arc" from two CLI's nearly simultaneously (remenber arc is marked not sharable). On one attempt, I got the familier instructions in one CLI, while in the other I got "command not found". On another try, I got the instructions in both CLI's, with the 2nd invocation waiting for the 1st to finish. Sounds like some timing sensitivities in rez's code, but at least both outcomes were benign. In any case, nothing ever put up a requester, etc. Which is not to say you'll have similar results (in fact you're not, since you are getting one). I also tried fooling around with my assigns and path a little, but never could get a request for WB, or any floppy ... One final thought just occurred to me, that I just verified ... if you aren't cd'd to the directory that the commands reside in when you issue the "rez -l" command(s), rez prints a "couldn't find" message, but also puts the command(s) on the rez list (as if you had issued "rez -a ..."). I.e., when "loading", rez doesn't look down your path, but only in the current directory. Then, if your c: dir is still assigned to WB:c, you might well get a requester the 1st time you issue a command. And you don't see the "couldn't find" message, because you redirected them to nil: ... Try cd'ing to where your commands are before issuing your rez command(s), and see if that doesn't fix the problem. (DON'T try something like "rez -l c:foo", as Jim warns against that ... and it doesn't work, anyway). > If REZ had worked the way I had expected it to, I would be more than happy to > blow off the BCPL junk and go with ARP. If you experiment a bit, I think you can get rez to work the way you'd expect it to. BTW, all the ARP stuff I've tried is both pure and sharable. > Are there any other suggestions? Does anybody know about the other "resident" > options (especially the one that's supposed to come with 1.3)? The ARP release (v1.1) has a resident command also. Haven't tried it myself, as I've been told by someone who has tried it, that rez works much better. Then there is Bill Hawes' "resi", which comes with his WShell, but I haven't tried it either. BTW, he's said he'll fix WShell to support whatever resident method becomes most popular. Hope you can find something of value in all of this ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
mp1u+@andrew.cmu.edu (Michael Portuesi) (04/19/88)
kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: > Try cd'ing to where your commands are before issuing your rez > command(s), and see if that doesn't fix the problem. (DON'T try > something like "rez -l c:foo", as Jim warns against that ... and it > doesn't work, anyway). Ah-ha! That's exactly what I was doing! I'll give it another try, and perhaps I'll give the BCPL stuff the heave-ho along with it. Is ARP 1.1 available via FTP from purdue? --M Michael Portuesi / Carnegie Mellon University ARPA/UUCP: mp1u+@andrew.cmu.edu BITNET: rainwalker@drycas "Memories are uncertain friends, when recalled by messages" -- OMD, "Messages"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/19/88)
I don't CD or anything, just: rez run dme (etc....) without any path specs. That's all you need to do. This effectively rez's any executable ending in that filename c:dme, df0:c/dme, ram:dme, etc... it doesn't matter where the actual executable resides. -Matt
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (04/19/88)
In article <8804182037.AA14484@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I don't CD or anything, just: > > rez run dme (etc....) > > without any path specs. That's all you need to do. This > effectively rez's any executable ending in that filename c:dme, df0:c/dme, > ram:dme, etc... it doesn't matter where the actual executable resides. Right. But, Michael was trying to preload the things he wanted resident at startup-sequence time, so he could remove his WB floppy, and not get asked for it again. To do that, you need to use rez's "-l" option, and for that to actually load the programs, you need to be cd'd to the directory they're in. Question for you Matt ... I see "run" in your above example. Do you really make "run" rezident, and if so, have you had any problems? When I've done that, it has interfered with shell's operation (Steve's v2.07m). This behavior was also reported here recently by someone else. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
kim@amdahl.uts.amdahl.com (Kim DeVaughn) (04/19/88)
In article <QWOXlby00VoD4DMo5-@andrew.cmu.edu>, mp1u+@andrew.cmu.edu (Michael Portuesi) writes: > Ah-ha! That's exactly what I was doing! I'll give it another try, > and perhaps I'll give the BCPL stuff the heave-ho along with it. Is > ARP 1.1 available via FTP from purdue? I dunno about FTP ... all the stuff has been at purdue for 6 weeks, or better. In any case, as promised, I will be posting the v1.1 stuff here this week, at a reasonable rate. First posting(s) should be going out tomorrow. /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
fwp@unccvax.UUCP (Rick Pasotto) (04/20/88)
I too am trying to get REZ to work but have encountered a problem. My normal environment is to have lots of stuff in vd0: including the Manx compiler, ie. 'cc', 'as', & 'ln'. My idea is to REZ them and then delete them from vd0:. This works fine for 'cc' and 'ln' EXCEPT that 'cc' cannot now find the assembler. Does PATH need to be set to some special value for 'cc' to find a REZ'ed 'as'? (If 'as' is not deleted from vd0: everything works normally.) Rick Pasotto mcnc!unccvax!fwp
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/88)
:Question for you Matt ... I see "run" in your above example. Do you really :make "run" rezident, and if so, have you had any problems? : :When I've done that, it has interfered with shell's operation (Steve's v2.07m). :This behavior was also reported here recently by someone else. : :/kim I haven't had any problems making RUN resident. I use my version of my shell. (speaking of which, I really ought to do another release of it!). -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (04/20/88)
> I too am trying to get REZ to work but have encountered a problem. >My normal environment is to have lots of stuff in vd0: including the Manx >compiler, ie. 'cc', 'as', & 'ln'. My idea is to REZ them and then delete >them from vd0:. This works fine for 'cc' and 'ln' EXCEPT that 'cc' cannot >now find the assembler. Does PATH need to be set to some special value >for 'cc' to find a REZ'ed 'as'? (If 'as' is not deleted from vd0: everything >works normally.) > >Rick Pasotto >mcnc!unccvax!fwp Remember that REZ intercepts LoadSeg(), so you still must have the executables available in many cases just so programs can get locks on them. That is, in those cases where the application 'searches' the path for the executable, it usually gets a lock on it before LoadSeg()ing it, and doesn't bother to LoadSeg() it if it can't get the lock.... REZ doesn't come in until the application actually LoadSeg()'s it. Also, REZ doesn't work for applications that CurrentDir() INTO the executable then LoadSeg(""). -Matt
morgan@brambo.UUCP (Morgan W. Jones) (04/21/88)
In article <28716@amdahl.uts.amdahl.com> kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes: >First, picked a pure and shareable command (ARP's info), and made sure there >was no copy anywhere in my path, and took it off the rez list. Tried issuing >"info" (just to be sure), and got "command not found", as expected. Put a >floppy in df0:, and cd'd to the directory with "info" in it. Did a "rez -l info", >and noted that the file seemed to load. Cd'd to my "home" directory in vd0:, >removed the floppy, and entered "info". Got the usual "info" output, without >any problems. This is what I (and I think, you) expect "rez -l" to do, right? Actually, the person who said that it requires the disk to be in the drive is correct. Since REZ only replaces the vectors for LoadSeg and UnLoadSeg, it doesn't know that you are trying to load a program until the CLI actually tries to load the file. Thus when you type "info", the CLI checks the path to convert "info" to "C:info" and then does a LoadSeg("C:info"). The reason that you didn't get a file requestor asking you to insert a volume is because the CLI (or whatever) actually caches the path name of the last few commands executed - so it knows the pathname of the command without having to try for a lock (if that's what it does) on "C:info" and "ram:info" etc. to determine which, if any, directory it is in. If you had executed several other commands on a different disk and then tried "info" with the disk removed, you indeed would have seen the requestor asking you to insert the volume that contains C:. After playing around with REZ, I find it a really inspired piece of code, but not quite complete enough to be a useful tool. The two problems that struck me were that REZ didn't use the PATH to determine where commands are (easily fixed), and that the disk containing the command has to be inserted in a drive which makes it next to useless on a floppy based system with a meg or more. I can see two ways to solve this second problem: rez adds ram:rez.stubs to the path, and every time that a command is made resident an empty file is created in rez.stubs under the same name, the file being deleted when the program is made unresident; the better alternative is to add a device REZ:, which is added to the path - whenever it is asked if a file is in it it responds yes if the file is resident and no otherwise - and so whenever a resident command is asked for by the CLI it will actually try to load REZ:command. This second approach also has the advantage of allowing data files to be made resident (particularly useful for libraries like c.lib). And if you get to this point in my message, I appologize for the long paragraphs but I couldn't see a good place to break them, and at 11:54 at night I'm not about to restructure them. >/kim -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."
rap@ardent.UUCP (Rob Peck) (04/21/88)
In article <8804201502.AA07604@cory.Berkeley.EDU>, dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > I too am trying to get REZ to work but have encountered a problem. > >My normal environment is to have lots of stuff in vd0: including the Manx > >compiler, ie. 'cc', 'as', & 'ln'. My idea is to REZ them and then delete > >them from vd0:. > > Remember that REZ intercepts LoadSeg(), so you still must have the > executables available in many cases just so programs can get locks on them. > That is, in those cases where the application 'searches' the path for the > executable, it usually gets a lock on it before LoadSeg()ing it, and doesn't > bother to LoadSeg() it if it can't get the lock.... REZ doesn't come in > until the application actually LoadSeg()'s it. Thanks, Matt, for pointing this out. I would have been tempted to do the same as the original poster. To save space in this case, rather than have the executable around, one might just have a teeny file having the same name as the executable, somewhere in the PATH, just to satisfy the locking requirement. And that file could be nothing more than an assembled/linked version of: DummyFile rts (or am I misinterpreting something?) Anyway, ya saved me a lot of hair pulling -- thanks. Rob Peck ...ihnp4!hplabs!ardent!rap
elbaum@reed.UUCP (Daniel Elbaum) (04/25/88)
In article <397@brambo.UUCP> morgan@brambo.UUCP (Morgan W. Jones) writes: . . . >After playing around with REZ, I find it a really inspired piece of code, >but not quite complete enough to be a useful tool. The two problems >that struck me were that REZ didn't use the PATH to determine where >commands are (easily fixed), and that the disk containing the command >has to be inserted in a drive which makes it next to useless on a ^^^^^^^^^^^^^^^^^^^^ >floppy based system with a meg or more. I can see two ways to solve ... ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ???? I can't really see what you perceive to be the problem. I have a 1MB floppy-based system and rez is perfectly suited to my resources and needs. Once the commonly-used stuff is loaded, I very seldom have to put the workbench disk back in. Daniel Elbaum elbaum@reed.UUCP tektronix!reed!elbaum "My employer is wholly responsible for this and all postings"
morgan@brambo.UUCP (Morgan W. Jones) (04/29/88)
In article <352@ardent.UUCP> rap@ardent.UUCP (Rob Peck) writes: >To save space in this case, rather >than have the executable around, one might just have a teeny file >having the same name as the executable, somewhere in the PATH, just >to satisfy the locking requirement. And that file could be nothing >more than an assembled/linked version of: > >DummyFile > rts > >(or am I misinterpreting something?) You're misinterpreting somthing, but you're on the right track. Since REZ will stop the file from ever being loaded, a zero length file will do the trick. If ram: is in you're path and you've just REZ'd a program called prog, "cat <nil: >ram:prog" works just great. The problem arises in that REZ -r won't clean out this file (a minor point). >Rob Peck ...ihnp4!hplabs!ardent!rap Just making sure: . . . . . -- Morgan Jones - Bramalea Software Inc. morgan@brambo.UUCP ...!{uunet!mnetor!lsuc!ncrcan, utgpu!telly}!brambo!morgan "These might not even be my opinions, let alone anyone else's."