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
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
My two cents... B^)
-Mike
--
INET : mi...@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??
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-----*/
/*------------------------------------------------------------------------*/
[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
jg...@cisunx.UUCP, jgh2@{unix or vms}.Cis.Pittsburgh.Edu, jg...@PITTVMS.BITNET
An Ounce Of Inaccuracy Saves A Pound Of Explanation
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...
I have been having problems with PATH:. Our site didn't receive the docs...
and I'm unable to actually create files in it. If I copy a file to
path:file, or just to path:, or use some other method (redirection, saveas
from DME, etc) I always get "error", "can't find ... " or some other
message that indicates it couldn't open the file. What exactly do I need
to do?
John
--
"The sinuous roots meshed together... the sun-dappled leaves... the arching
branches... and put it all together? Nothing! Icky, icky tree!"
-- something like that anyway; from "The Kids in the Hall"
John Toebes replies:
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 |
...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 --
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 <1...@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.
I haven't had much time to play with this - it's finals time here at CMU :-(
- Derek
ARPA: dn...@andrew.cmu.edu
I've been using the ARP assign to PATH: in my startup sequence for several
weeks now. Which release of ARP are you using? I am using the latest that
I know of: ARP Rel 2 (aka v1.(1?)). I am sure that I am not accidentally
using the amigados assign, because I am doing the about following:
"Assign c: path:c rexx: path:rexx", which only ARP will do. This is kind
of a silly question, but are you sure you are doing the copy to PATH:
BEFORE you do the assign?
Scott Henry
--
Scott Henry <sco...@harlie.sgi.com> {or, also on the Internet:}
<skyw...@cup.portal.com>
#include <std_disclaimer.h>
Sorry not to respond sooner, but I kept forgetting to check this when I was
home, and I usually read the news at work. (Work? You call this work???)
I had a similar problem when I installed PATH:. What I had done was to put
the path-handler file in L:. Silly me. The mountlist has it as being in
DEVS:.
Now me, I changed the mountlist entry. Handlers belong in L:. Devices (and
other things I cannot find a collective noun for) belong in DEVS:.
Let's everybody try to remember this.
(And since I'm making such a big ass out of myself, what is the difference
between a device and a handler anyway?)
--
- 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: ch...@gtss.gatech.edu