chas@gtss.UUCP (Charles Cleveland) (11/30/88)
I have recently gotten the 1.3 Enhancer. While trying to figure out how
to fit another recent acquistion, Lattice 5.0, onto a reasonable number of
floppys & ram:things (memory is limited, and there ain't no hard drive yet)
in a way that would make it the most convenient to work in the usual cases,
while still handling the more obscure ones on the fly, I had the idea of
trying the recently posted (comp.sys.amiga.binaries/sources) PATH: device, so
that I could split the LIB: directory between reasonably likely libraries (on
RAD:) and the occasionally useful ones (on floppy). Lattice 5.0 libs have now
proliferated (what between 16 int libs and 32 bit ones, and ones that use
registers to pass some arguments and those that don't, etc., all roughly
equivalent and about the same size) to the point that cramming them all into
memory when I only need a few is painful, while I would much prefer for the
system to find the oddball request of mine instead of having to make massive
readustments just because I want to have a quick look a something that requires
special treatment. So I thought PATH: would let me put the more used entries
in RAD: and leave the rarely used ones on floppy and have the best of all
possible worlds.
And perhaps it will.
However, it was natural to first introduce the sort of example in the PATH:
device documentation, such as constructing a command path and then using it
to to find requested commands, instead of just using the PATH command.
:-( Problem the lesser:
Suppose I have created a file in path: called "c" containing the following
lines:
sys:c/
fred:c/
barbarella:c/
and have done something like 'assign c: path:c' or even
'path reset path:c'. Apparently, the PATH: device first checks on the
existence of its entries, one by one, and only then tries to actually find
the file in question. Suppose in my case that there are no drives other
than df0: and df1:, df0: contains sys: and is sancrosanct, and df1:
contains barbarella: at the time I try to execute a command in
barbarella:c. Without using df0:, I am faced with a succession of
requestors, first for fred:c, to make sure it exists, and then for
barbarella: to make sure it exists, and then for fred: again, to try to
find the command in it, and finally for barbarella:, to try (sucessfully
at last), to find the command. It would seem preferable, after first
determining that fred:c exists to then search it for the command, and
only then determine whether barbarella: exists and then search it for
the command (sucessfully, and with only half the swaps). Of course,
the path command checks for existence only on its execution, which is
even better, but a little harder for something like PATH: to handle.
Obviously I think that at a minimum PATH: should change the order of
doing things, and search a member for the target immediately after
having verified its existence, instead of verifying all members existence
before searching any for the target.
:-( Problem the greater:
After putting path:c in my command path (via 'assign c: path:c' or
say 'path reset path:c'), often (perhaps always) when I try to execute
the 1.3 command 'more' (which is pure but which I have not made
resident) I am visited by the GURU, with the accompanying loss of
RAD: on reboot (which lives in C00000 on my machine, give or take a 0).
I would try to determine the precise GURU number now, except for not
being able to complete this message. Multitasking has its limits.
This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider.
ARP is nowhere to be seen (except on other disks where I have seen odd
behavior after trying to bring up the 1.3 shell). ConMan is in use on
all these disks.
So has any one else seen any odd interactions between PATH: and 1.3, at any
level of the gamma releases? (I would like to think that Lattice actually
included the 1.3 release stuff on their disks, since otherwise they included
a lot of 1.3 gamma. I can't say that I've copied over all their l:,
libs:, etc. directories with my 1.3 release, though perhaps I should. Or
perhaps I shouldn't.)
--
- It is better for civilization to be going down the drain than to be -
- coming up it. -- Henry Allen -
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.eduecphssrw@solaria.csun.edu (Stephen Walton) (12/01/88)
In article <284@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: (a great deal of stuff deleted, then Charles asks about the PATH: handler) > Suppose I have created a file in path: called "c" containing the following > lines: > > sys:c/ > fred:c/ > barbarella:c/ > > and have done something like 'assign c: path:c' or even > 'path reset path:c'. Apparently, the PATH: device first checks on the > existence of its entries, one by one, Charles then points out that path: asks first for fred:, then for barbarella:, then for fred: again (first request to see if fred:c exists, second to find the command in it). I agree that this shouldn't happen, but in the long run, I think you'll be happier if you simply make path:c read: sys:c/ rad:c/ df0:c/ df1:c/ (or something similar) which will then search the mounted drives and no others. You'll still get a requester if there is no floppy at all in df0: and/or df1:, but I think that is rarely the case. > After putting path:c in my command path (via 'assign c: path:c' or > say 'path reset path:c'), often (perhaps always) when I try to execute > the 1.3 command 'more' (which is pure but which I have not made > resident) I am visited by the GURU Hmm, I *think* I've used more with path-handler installed without trouble, but I'll check. ... OK, I'm back (ah the joys of multitasking). I just used the 1.3 More when More was in sys:C without trouble. I did a PATH RESET, and an ASSIGN C: PATH:C with PATH:C being the above file, and More S:Startup-Sequence went without trouble. Conman and WShell in use. I have used PATH: on several other occasions, without any trouble, under most 1.3 Omegas and the release. >This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider. This is why RAD: doesn't recover. No recoverable RAM disk can survive in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for its existence. Only true FAST RAM will work. Possible commercial announcement: Bill Hawes says over on BIX that he has finished a similar Path-Handler which will come with the next update of WShell. It allows you to simply say: Assign C: Sys:c,df0:c,df1:c (for example). You can also do a Dir C: with his handler, and get the result you expect, rather than an infinite stream of "Unknown Packet" errors. -- Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge RCKG01M@CALSTATE.BITNET ecphssrw@afws.csun.edu swalton@solar.stanford.edu ...!csun!afws.csun.edu!bcphssrw
raddison@castor.usc.edu (Richard Addison) (12/01/88)
In article <385@solari.csun.edu> ecphssrw@trantor.csun.edu writes: >This is why RAD: doesn't recover. No recoverable RAM disk can survive >in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for >its existence. Only true FAST RAM will work. Funny thing, I've not had any major problems recovering VD0: in 0xC00000 ram on my 2000 (with standard 512K chip, 512K "sync" memory). Am I doing something wrong? (-; I've even rebooted to disks without the VD0: driver (like the standard workbench, with the standard screen size) to do something quick and then have rebooted by customized environment with VD0: and have the contents remain. This works only because I didn't make heavy memory demands in between. So what is the real story? Richard Addison (Charles Rocket plays me on Moonlighting)
ca063@unocss.UUCP (Thomas Davis) (12/03/88)
From article <385@solaria.csun.edu>, by ecphssrw@solaria.csun.edu (Stephen Walton): > In article <284@gtss.UUCP> chas@gtss.UUCP (Charles Cleveland) writes: >>This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider. > > This is why RAD: doesn't recover. No recoverable RAM disk can survive > in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for > its existence. Only true FAST RAM will work. > Almost right. C00000 RAM will recover, IF you don't reset all the way back to Kickstart. I know. My 1000 and it's Squeeze ram (1meg @ C00000) does. Even RAD: (althougth I don't use it. I did test it out though.) The only time I don't get a recovery is if VD0: get fulls, and the system gurus, or some wild pointer mashes the magic cookies that VD0: stashes in memory. Now, if your using VD0:, check to see what version it is. The version I have is 3.0; to find out what version your using, use 1> type devs:asdg.vdisk.device opt h You'll see a hex dump with the printable ascii on the side; part of the ascii will have something like 'version 3.0, date xxxxxx'. Also make sure vd0: has a ODD number of cylinders; even will cause weird problems to develop! -- Internet : ca063%unocss.unl.edu@RELAY.CS.NET | Thomas Davis BitNet : conslt16@unoma1 | Consultant, Campus Computing UUCP : uunet!btni!unocss!ca063 | U. of Neb. @ Omaha, NE
chas@gtss.UUCP (Charles Cleveland) (12/03/88)
In article <385@solaria.csun.edu> ecphssrw@trantor.csun.edu (Stephen R. Walton) writes:
) I think you'll be happier if
)you simply make path:c read:
)
) sys:c/
) rad:c/
) df0:c/
) df1:c/
)
)(or something similar) which will then search the mounted drives and
)no others. You'll still get a requester if there is no floppy at all
)in df0: and/or df1:, but I think that is rarely the case.
Wouldn't you know it. At last I find someone who knows what I want better
than I do. And he's the wrong sex. :-) Actually I don't want to use the path
device as a substitute for the PATH command at all. Not even a little, even
if I would be happier. I just observed the behavior when checking it out
and thought it was awkward. For what I want to do instead it will be fine,
because that only involves one unmounted disk.
) I have used PATH: on several other occasions, without any
)trouble, under most 1.3 Omegas and the release.
)
Thanks for the info. I stopped using my test path device file instead of
the PATH command and my GURU's stopped too. Must be some odd interaction.
)>This is under 1.3 Kickstart on an Amiga 1000 with a Michigan Insider.
)
)This is why RAD: doesn't recover. No recoverable RAM disk can survive
)in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for
)its existence. Only true FAST RAM will work.
By God you're right. I thought RAD:, like vd0:, might survive some boots
like a simple vulcan nerve pinch, but apparently not. Now I have to decide
whether the speed of RAD: under FFS is better than, say, just using RAM: or
enjoying the sometimes recoverability of vd0: Well, since my development
programs almost never produce GURUs ;-) ...
)
)Possible commercial announcement: Bill Hawes says over on BIX that he
)has finished a similar Path-Handler which will come with the next
)update of WShell. It allows you to simply say:
) Assign C: Sys:c,df0:c,df1:c
)(for example). You can also do a Dir C: with his handler, and get the
)result you expect, rather than an infinite stream of "Unknown Packet"
)errors.
Will it support
Assign L: sys:L, wp:L, Lattice_C_5.0.1:L ?
That is, does the search extend beyond that for commands, but to other
referenced files as well?
)--
)Stephen Walton, Dept. of Physics & Astronomy, Cal State Univ. Northridge
)RCKG01M@CALSTATE.BITNET ecphssrw@afws.csun.edu
)swalton@solar.stanford.edu ...!csun!afws.csun.edu!bcphssrw
Thanks for responding.
--
- It is better for civilization to be going down the drain than to be -
- coming up it. -- Henry Allen -
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430
UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.eduFelineGrace@cup.portal.com (Dana B Bourgeois) (12/04/88)
But Stephen Walton, I have a 1Meg Insider and both VD0: and RAD: survive warm boots. I take them for granted now. You mean they're not supposed to? Please don't tell them that! I don't want them to change. With WShell there is a global path you can set in your ENV: directory. I have RAD:c, c:, df1:c, df2:c in it and that seems to work without requesters although if one of the drives is empty then I get a requester about that if the complete path needs to be searched(like when the command doesn't exist due to mispelling). Yeah, I have three drives. Seemed cheaper and easier than a hard disk although prices and hassles seem to be dropping.
chas@gtss.UUCP (Charles Cleveland) (12/05/88)
In article <2056@nunki.usc.edu> raddison@castor.usc.edu (Richard Addison) writes: )In article <385@solari.csun.edu> ecphssrw@trantor.csun.edu writes: )>This is why RAD: doesn't recover. No recoverable RAM disk can survive )>in C00000 RAM, because of the way Kickstart 1.2 (and 1.3) check for )>its existence. Only true FAST RAM will work. ) )Funny thing, I've not had any major problems recovering VD0: in 0xC00000 )ram on my 2000 (with standard 512K chip, 512K "sync" memory). Am I )doing something wrong? (-; I've even rebooted to disks without the VD0: )driver (like the standard workbench, with the standard screen size) to )do something quick and then have rebooted by customized environment with )VD0: and have the contents remain. This works only because I didn't )make heavy memory demands in between. ) )So what is the real story? ) )Richard Addison (Charles Rocket plays me on Moonlighting) Well I don't know the whole real story, which I too would like to hear. It involves the fact that the OS doesn't always feel a need to re-verify the existence of C00000 memory on a warm boot, depending on how trashed the system is. I also got FFS RAD: quasi-recovering. I just got through writing about it, but I notice on looking back that it only went to comp.sys.amiga.tech and not here, and since it may be of general interest I quote it below. Comp.sys.amiga article follows -> Newsgroups: comp.sys.amiga.tech Subject: Re: Partitioning RAD: Summary: Expires: References: <3012@sugar.uu.net> <282@gtss.UUCP> <3702@druwy.ATT.COM> Sender: Reply-To: chas@gtss.UUCP (Charles Cleveland) Followup-To: Distribution: Organization: Georgia Tech School of Physics Keywords: In article <3702@druwy.ATT.COM> mab@druwy.ATT.COM (Alan Bland) writes: )In article <282@gtss.UUCP>, chas@gtss.UUCP (Charles Cleveland) writes: )> When I set up RAD: under FFS (but not under SFS), I seemed to have to format )> it before using it even though it was a single filesystem, contrary to your )> remark above. ) )My RAD: is setup under FFS as a single filesystem, and it does not need )to be formatted. After mounting, RAD: is automagically formatted on cold )boot (my MountList specifies Mount = 1, or whatever the parameter is, that )tells it to load the handler immediately when mounted rather than waiting )until the first access). Make sure your MountList includes both the FFS )handler and the dos type (I forget the exact names of the parameters). Mount = 1. That's the ticket. Now not only does my FFS RAD: not need to be formatted, but it has regained the quasi-recoverability (it goes in C00000 memory in my machine), like vd0:'s, that I had hoped for. Examination of my startup-sequence reminds me that I had RAD: recovering before while a slow-file system, but conversion to FFS without Mount = 1 if RAD: lives in C00000 apparently prevents any recoverability at all. I was surprised, after adding 'Mount = 1' to my mountlist and removing the format from my startup-sequence, when I rebooted with that disk and none of the expected copies to RAD: occurred. When I looked, RAD:'s contents were still intact from yesterday, when it had been mounted without 'Mount = 1' in my mountlist. In fact, in the meantime, I had even rebooted twice from other disks that don't even know about RAD:, but use vd0: instead. Thanks. That hit the spot. -- - It is better for civilization to be going down the drain than to be - - coming up it. -- Henry Allen - Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430 UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edu
bader+@andrew.cmu.edu (Miles Bader) (12/06/88)
chas@gtss.UUCP (Charles Cleveland) writes: > In article <385@solaria.csun.edu> ecphssrw@trantor.csun.edu (Stephen R. Walton) writes: > )Possible commercial announcement: Bill Hawes says over on BIX that he > )has finished a similar Path-Handler which will come with the next > )update of WShell. It allows you to simply say: > ) Assign C: Sys:c,df0:c,df1:c > )(for example). You can also do a Dir C: with his handler, and get the > )result you expect, rather than an infinite stream of "Unknown Packet" > )errors. > > Will it support > Assign L: sys:L, wp:L, Lattice_C_5.0.1:L ? > > That is, does the search extend beyond that for commands, but to other > referenced files as well? What are the limits on what's passed as the name of a file? If it's possible, I'd like to see a path device that works something like (e.g): assign c: path:sys:c/,mydisk:c/ makes looking for a file on c: look in sys:c and mydisk:c So can you pass ":" and ","? And what are the name length limits? -Miles