kms@ecsvax.UUCP (Ken Steele) (06/10/89)
I am having some weird/silly problem using C-A's assign. I want to
make the following assignment--
assign LC: L1:c
assign INCLUDE: L2:CompactH
assign LIB: L2:lib
assign QUAD: ram:
So I am just doing assigns to two different volumes. Not very
tricky, eh what? Here is the problem. The assignment of the second
disk produces the reassignment of the first disk to--
LC: Volume: L1
I've tried all sorts of variations: relabeling the disks with longer
names, very different names, doing the assigns individually (disks
already inserted or not), and so forth. Each time the same thing
happens. When the second assign occurs, the first assign is
changed (whatever the particular assigns). And it is changed. "lc
-L hello" fails to find lc1 and lc2.
It can't be that you can only do assigns to currently mounted
volumes. What extremely dumb thing am I doing? ARGHH! such
embarassment!
--
Ken Steele Dept. of Psychology kms@ecsvax.[bitnet || UUCP]
Mars Hill College kms@ecsvax.uncecs.edu
Mars Hill, NC 28754 new@udel.EDU (Darren New) (06/10/89)
If you have an assign to a directory on the disk and then remove the disk from the drive, the assign command will only tell you the disk name and not the full directory path. This is because the assign creates a lock (containing a pointer back to the volume lock). All of the intermediate directory names on the path are not around anywhere when the disk is out. Try doing the assigns and put the LC1: disk back in to check the assigns on that volume. Since you say that the LC command does not find the locks, something may indeed be wrong; but it sounds like a misinterpretation of output to me... -- Darren
kms@ecsvax.UUCP (Ken Steele) (06/10/89)
In article <17283@louie.udel.EDU>, new@udel.EDU (Darren New) writes: > If you have an assign to a directory on the disk and then remove the > disk from the drive, the assign command will only tell you the > disk name and not the full directory path. This is because the > assign creates a lock (containing a pointer back to the volume lock). > All of the intermediate directory names on the path are not around > anywhere when the disk is out. Try doing the assigns and put the > LC1: disk back in to check the assigns on that volume. > Since you say that the LC command does not find the locks, > something may indeed be wrong; but it sounds like a misinterpretation > of output to me... -- Darren I didn't have THE disks handy, so I grabbed a couple that were handy and checked. Just as you said (and I had unconsciously assumed). That leaves the question of why LC fails, which is what led me to the question about assigns. LC is located in sys:u and hello.c is located in sys:src (call me mr. originality). LC1 and LC2 are located in L1:c, everything else is in L2:. What seems to happen is this. If L1: is already in the drive, then LC exits after the first disk swap (to L2:) with the error that it can't find LC2. If L2: is in the drive, then LC exits with the error that it can't find LC1. Any suggestions? -- Ken Steele Dept. of Psychology kms@ecsvax.[bitnet || UUCP] Mars Hill College kms@ecsvax.uncecs.edu Mars Hill, NC 28754
shadow@pawl.rpi.edu (Deven T. Corzine) (06/11/89)
In article <7145@ecsvax.UUCP> kms@ecsvax.UUCP (Ken Steele) writes: >LC is located in sys:u and hello.c is located in sys:src >(call me mr. originality). LC1 and LC2 are located in L1:c, >everything else is in L2:. [sys:U?] >What seems to happen is this. If L1: is already in the drive, >then LC exits after the first disk swap (to L2:) with the error that >it can't find LC2. If L2: is in the drive, then LC exits >with the error that it can't find LC1. >Any suggestions? Your problem is (again) that the correct disk is not in the drive. LC is simply a driver program which parses arguments and serves to coordinate compilation at a higher level. (Unix "cc" works the same way.) When you try to compile something, LC will Execute() each stage of the compiler and (if the -L switch is specified) it will Execute() the linker as well. What it comes down to is that even though you may have LC: in your path (you should) it will not get executed unless it is immediately available. Execute() will follow the path, but it will ONLY actually ask for the disk containing C: if it can't find the executable. This means you must assign c: (as well as lc:) to L1:c, so AmigaDOS will request the disk back to continue with the compiler passes. In older versions of Lattice C, it used to Execute() "LC:LC1" instead of "LC1", so it would not follow the path. This has been changed, but can cause inconvenience for those with only a floppy drive available. If you can afford the memory, making LC1 and LC2 resident (either with ARes (if you use ARP 1.3) or Resident (with AmigaDOS 1.3)) will both save you a lot of time loading the passes, and keep you from having to have the disk in the drive. If you have less than 1 Meg of memory, you won't be able to do this. With 1 Meg, you're pushing it, but can perhaps get a workable system if you get rid of as much other ram as possible. (RAD:, other resident programs, etc.) If you've over 1 Meg, you can probably keep LC, LC1, LC2 and BLINK all resident and compile most things unless they're quite large. With over 2 Meg, you're home free. Alternatively, you can try cramming the necessary executables (lc, lc1, lc2, blink, maybe omd and one or two others) along with ALL the (compacted) include files and at least lc.lib and amiga.lib onto a single floppy... Then you can compile programs in ram (not on a floppy) with everything assigned to that single disk. For complicated programs, reassign libs: to l2:libs during linking. Anyway, I think you get the idea... [the lengths we must go to avoid disk swapping and thrashing... *sigh*] Deven -- shadow@[128.113.10.2] <shadow@pawl.rpi.edu> Deven T. Corzine (518) 272-5847 shadow@[128.113.10.201] <shadow@acm.rpi.edu> 2346 15th St. Pi-Rho America deven@rpitsmts.bitnet <userfxb6@rpitsmts> Troy, NY 12180-2306 <<tionen>> "Simple things should be simple and complex things should be possible." - A.K.
kms@ecsvax.UUCP (Ken Steele) (06/12/89)
In article <SHADOW.89Jun10190508@daniel.pawl.rpi.edu>, shadow@pawl.rpi.edu (Deven T. Corzine) writes: > In article <7145@ecsvax.UUCP> kms@ecsvax.UUCP (Ken Steele) writes: > > > >What seems to happen is this. If L1: is already in the drive, > >then LC exits after the first disk swap (to L2:) with the error that > >it can't find LC2. If L2: is in the drive, then LC exits > >with the error that it can't find LC1. > > >Any suggestions? > > In older versions of Lattice C, it used to Execute() "LC:LC1" instead > of "LC1", so it would not follow the path. This has been changed, but > can cause inconvenience for those with only a floppy drive available. > > > Deven Thanks for the help, Deven. For those of you who need to work on an A1000+512k+2floppies (we prefer to say the classical configuration ;-) here is a setup that 5.0 seems to tolerate. Put the executables (lc, lc1, lc2, blink, etc) AND the compacted includes on the same disk. Put the lib files on another disk. Blink looks to LIB: and has no problem with the disk swap. If you know that you will only need a couple of the included libraries then you can squeeze it down to only 1 disk. I need extra room for another library and kept with the 2 disk setup. > -- -- Ken Steele Dept. of Psychology kms@ecsvax.[bitnet || UUCP] Mars Hill College kms@ecsvax.uncecs.edu Mars Hill, NC 28754