manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) (02/04/91)
I recently purchased SAS/C and kissed goodbye the MANX C compiler that
I have used for years.
Now I have a problem. All was going exceedingly well until I decided
to include <exec/exec.h>, when I did this and compiled my program the
compiler complained about needing a closing brace in the nodes.h file
(it was pulled in by exec.h).
Seeing this I realized that I had seen a update from SAS/C 5.10 to
SAS/C 5.10a on CompuServe. I got this update and ran it. All went
fine in applying the patch(s), however it did not solve this problem.
I re-installed the C compiler and went through the patching process
again. Alas, no luck.
What is the solution? If anyone can help it will be appreciated.
I thought I would save myself from some phone-tag at SAS.
Your help is most appreciated. Thank you for your support.
-mark=
+--------+ ==================================================
| \/ | Mark D. Manes "Mr. AmigaVision"
| /\ \/ | manes@vger.nsu.edu
| / | (804) 683-2532 "Make up your own mind! - AMIGA"
+--------+ ==================================================
jap@convex.cl.msu.edu (Joe Porkka) (02/05/91)
manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: >I recently purchased SAS/C and kissed goodbye the MANX C compiler that >I have used for years. > >Now I have a problem. All was going exceedingly well until I decided >to include <exec/exec.h>, when I did this and compiled my program the >compiler complained about needing a closing brace in the nodes.h file >(it was pulled in by exec.h). Try also including <exec/types.h> before including any other <exec/#?.h> stuff. Most cbm include files include whateverelse they need. not all unfortunately.
vinsci@nic.funet.fi (Leonard Norrgard) (02/06/91)
In article <1991Feb4.215627.6222@msuinfo.cl.msu.edu> jap@convex.cl.msu.edu (Joe Porkka) writes:
Try also including <exec/types.h> before including any
other <exec/#?.h> stuff.
Most cbm include files include whateverelse they need. not all
unfortunately.
Speaking about cbm include files, they also use structures they
haven't defined yet. Not very good for typechecking... To find out
just what is wrong, compile with gcc: you'll learn a lot.
-- Leonard
PS. Now cbm folks, don't get me wrong: I just like to point out the
mistakes so you can fix them; you ARE improving :-) DS.markv@kuhub.cc.ukans.edu (02/06/91)
In article <1991Feb4.215627.6222@msuinfo.cl.msu.edu>, jap@convex.cl.msu.edu (Joe Porkka) writes: > manes@vger.nsu.edu ((Mark D. Manes), Norfolk State University) writes: > >>I recently purchased SAS/C and kissed goodbye the MANX C compiler that >>I have used for years. >> >>Now I have a problem. All was going exceedingly well until I decided >>to include <exec/exec.h>, when I did this and compiled my program the >>compiler complained about needing a closing brace in the nodes.h file >>(it was pulled in by exec.h). > > Try also including <exec/types.h> before including any > other <exec/#?.h> stuff. > Most cbm include files include whateverelse they need. not all > unfortunately. This is true of <intutition/intuition.h>. I always include <exec/types.h> as my first amiga include. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: mgooderum \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
chucks@pnet51.orb.mn.org (Erik Funkenbusch) (02/07/91)
manes@vger.nsu.edu ((Mark D. Manes) writes: >I recently purchased SAS/C and kissed goodbye the MANX C compiler that >I have used for years. I'm interested in why you switched to SAS. I have been using Manx for years as well, and i get nausea when i try and use SAS. I was just wondering about your reasons. > > > -mark= > > +--------+ ================================================== > | \/ | Mark D. Manes "Mr. AmigaVision" > | /\ \/ | manes@vger.nsu.edu > | / | (804) 683-2532 "Make up your own mind! - AMIGA" > +--------+ ================================================== > UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks ARPA: crash!orbit!pnet51!chucks@nosc.mil INET: chucks@pnet51.orb.mn.org
jesup@cbmvax.commodore.com (Randell Jesup) (02/07/91)
In article <28398.27aee697@kuhub.cc.ukans.edu> markv@kuhub.cc.ukans.edu writes: >This is true of <intutition/intuition.h>. I always include ><exec/types.h> as my first amiga include. Under the 2.0 includes this is not needed any more, all compile properly without including any other files. -- Randell Jesup, Keeper of AmigaDos, Commodore Engineering. {uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup The compiler runs Like a swift-flowing river I wait in silence. (From "The Zen of Programming") ;-)
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (02/08/91)
In article <4034@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: > >manes@vger.nsu.edu ((Mark D. Manes) writes: >>I recently purchased SAS/C and kissed goodbye the MANX C compiler that >>I have used for years. > >I'm interested in why you switched to SAS. I have been using Manx for years >as well, and i get nausea when i try and use SAS. I was just wondering about >your reasons. >> >> >> -mark= >> >> +--------+ ================================================== >> | \/ | Mark D. Manes "Mr. AmigaVision" >> | /\ \/ | manes@vger.nsu.edu >> | / | (804) 683-2532 "Make up your own mind! - AMIGA" >> +--------+ ================================================== >> > > >UUCP: {amdahl!bungia, crash}!orbit!pnet51!chucks >ARPA: crash!orbit!pnet51!chucks@nosc.mil >INET: chucks@pnet51.orb.mn.org YEAH! RIGHT ON. I use MANX too. I have ever since 1985. I don't like having to conform to ANSI. Unfortunatly, MANX rid 16 bit ints and adopted the ANSI way of doing things. Wish they could release a new version in the spirit of 3.6 for us non comformists. Until then, I'm going to continue using 3.6 and my 5.x updates will just collect dust. Jeff
espie@flamingo.Stanford.EDU (Marc Espie) (02/08/91)
In article <1991Feb7.192644.25098@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >In article <4034@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >> >>manes@vger.nsu.edu ((Mark D. Manes) writes: >>>I recently purchased SAS/C and kissed goodbye the MANX C compiler that >>>I have used for years. >> >>I'm interested in why you switched to SAS. I have been using Manx for years >>as well, and i get nausea when i try and use SAS. I was just wondering about >>your reasons. >>> [sigs deleted] > > YEAH! RIGHT ON. I use MANX too. I have ever since 1985. I don't >like having to conform to ANSI. Unfortunatly, MANX rid 16 bit ints and >adopted the ANSI way of doing things. Wish they could release a new version >in the spirit of 3.6 for us non comformists. Until then, I'm going to continue >using 3.6 and my 5.x updates will just collect dust. > > Jeff Ok, this is a flame (kind of). I don't like the idea that I chose to ``have to conform to ANSI''. What do you mean ``having to conform to ANSI'' ? ANSI is NOT something you have to conform to. It just means you CAN do stricter type-checking. You don't usually have to. The SAS/C compiler mostly returns warnings if you indulge in type-punning, you can ignore them if you want, you can even turn them off. On the other hand, you get the benefit of having prototypes, which means you don't HAVE to use dumb castings the like of sqrt((double)2) or (worse) float x = 2.57; y = sin((double)x); You don't spend hours on stupid bugs because the compiler tells you when you have done things wrong (when you INTEND to do things the wrong way, you still CAN, but you'll get warned)---and don't tell me you don't indulge in stupid bugs from time to time. Spare us the macho part about ``real programmers don't need prototypes. Or I've got the right to be non-conformist.'' Did it ever occur to you that everybody (UNIX too) is switching to ANSI C ? There might be a good reason to that... Doesn't it bother you that your source code will soon be a fossile, and is much less portable than ANSI-like C right now ? BTW, SAS/C supports 16 bit integers, as well as several models of floating point. And there is something ANSI provides which traditional C has not: if you use only single precision floating point variables, computations will get done in single precision, instead of converting everything to double first; the old traditional C efficiency-loophole. You want to make us ANSI-C programmers feel like we wear a straightjacket. This is wrong. ANSI-C means freedom. Traditional C means a high dependency on the machine you use. Granted, you can get rid of such dependencies, but in that case you don't need the dubious ``benefits'' of ANSI-C. -- Marc Espie (espie@flamingo.stanford.edu)
jdickson@jato.jpl.nasa.gov (Jeff Dickson) (02/08/91)
In article <1991Feb7.220346.29943@Neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >In article <1991Feb7.192644.25098@jato.jpl.nasa.gov> jdickson@jato.Jpl.Nasa.Gov (Jeff Dickson) writes: >>In article <4034@orbit.cts.com> chucks@pnet51.orb.mn.org (Erik Funkenbusch) writes: >>> >>>manes@vger.nsu.edu ((Mark D. Manes) writes: >>>>I recently purchased SAS/C and kissed goodbye the MANX C compiler that >>>>I have used for years. >>> >>>I'm interested in why you switched to SAS. I have been using Manx for years >>>as well, and i get nausea when i try and use SAS. I was just wondering about >>>your reasons. >>>> >[sigs deleted] >> >> YEAH! RIGHT ON. I use MANX too. I have ever since 1985. I don't >>like having to conform to ANSI. Unfortunatly, MANX rid 16 bit ints and >>adopted the ANSI way of doing things. Wish they could release a new version >>in the spirit of 3.6 for us non comformists. Until then, I'm going to continue >>using 3.6 and my 5.x updates will just collect dust. >> >> Jeff > >Ok, this is a flame (kind of). I don't like the idea that I chose to >``have to conform to ANSI''. >What do you mean ``having to conform to ANSI'' ? Ok. You did not choose ANSI (at least not all of you). SAS offered ANSI 'C' before MANX did. That was fine. Those who wanted strictor type checking chose SAS, those who didn't stuck with/chose MANX. Then for some strange reason, almost like ANSI compatibility had been proclaimed thee thing, MANX decides to pull the rug out from under its many faithful users. Sure, MANX has some kind of compatability command line switch that is "supposed" to emulate their 3.6 - but it doesn't. I apologise, because now-a-days new 'C' compiler buyers don't have a choice. I'm just mad, because I liked the way it isn't anymore. >ANSI is NOT something you >have to conform to. It just means you CAN do stricter type-checking. You >don't usually have to. The SAS/C compiler mostly returns warnings if >you indulge in type-punning, you can ignore them if you want, you can >even turn them off. On the other hand, you get the benefit of having >prototypes, which means you don't HAVE to use dumb castings the like of >sqrt((double)2) or (worse) float x = 2.57; y = sin((double)x); >You don't spend hours on stupid bugs because the compiler tells you when >you have done things wrong (when you INTEND to do things the wrong way, >you still CAN, but you'll get warned)---and don't tell me you don't indulge >in stupid bugs from time to time. >Spare us the macho part about ``real programmers don't need prototypes. Or >I've got the right to be non-conformist.'' >Did it ever occur to you that everybody (UNIX too) is switching to ANSI C ? >There might be a good reason to that... Doesn't it bother you that your >source code will soon be a fossile, and is much less portable than ANSI-like >C right now ? Portable to what? Really doubt that portability is an issue with Amiga specific source code. > >BTW, SAS/C supports 16 bit integers, as well as several models of floating >point. And there is something ANSI provides which traditional C has not: >if you use only single precision floating point variables, computations >will get done in single precision, instead of converting everything to >double first; the old traditional C efficiency-loophole. > Yeah, that's good. >You want to make us ANSI-C programmers feel like we wear a straightjacket. >This is wrong. ANSI-C means freedom. Traditional C means a high dependency >on the machine you use. Granted, you can get rid of such dependencies, >but in that case you don't need the dubious ``benefits'' of ANSI-C. >-- > Marc Espie (espie@flamingo.stanford.edu) "BENEFIT" is in the eye of the beholder. Jeff
dave@unislc.uucp (Dave Martin) (02/13/91)
From article <1991Feb7.192644.25098@jato.jpl.nasa.gov>, by jdickson@jato.jpl.nasa.gov (Jeff Dickson): > > like having to conform to ANSI. Unfortunatly, MANX rid 16 bit ints and > adopted the ANSI way of doing things. Wish they could release a new version > > Jeff Doesn't Manx provide flags to control this stuff? SAS provides flags to control level (if any) of ANSI conformance desired, and whether you want int to be 16 or 32 bits. -- VAX Headroom Speaking for myself only... blah blah blahblah blah... Internet: DMARTIN@CC.WEBER.EDU dave@saltlcy-unisys.army.mil uucp: dave@unislc.uucp or use the Path: line. Now was that civilized? No, clearly not. Fun, but in no sense civilized.
rshaw@theborg.mlb.fl.us (Ron) (02/14/91)
manx did not get rid of 16 bit ints, the just changed the default to 32 bit
ints. you can set 16 bit ints with one of their numerous flags. of course 5.0d
is riddled with bugs. but a fix/update is due any day (per Manx staff)
Ron Shaw..... The only good 8 bit computer is a
Dead 8 bit compter....
-----------------------------Mathematics is a state of mind,
Electronics is a state of being.