#SAS/C 5.10A Patch
36 messages in this thread
****************************
*** SAS/C VERSION 5.10A ***
****************************
Wednesday, December 5, 1990
SAS Institute, Inc. would like to announce version 5.10A of their SAS/C
Compiler for AmigaDOS. The new version, available free to all registered
owners of the 5.10 release, comes in the form of a patch that is applied to
your existing 5.10 SAS/C executables and include files.
5.10A is primarily a bug fix release, but there are a few new options to
implement user requests. The following new options are available on lc and
lc1:
-go Indicates error and warning messages should be sent to the normal
stderr stream as well as to the listing file. Useful in
conjunction
with other listing flags to indicate the disposition of your
messages.
-ja Suppresses ANSI escape sequences in compiler errors and warnings.
-pt Suppresses the use of typedefs when generating prototypes.
Implies
the -pr flag to generate prototypes – no object file will be
created, the -o option will specify the location of the prototype
file instead!
Also, 5.10A allows national characters in identifiers. Hex codes 0xC0
through 0xFF are treated as normal characters.
For 5.10 owners, the 5.10-to-5.10A upgrade patch is available on CompuServe
in the AMIGATECH section 5 area as sasc510a.lzh. You will need LHARC, LZ,
LHUNARC or some other de-archiver that handles the same format. Please be
aware that this patch is NOT freely redistributable, and should not be
uploaded to any bulletin boards or online services.
If you choose not to download the patch from CompuServe, you may contact
the Institute and ask for a free patch disk. The phone number is
(919)677-8000, from 9:00 AM to 5:00 PM Eastern Standard Time. Ask for the
Book Sales Dept. extension 5042. You can also send FAX requests to
(919)677-8166, or write the Institute at the following address:
********************
SAS Institute, Inc.
Attn: Book Sales Dept.
SAS Campus Drive
Cary, NC 27513
USA
********************
Registered owners of versions 5.0, 5.02, 5.04 and 5.05 of the Lattice C
Compiler
for AmigaDOS can upgrade to SAS/C version 5.10A for the upgrade fee of
US$40. This includes a full set of six disks and new manual pages.
Registered owners of version 4 can upgrade for US$100, which includes a
full set of six disks and completely new manuals. Registered owners of
previous versions of the Lattice C Compiler or Amiga C can upgrade for
US$125.00. All upgrades include shipping in the United States and Canada;
contact SAS Institute for information about shipping to other countries.
The Institute would like to thank its beta testers for many hours of work
making the 5.10A release a product that we can be proud of. Next stop,
6.0!
John, 6.0? Is this to be the release that fully incorporates
compiler/editor ala Turbo C?????
BTW, how is C++ coming?
— Ethan
Actually, we have gone a long way to incorporate the compiler/editor with
the 5.10 release. If you have errors while compiling it will invoke the
editor with the errors loaded and you can invoke the compiler/linker fro
the editor. We are definitely moving further and further in this
direction. Note that we will be constantly updating the product, so 6.0
will just be another step in a forward direction. There will be many
releases after that (providing the amiga stays alive :-)!) so don't just
wait around for a particular release…
C++ is in development. We are not satisfied that it is alpha stage yet, we
want it to be a solid product.
Well, I guess when I meant an integrated compiler-editor I meant a
complete revamp of lse. Only a very few SAS users actually use lse. Most
use Cygnus Ed or some PD editor.
— Ethan
If you want to use CEDPro instead of LSE in SAS's integrated environment,
look the program LTOCED on disk 6 of the 5.1 distribution disks.
I didn't even know that was there! Thanks.
— Ethan
Actually, a surprisingly high number of people actually use LSE (and like
it). However we have included support for Cygnus Ed on disk 6. You will
see more of this level of support in the future – limited only by the
capabilities of the editor.
John –
I vote with BobR. While I have CED, I use and prefer UEdit.
– Nelson …
(Dedicated to saving the world from my bad code.)
I'm partial to SEDT, since its been ported to the IBM, Amiga, VAX, and
other machines. Cheers, Paul (WA1OMM)
John,
A couple of things I wouldn't mind seeing in LSE is the ability to use the
mouse to mark a block, and the ability to use the shift key as a qualifier
with the cursor keys.
And a file requestor would come in real handy, too. (I vote for Khalid's
file requestor)
73, Kelly
Oh, yes, thanks for uploading the patch file.
Both are on 'the list' already. They have been marked for 6.0 target
although the mark block with mouse is lower priority of course.
If you want suggestions on changes to LSE, I'll mention my one biggest pet
peeve about it: It assumes I use K&R style for my curly braces, and
indents/undents accordingly. I *hate* that. I personally use the
following style:
if (something)
{
do something
do something else
}
do a different thing
and lse makes it *really* a pain in the neck to do this with. Also, being
able to set tab stops would be nice…
–>Steve Bennett
You wouldn't be asking for an (dare i say it) 'option' to configure how LSE
does the brace indentation, now would you? It is already on the list of
things to be done. The hardest part is designing the user interface for
specifying it.
As for tab stop setting, you can do it. Just go into the mode menu (F2 M)
and select the tab stop option to change tab stops. Type in the new tab
stops, press return and then press 'S' to save them to disk. Make sure you
are using 5.10a for the save to disk. I remember some strange bug
associated with a crash for that saving operation.
Actually, all I need is for Brace Indentation to be disabled. Since LSE
already retains the current indent level, I don't need any automatic
indent/undent on braces.
As for the user interface, a nice change would be to have all options in
a requester, which is called up when you select an Options menu item. Then
you go click on buttons and the like with the mouse and voila! Simple, no?
And I saw someone mention click and drag on text to select… YES!!! DO
THIS!!! Pretty please? 🙂
–>Steve Bennett
John, I personally would rather see SAS concentrate on the compiler and
let others work on editors. My vote is for SAS to release ARexx drivers and
setup programs, like ltoced, for the popular editors. This gives more time
to improving the compiler itself. If Ced is properly reconfigured
(keystrokes changed to ARexx macros), which shouldn't take too much work,
will give you far more than rewriting lse would in far less time. Just my
NSHO.
— Ethan
Believe me, the compiler gets a lot of attention. If we were a small
company with only one or two programmers it would be an issue of working on
one verses the other. However with the resources we now have a SAS, there
are 4 developers on the compiler/tools/libraries, 4 developers on the
debugger, 2 auxilery developers on tools/support, plus assistance from
another group of 3 people on the optimizer. Of course this doesn't count
the peripheral person working on a scheduler (whatever that is :-)) or the
countless developers who are in-house scrutinizing the code quality. For
SAS Institute, the Code quality and stability is paramount. For many of
our users, providing a complete development package is equally important.
With LSE as part of the package we can be assured that someone is up and
running the day the get the product. Besides there are people out there
that think LSE is truely a great editor (myself included).
I must admit that I've never spent much time in LSE. I looked at it
quickly but never spent the time to learn it. I guess I was initially
turned off by the lack of "prettiness". B&W, no menus or requestors. Of
course, I've learned emacs so LSE shouldn't be a problem.
BTW, in considering what editors to support you should keep in mind that
GNU Emacs is coming for the Amiga. It is version 0.9 now. You'll probably
find a lot of people using it, given some time.
I'm glad to see so many people are working on cpr. I was using it today
to debug an assignment (write a heapsort routine). I made a number of silly
errors and had to step through. One thing that would've been very helpful
would be a way to watch the numerous elements of an array without having to
type watch A[n] for each one individually. That seems like a small
addition.
So, I'll be eagerly awaiting 6.0!
— Ethan
Yes, PLEASE, PLEASE put a file requestor in place !!!!
I'm glad to see the Lattice support in there. I hadn't realized it.
— Ethan
John,
Will SAS ever add a helpfile database like MicroSoft & Turbo have? This
saves a lot of time… I hate manuals and books! It's nice to have help
right at your HELP key for all Amiga & STD functions, compiler, linker,
make, editor etc…
-Troy
Certainly more interactive online help is in the works. Expect to be
surprised…
John
I just spent a miserable evening NOT patching SAS/C 5.10 to 5.10a. Well,
not completely anyway. When the patch process got to disk 5, it started to
not find the files it wanted to patch. If the messages on the screen were
to be blieved, it would appear that .pch files were corrupt in some manner,
because the files it complained about not finding appeared to be filenames
with 6 or seven letters missing. (comper instead of compiler_header, for
instance). Could lharc have blown the unlhacing process? Should I
download the patch file again? Should I order the patch disk from SAS?
Thanks for your time. I use your product lots, and like it!
-Ken
Ken,
I ran the patch here, no problems with it at all, so the upload was
fine. It's next to impossible for the file transfer from CIS to you to be
"bad", that is.. not be the same as the file we have here. It is possible
your term program munged it somehow or other.
It's also possible an error occured when extracting the files onto
that empty disk. You might try re-extracting the files again (yes…I
know, a LONG process) and make sure the floppy you're extracting to is
completely empty…no icons, no trash, no nothing on it before you start
the extracting.
Don
Dondiscarded it right after I extracted the files. I did the extract on the
CBM provided RAD: device. Could that have been the culprit?
-Ken
Ethan,
SAS/C already will support CygnusED (sort of) for the feature of
invoking the editor after a compiler error. On disk 6 of the 5.10
distribution, in the Extras directory is a program called "ltoced" and a
companion "ltoced.doc" file. While I have found this to be a bit quirky,
for me it is an improvement to learning yet-another-editor.
Hope this helps…
…BobR
John,
Thank you for making the 5.10A patches available here. It is greatly
appreciated. As usual, the patches applied painlessly.
Speaking about the "invoking the editor on compiler errors" feature,
have you (or could you) document the interface publicly? I prefer using a
different editor than LSE. Currently I am using CED Pro, for which you do
provide a program that _almost_ works right, but it does have a couple of
deficiencies — the main one being that the file you are compiling must be
in CED's idea of the current directory, which is often not the case for me.
With a published interface, those of us so inclined could then be able to
add or fix the support for our favorite editors (don't want to get
religious here :-).
Thanks…
…BobR
The 5.10a patch should have handled that better because it now passes the
entire name to the editor. The interface is so simple as to be ridiculous.
LC looks for a REXX port called (not get this) 'LSE'. If it finds it, it
send a message to it in the form 'OW UC<filename>' followed by a
'LE<errorfile>' to tell it to read the errors. That is it. As Bill Hawes
has pointed out, it is possible to write an interface for any editor by
setting up a public port that is watched by a rexx script. For the 6.0 we
want to provide more interfaces/configurations, but for now we have to see
what editors people are interested in.
John,
Thanks for the info. I was thinking it was something fairly simple like
that – just haven't had the time to investigate fully. Also good to know
about the fix for LtoCed's "problem". Obviously I haven't had a compiler
error since I applied the patches. Must not have written much code on the
Amiga today!
…BobR
John – the new switches don't do anything for me… what bugs did the patch
fix, for those of us who are using the compiler happily?
Ben
Amateur Radio Callsign is A A 7 A S
Ben,
On the SAS_PATCH5.10A disk, there is a file called "bugfix_5.10a". This
file lists all the fixes that were supposed to be done. This file is not
copied over to your HD if you execute INSTALL_HD.
73, Kelly
That's nice – but what I am trying to do is get a callout of the bugs it
fixes here in the message base, where anyone who has 5.1 can decide if it's
appropriate to patch the compiler. Many earlier patches worked only on the
original setup; that meant that if you patched your installed compiler with
the first patch that came along, you had to re-install the compiler with
the original, unpatched version before you could use the new patch. I don't
have any intention of being caught in that trap again; My 5.10 version
seems to be working 100%, so what I want to know is what bugs were fixed –
I should be able to tell if any of them are likely to bite me.
There are many, many features in the compiler that I don't use, and never
intend to. I have a very specific coding and compiling method, all of which
work well, and I have no intention of changing. This prevents bugs in the
WB interface from being significant to me, for instance.
I suspect I'm not the only one who would be interested in such a list,
therefor the suggestion for the post in the message base.
I expect to DL the patch, and hopefully the data is in there… but that
only tells me.
Ben
Amateur Radio Callsign is A A 7 A S
The bug list is part of the patch. As for 5.10a, one big thing that it
fixes is a crash when running on the 68000 as well as several enforcer
hits. Additionally it is a faster compiler in the process. You are right,
if you don't have any problems then you don't have to update to the newer
patch. There are a few people that experience the problems and for them we
have made it available.
Yes – A friend EMAILed me the bug list – I see that while the bugs seems to
be rather obscure, there are quite a few you foxed. Er, fixed. Well, maybe
foxed. :^)
Anyway, I don't run under the 68000 (and hope to Darwin I never have to
again) and none of the others looked like they are likely to bite me at any
forseeable time in the future. Compile speed, well, that's always an issue,
but I'm not suffering, typical "large" modules compile in under a minute,
most compile faster.
Good job on the bug fixes – Glad the compilers in your capable hands now.
Always did prefer the horses mouth. :^)
Ben
Amateur Radio Callsign is A A 7 A S
Ben;
I think you might (also) have been hit with a defective patch. The proper
operation of the patches for ver 4 was that they HAD to be applied
sequencially and indeed if you skipped one then it would fail.
Unfortunately, one of the versions of one of the patches was itself
defective.
73, bill
That could be, certainly.
Ben
Amateur Radio Callsign is A A 7 A S