rayz@koko.UUCP (Ray Zarling) (12/02/88)
[] I just got my upgrade to Lattice C v5.0, and I am bitterly disappointed! Yes, it seems to have all the goodies as advertised. Yes, it produces executables that seem to be typically 15% smaller than under 4.01. BUT... The only way I can run it on my system is to boot from the compiler disk! I try to run my Amiga with two floppies and a ram disk. That means I have a 99.99% full CLI disk in drive 0, my application in ram disk, and a disk with compiler executables and libraries in df1:. Under v[34].*, this worked fine--just assign LC: to an approriate subdirectory of my compiler disk, do other assigns for INCLUDE:, QUAD: and LIB:, and compile away! But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: directory! (I tried putting the subdirectory with the compiler on the AmigaDOS path, but that didn't help.) I don't have room for several hundred more blocks of programs in my C: directory! I don't know if the other programs that lc wants to load also have to be there; lc2b, go (the optimizer), ...? If I try to configure the way I did under all the previous versions, lc just complains that it "Can't find lc1." Oh yes-- I *can* run the compiler passes separately, like the good ol' days: LC:lc1 -xxx blah; then later LC:lc2 -yyy blah... But you don't get the optimizer etc. this way, and anyways it's a pain! I called Lattice about this, and all they could suggest was to assign C: to the directory with the lattice executables! I suppose this will eventually work, but I will then have to put sys:c/ separately on my path, and I only got as far as trying it and discovering that RUN has to be moved to also be in the subdirectory with the lattice programs before I gave up in disgust at having to rework my entire environment. WHY? can't lc just look for lc1 etc. in LC: like it always has? Or like the documentation still implies that it does? Anyone know of a simple work-around for us poor people without hard disks who don't want to reboot just so they can do some compiling? --Ray Zarling ...uunet!lll-winken!csustan.EDU!rayz
jesup@cbmvax.UUCP (Randell Jesup) (12/05/88)
In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: >But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: >directory! (I tried putting the subdirectory with the compiler on the >AmigaDOS path, but that didn't help.) I don't have room for several >hundred more blocks of programs in my C: directory! I don't know if the >other programs that lc wants to load also have to be there; lc2b, >go (the optimizer), ...? If I try to configure the way I did under all >the previous versions, lc just complains that it "Can't find lc1." 5.0 doesn't search in LC: like 4.0 did, it searchs the AmigaDos path. Try again, with a "path lc: add" before using lc. I guarantee that it works (though I also wish it would search lc:, at least if the path didn't find it - it's a very minor point, though, since LC: must be in your path in order to find lc - it only really affects shells that use their own non-AmigaDos paths.) -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
mikhe@tragicomix.liu.se (Mike Henry) (12/05/88)
In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: >But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: >directory! (I tried putting the subdirectory with the compiler on the >AmigaDOS path, but that didn't help.) I don't have room for several >hundred more blocks of programs in my C: directory! I don't know if the This doesn't sound good, but maybe you can cure the symptoms by using the PATH: device and assign your C: to maybe PATH:c where the file c contains the paths to all directories you *allways* need to access... My two cents... B^) -Mike -- INET : mikhe@majestix.liu.se /// UUCP : {mcvax,munnari,ukc,unido}!enea!liuida!majestix!mikhe /// ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\\/// What SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN \XX/ Else??
toebes@sas.UUCP (John Toebes) (12/05/88)
In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: >I just got my upgrade to Lattice C v5.0, and I am bitterly disappointed! >Yes, it seems to have all the goodies as advertised. Yes, it produces >executables that seem to be typically 15% smaller than under 4.01. BUT... >The only way I can run it on my system is to boot from the compiler disk! > >But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: >directory! (I tried putting the subdirectory with the compiler on the >AmigaDOS path, but that didn't help.) The LC driver program searches the standard path for the compiler using the Execute() function. On my system, I put the compiler and all other utilites in the LC: directory and just put that on the path. Note LC: and C: are on separate volumes. One advantage to doing this is to allow putting all the commands on a separate disk and add that as necessary. By using Execute() [and a few other tricks] we are also able to pick up the compiler even if it is resident. One additional note, the compiler needs to locate the error messages in s:lcerrs.txt followed by lc:lcerrs.txt We spent quite a bit of time examining this issue to see what would work best and this allows one to make the compiler resident, still have LC: to a separate floppy, but have the error messages in the S: directory where most configuration files go. As to solutions to finding out what is wrong, you should check to ensure that 1) The programs are in LC: 2) LC: is on the path. path lc: add 3) Try running them from the CLI with: LC1 <----- NOT LC:LC1 LC2 <----- NOT LC:LC2 4) Make sure you aren't using a shell that setfunctions Execute() in a non compatible way. We know that the standard Amiga Shell and CLI as well as WShell are compatible with allowing the resident commands to work. 5) If you are running REZ, try it without it once. There have been reports of problems with REZ misrecognizing the type of program and then attempting to 'patch' the resultant executable on loading. 6) If the above fail, check to see how badly fragmented your memory is. It is possible that there is something in your startup sequence that is eating memory. If all the above fail, I will be just as stumped as tech support. The compiler and driver program use as vanilla an interface into the operating system as is possible. It does not count on any internal interfaces and does run under 1.1, 1.2 and 1.3. [I haven't loaded 1.0 in a while but suspect it will work under it too]. /*---------------------All standard Disclaimers apply---------------------*/ /*----Working for but not officially representing SAS or Lattice Inc.-----*/ /*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ /*------------------------------------------------------------------------*/
jgh2@cisunx.UUCP (John G. Hardie) (12/06/88)
In article <5424@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: >>But 5.0 now requires the compiler passes lc1 and lc2 to be in your C: >>directory! (I tried putting the subdirectory with the compiler on the [stuff deleted to please this stupid mailer] > 5.0 doesn't search in LC: like 4.0 did, it searchs the AmigaDos >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup This is strange. I'm running 5.0 on an A1000 with 1 Meg. I've got Wshell running (and AREXX). The system disk is in df0, the compiler and linker (and includes, libraries, optimizer...) are in df1. THe executables are in directory c on the compiler disk (which, by the way is not bootable) and this directory is NOT on the path. In fact my path contains only the current directory, and C: which is assigned to ram:c. I assign LC: to df1:c. I can compile files from anywhere by typing LC:lc ... I can even run the global optimizer without any problems. So, does the compiler search ENV:PATH which Wshell uses? My ENV:PATH contains df0:c, df1:c, ram:c and current dir, while my AmigaDOS path contains nothing useful. I set up this way so that I NEVER get an "insert disk" requestor, and commands can be found automatically on any disk that I insert (very nice.) Anyway, I don't have any trouble with the compiler. Just thought that I'd get my .02 in. John -- John Hardie - Physics Dept U. Of Pittsburgh Pittsburgh, Pa 15260 jgh2@cisunx.UUCP, jgh2@{unix or vms}.Cis.Pittsburgh.Edu, jgh2@PITTVMS.BITNET An Ounce Of Inaccuracy Saves A Pound Of Explanation
john13@garfield.MUN.EDU (John Russell) (12/06/88)
In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: > >Anyone know of a simple work-around for us poor people without hard disks >who don't want to reboot just so they can do some compiling? What you really need is about 2 megs of memory. Until you have enough room to create specially setup ramdisks with the configurations of C:, libs:, etc in memory you'll find you either need to reboot a lot or create special work disks for different jobs you may want to do. In any case you'll need a number of CLI / Shell scripts to customize your setup for compiling, wordprocessing, using certain paint programs, etc. So it does require a good deal of work and experimentation. Stick with it, and after a while you should be able to automate the entire process; the memory will really, really help though. John -- "Media is Ignorent, Researchers Say" -- either this is an incredibly sarcastic headline-writer, or...
dave@dms3b1.UUCP (Dave Hanna) (12/07/88)
In article <731@sas.UUCP> toebes@sas.UUCP (John Toebes) writes: >In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) says he can't run Lattice C 5.0 except by booting from the Lattice disks. John Toebes replies: >The LC driver program searches the standard path for the compiler using the >Execute() function. On my system, I put the compiler and all other utilites >in the LC: directory and just put that on the path. Note LC: and C: are on >separate volumes. One advantage to doing this is to allow putting all the >commands on a separate disk and add that as necessary. By using Execute() >[and a few other tricks] we are also able to pick up the compiler even if >it is resident. One additional note, the compiler needs to locate the error >messages in s:lcerrs.txt followed by lc:lcerrs.txt We spent quite a bit of >time examining this issue to see what would work best and this allows one to >make the compiler resident, still have LC: to a separate floppy, but have the >error messages in the S: directory where most configuration files go. > >As to solutions to finding out what is wrong, you should check to ensure that > 1) The programs are in LC: > 2) LC: is on the path. > path lc: add > 3) Try running them from the CLI with: > LC1 <----- NOT LC:LC1 > LC2 <----- NOT LC:LC2 > 4) Make sure you aren't using a shell that setfunctions Execute() in a > non compatible way. We know that the standard Amiga Shell and CLI as well > as WShell are compatible with allowing the resident commands to work. > 5) If you are running REZ, try it without it once. There have been reports > of problems with REZ misrecognizing the type of program and then > attempting to 'patch' the resultant executable on loading. > 6) If the above fail, check to see how badly fragmented your memory is. > It is possible that there is something in your startup sequence that > is eating memory. >If all the above fail, I will be just as stumped as tech support. The compiler >and driver program use as vanilla an interface into the operating system as >is possible. It does not count on any internal interfaces and does run under >1.1, 1.2 and 1.3. [I haven't loaded 1.0 in a while but suspect it will work >under it too]. Okay, I too am having problems. Maybe I should have sent this E-Mail, but I figure I'm probably not the only one. Configuration: A2000, two floppies, no Hard drive, 1 Meg Ram, AmigaDos 1.2 with DMouse, cron, SPUDclock and NAG running in background. Running Dillon/Drew Shell2.07M I made a disk called 'Comp:' with a c directory containing lc, lc1, lc2, lcerrs.txt and lcerrs.deutsch. Also on Comp: is an include directory with the entire CompactH directory copied to it. I run the following commands: cp c:run ram: cp c:assign ram: assign LC: Comp:c assign INCLUDE: Comp:include assign QUAD: RAM: path LC: add cd SourceCode: (where my source file is) assign C: ram: LC hello The compiler puts up its banner, grinds around on the disks for a little bit, says "Compiling hello.c", and then hangs. DMouse is unresponsive (won't bring up a new shell). I brought up a new CLI by clicking on the CLI Icon and ran Xoper, which seemed to show something consuming 100% of CPU dispatch cycles. Starting on your checklist, I was already doing 1 and 2 (the commands are in LC (or at least a directory that LC: is assigned to), and it is on the path. To make sure of 4 (nothing that Setfunction's Execute() ), I got rid of all my background stuff and ran from a straight CLI (broke out of my Startup-Sequence.) Same symptoms. I'm not running REZ. And, since I'm running this right after my Startup, I don't think memory is too fragmented. However, I can execute the same thing as above, except substitute LC1 hello LC2 hello and it runs to completion. Oh, and it does run if I boot disks 1 and 2 of the Lattice Distribution and run from that. I had just about decided that it needed 1.3 to run, when I saw your post that it would run from 1.1, 1.2 or 1.3. I'm going to make up a 1.3 configuration when I get time, but what do I do in the meantime? Any help would be greatly appreciated. >/*----John A. Toebes, VIII usenet:...!mcnc!rti!sas!toebes-----*/ -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
pete@violet.berkeley.edu (Pete Goodeve) (12/08/88)
In article <5021@garfield.MUN.EDU> john13@garfield.UUCP (John Russell) writes: >In article <866@koko.UUCP> rayz@koko.UUCP (Ray Zarling) writes: >> >>Anyone know of a simple work-around for us poor people without hard disks >>who don't want to reboot just so they can do some compiling? > >What you really need is about 2 megs of memory. [....(otherwise set up >specialized work disks)....] > >In any case you'll need a number of CLI / Shell scripts to customize your >setup for compiling, wordprocessing, using certain paint programs, etc. > ...I too, have a number of specialized system disks, but I never usually have to reboot. I've standardized on a command script called "use" on all of these disks, which simply reassigns all the necessary system directories, paths and so on to something suitable for the task at hand. Then I just have to type "df0:use" to get going in that environment. [Well, until 1.3 came along, if you didn't use Sili(Con:) you would have had to type "execute df0:use" or something...(:-))]. Now that I have lots of memory [thanks Mike -- it's still running fine!], I keep C: itself in VD0:, and work there, and my 'use' script mainly just inserts the new stuff into the path, but for C compiling, for example, it also assigns INCLUDE: and LIB: and so on. If you want to work entirely from floppies, you'll have to assign DEVS:, L:, and so on as well. Oh, yes -- in that case you want to make your first script command DF0:C/assign C: DF0:C so that all the rest of the commands can be executed from the C: directory currently available. -- Pete --
pete@violet.berkeley.edu (Pete Goodeve) (12/08/88)
Just in case it helps shed any light, I'm running 5.0 without any trouble. My configuration is A1000 with 4.5M memory and two floppies. VD0: is SYS:, with C: and all the other essential system directories there. [Is't possible by the way, that some people having trouble have omitted to provide L:, LIBS:, DEVS: or something on their C system disk? ...just a thought.] I compile in a subdirectory of VD0:, but rather than transfer the compiler files to RAM, I run them off two floppies; DF0: contains the compiler executables, DF1: has the includes and headers. I have a command script that basically sets things up as follows: assign LC: df0:c assign LIB: df1:lib assign INCLUDE: df1:CompactH path LC: add The original C: is always available of course with all the normal system commands (especially RUN, for lc's sake). All works fine. Where's the difference? I dunno. -- Pete --
dave@dms3b1.UUCP (Dave Hanna) (12/09/88)
In article <18017@agate.BERKELEY.EDU> pete@violet.berkeley.edu (Pete Goodeve) writes: >Just in case it helps shed any light, I'm running 5.0 without any trouble. >My configuration is A1000 with 4.5M memory and two floppies. VD0: is SYS:, >with C: and all the other essential system directories there. [Is't possible >by the way, that some people having trouble have omitted to provide L:, >LIBS:, DEVS: or something on their C system disk? ...just a thought.] ^^^^^^^^^ that's it - something. >I compile in a subdirectory of VD0:, but rather than transfer the compiler >files to RAM, I run them off two floppies; DF0: contains the compiler >executables, DF1: has the includes and headers. > >I have a command script that basically sets things up as follows: > > assign LC: df0:c > assign LIB: df1:lib > assign INCLUDE: df1:CompactH > path LC: add > >The original C: is always available of course with all the normal system >commands (especially RUN, for lc's sake). All works fine. Where's the >difference? I dunno. > -- Pete -- After posting article <168@dms3b1.UUCP>, I spent another 4 or 5 hours experimenting last night, and finally isolated it. I'll spare the gory details of how I arrived at this conclusion, but if EndCLI is available to it, it runs, otherwise it doesn't. (Why EndCLI? Beats the h*** out of me.) This would be masked if you are running with a complete C: directory available, either on HardDisk or a large RAM:. Since I have a stock 2000, I don't want to put an entire C: directory in RAM:, and I want to have a disk with my source code on it. That means I need to get the compiler and include files all on one disk, so the set-up described above doesn't work very well. I now copy c:Run and c:EndCLI to RAM: in my startup, and it seems to run fine. Now if I can just get make to work right.... But that's another story. Dave Hanna. -- Dave Hanna, Daltech MicroSystems | "Do or do not -- There is no try" P.O. Box 584, Bedford, TX 76095 | - Yoda (214) 358-4534 (817) 540-1524 | UUCP: ...!killer!gtmvax!dave |
dn0o+@andrew.cmu.edu (Derek Brooks Noonburg) (12/09/88)
I also had the same hanging problem when I first installed 5.0. After an hour or two of fiddling, I found out that lc needs endcli in your path. If it's not there, lc hangs, but lc1 and lc2 run fine. Another interesting detail: if your path causes a disk switch requester (please insert volume...) while looking for endcli and you hit cancel, lc exits with a reasonable error instead of hanging. I haven't had much time to play with this - it's finals time here at CMU :-( - Derek ARPA: dn0o+@andrew.cmu.edu