kuch@reed.edu (04/09/91)
I'm a Manx owner who recently received the 5.0d upgrade. In light of the major and crippling bugs in 5.0a and 5.0b, I have some apprehension about getting started with it. Does anyone out there have any experiences to report? I'm also wondering if Manx has been left behind in the functionality race. Can any users out there give me a run through of the highs and lows of each package as they see them? I have no experience with any Lattice release later than 3.0 and would like to hear what's up. If it sounds favorable, I may end up making the jump to SAS. Comparisons/contrasts and feature summaries for SAS especially will be helpful. By the way, did anyone notice that the Manx ad on the inside front cover of the first issue of the AW Tech Journal mentioned version 5.2?!?! Is this something they really plan to get out soon, or were they hoping that the Journal would be another six months in appearing? Thanks a lot. Jerry
shields@yunexus.YorkU.CA (Paul Shields) (04/13/91)
kuch@reed.edu writes: >I'm a Manx owner who recently received the 5.0d upgrade. In light of the major >and crippling bugs in 5.0a and 5.0b, I have some apprehension about getting >started with it. Does anyone out there have any experiences to report? Sure, I've been using 5.0d for the past 4 or 5 months on a full-time project, so I've had lots of time with it. It works quite well for me. Here are the problems I have encountered: 1) There are a couple annoying problems with sdb, all of which have fairly easy workarounds... - If you quit before single-stepping at least one instruction, sdb may hang. - If you resize sdb's window before it is finished loading your program, you sometimes crash. - If you distribute source modules throughout several directories, realize that sdb will only look in the current directory for source modules. I found this really annoying because I put source in various places to help manage complexity. 2) If you use any floating point math functions, you'd better make sure you put the -lm option before the -lc option on the link command. The documentation says that the non-math printf library will print "f" or "g" when you try to print floats, but my actually it silently fails. 3) When linking with more than 64K of initialized data, the linker complains and there seems to be no way to get it to work without placing the data in the code segment. I am uncertain whether that is satisfactory, but it works. 4) The optimizer is really inadequate. This is why I'm about to take the plunge and try using gcc to optimize instead. >I'm also wondering if Manx has been left behind in the functionality race. >Can any users out there give me a run through of the highs and lows of each >package as they see them? I haven't used Lattice, but Manx appears to be fully ANSI compliant. (If any of you know better, do tell.) What functionality would be nice? I have used the Microsoft codeview debugger on PC's, and think it would be a "good thing" (tm) for the Manx debugger to watch variables, ie: to display the values of a list of variables at each single-step automatically. An execution profiler would be nice. It's time for me to start tweaking the speed of my code up.. a profiler it would be _so_ helpful since the optimizer doesn't work well enough. -- Paul Shields
wally@pallas.athenanet.com (Wally Hartshorn) (04/15/91)
In article <m0jQ2YL-0003PWC@reed.edu> kuch@reed.bitnet (Jerry Kuch) writes: >first issue of the AW Tech Journal mentioned version 5.2?!?! Is this something >they really plan to get out soon... I called Manx about a week ago and was told that v5.2 would be shipping in 4-6 weeks. That would mean early- to mid-May. -- Wally Hartshorn (uunet!pallas!wally or wally@athenanet.com) President, Amiga Computer Enthusiasts of Springfield (ACES) Chronicler, Shire of Swordcliff, SCA Sysop, The Quest, F&SF BBS, Citadel-68K node US (217) 546-7608
stephen@cia.docs.uu.se (Stephen Cooper) (04/19/91)
22394@yunexu Sender: news@kuling.UUCP Distribution: world Lines: 61 In <22394@yunexus.YorkU.CA> shields@yunexus.YorkU.CA (Paul Shields) writes: >kuch@reed.edu writes: >>I'm a Manx owner who recently received the 5.0d upgrade. In light of the major >>and crippling bugs in 5.0a and 5.0b, I have some apprehension about getting >>started with it. Does anyone out there have any experiences to report? >Sure, I've been using 5.0d for the past 4 or 5 months on a full-time >project, so I've had lots of time with it. >It works quite well for me. Here are the problems I have encountered: >1) There are a couple annoying problems with sdb, all of which have fairly >easy workarounds... [...lot's of bugs deleted -- don't you wish it were that easy...] Yet another bug in AztecC 5.0d: (YABIAC? :-) Compiling this: void DrawCurves (void) { SHORT xy[MAXPOINTS * 2]; struct Border BezierBorder = {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); return; } will give internal error #40, while compiling this: void DrawCurves (void) { SHORT xy[MAXPOINTS * 2]; struct Border BezierBorder = {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, NULL, NULL}; BezierBorder.XY = xy; get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); return; } is OK. What gives? I mean really -- Internal errors??? For that?!?! Another thing I dislike about Aztec C is sdb's refusal to read <alt> keys. I have an A1000 with a keymap I edited with KeyMapEd, so that I can have both Swedish characters and programming characters, like {[]}. SDB refuses to let me get at characters by pressing the <alt> key. Try printing a matrix without []! /Stephen stephen@jfk.docs.uu.se ---------------------------------------------------------------- All opinions are my own. ----------------------------------------------------------------
brett@visix.com (Brett Bourbin) (04/20/91)
In article <stephen.672004888@cia.docs.uu.se>, stephen@cia.docs.uu.se (Stephen Cooper) writes: > Yet another bug in AztecC 5.0d: (YABIAC? :-) > Compiling this: > > void > DrawCurves (void) > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; > > get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); > return; > } > > will give internal error #40, while compiling this: > > void > DrawCurves (void) > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, NULL, NULL}; > > BezierBorder.XY = xy; > get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); > return; > } > > is OK. What gives? I mean really -- Internal errors??? > For that?!?! Yes, for that. It looks like "xy" is declared in a procedure and is a local variable, which means it will be allocated when you call the routine, from the stack. Now, you then try to take the address of a item that will be on the stack. A no-no. You can either make the "xy" array "static" so it will not be on the stack, or you could pull it outside the DrawCurves() function and make it global (yech!). Hope this helps. > stephen@jfk.docs.uu.se -- __ Brett Bourbin \ / /(_ /\/ 11440 Commerce Park Drive ..!uunet!visix!brett \/ / __)/ /\ Reston, Virginia 22091 brett@visix.com Software Inc (703) 758-2733
milamber@caen.engin.umich.edu (Daryl Cantrell) (04/20/91)
In article <1991Apr19.193033.13587@visix.com> brett@visix.com writes: >In article <stephen.672004888@cia.docs.uu.se>, stephen@cia.docs.uu.se (Stephen Cooper) writes: >> Yet another bug in AztecC 5.0d: (YABIAC? :-) >> Compiling this: >> >> void >> DrawCurves (void) >> { >> SHORT xy[MAXPOINTS * 2]; >> struct Border BezierBorder = >> {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; [...] >Yes, for that. It looks like "xy" is declared in a procedure and is a local variable, >which means it will be allocated when you call the routine, from the stack. Now, you >then try to take the address of a item that will be on the stack. A no-no. You can >either make the "xy" array "static" so it will not be on the stack, or you could pull >it outside the DrawCurves() function and make it global (yech!). [...] Whoa, hold up there... Address-of is a perfectly legal operation on an auto- variable, it just isn't a valid initializer. Technically, the initializers for the Border structure must all be constants. In theory, since the struct- ure is reinitialized at every function entry, you could compute a new address for xy each time. BUT, it's not kosher C. I will say this: Manx should have pointed out the specific error, not "internal error". -- +---------------------------------------+----------------------------+ | // Daryl S. Cantrell | These opinions are | | |\\\ milamber@caen.engin.umich.edu | shared by all of // | | |// Evolution's over. We won. | Humanity. \X/ | +---------------------------------------+----------------------------+
dillon@overload.Berkeley.CA.US (Matthew Dillon) (04/22/91)
In article <1991Apr20.052047.18815@engin.umich.edu> milamber@caen.engin.umich.edu (Daryl Cantrell) writes: >In article <1991Apr19.193033.13587@visix.com> brett@visix.com writes: >>In article <stephen.672004888@cia.docs.uu.se>, stephen@cia.docs.uu.se (Stephen Cooper) writes: >>> Yet another bug in AztecC 5.0d: (YABIAC? :-) >>> Compiling this: >>> >>> void >>> DrawCurves (void) >>> { >>> SHORT xy[MAXPOINTS * 2]; >>> struct Border BezierBorder = >>> {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; >[...] Theoretically this is valid since BezierBorder is an auto, but the definition of ANSI C says that any auto-aggregate initialization (which is what you are doing) must contain only constants, as if it were a static initialization. So the &xy is illegal. -Matt > Whoa, hold up there... Address-of is a perfectly legal operation on an auto- >variable, it just isn't a valid initializer. Technically, the initializers It's a perfectly valid initializer but in the case of auto-aggregate initialization you can ONLY take the address of a static or global variable since that is, essentially, a constant. If 'xy' were declared static it would work. >for xy each time. BUT, it's not kosher C. I will say this: Manx should have >pointed out the specific error, not "internal error". no disagreement there. >+---------------------------------------+----------------------------+ >| // Daryl S. Cantrell | These opinions are | >| |\\\ milamber@caen.engin.umich.edu | shared by all of // | >| |// Evolution's over. We won. | Humanity. \X/ | >+---------------------------------------+----------------------------+ -Matt -- Matthew Dillon dillon@Overload.Berkeley.CA.US 891 Regal Rd. uunet.uu.net!overload!dillon Berkeley, Ca. 94708 USA
peter@sugar.hackercorp.com (Peter da Silva) (04/22/91)
In article <stephen.672004888@cia.docs.uu.se> stephen@cia.docs.uu.se (Stephen Cooper) writes: > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; I think this is an illegal auto aggregate initialization. I'm surprised it let you get away with it. I'm crossposting to comp.lang.c so the language lawyers can have at it. > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, NULL, NULL}; At least here the aggregate is a constant, that it can copy in. I'm still surprised it worked. I wouldn't code like that. Try making xy and BezierBorder static. -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
johnhlee@CS.Cornell.EDU (John H. Lee) (04/23/91)
In article <stephen.672004888@cia.docs.uu.se>, stephen@cia.docs.uu.se (Stephen Cooper) writes: > Yet another bug in AztecC 5.0d: (YABIAC? :-) > Compiling this: > > void > DrawCurves (void) > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, &xy, NULL}; ^^^ "&xy" used to be illegal (just use "xy",) but was recently legalized with ANSI C. Perhaps Manx hasn't quite finished ANSI'sizing its compiler yet? > > get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); > return; > } > > will give internal error #40, while compiling this: > > void > DrawCurves (void) > { > SHORT xy[MAXPOINTS * 2]; > struct Border BezierBorder = > {0, 0, 1, 0, COMPLEMENT, MAXPOINTS, NULL, NULL}; > > BezierBorder.XY = xy; ^^ Notice what you did here compared with above. > get_polypoints (DrawBezier, Bezier_Window, &BezierBorder); > return; > } > > is OK. What gives? I mean really -- Internal errors??? > For that?!?! Yup, you're right. There's a bug in the compiler. Perhaps the compiler wanted to report a warning (e.g., "& before array ignored") and the internal error occurs when the compiler tries to report it! ------------------------------------------------------------------------------- The DiskDoctor threatens the crew! Next time on AmigaDos: The Next Generation. John Lee Internet: johnhlee@cs.cornell.edu The above opinions of those of the user, and not of this machine.
jk@cs.man.ac.uk (John Kewley ICL) (04/23/91)
What is the derivation of the term Manx (apart from one who was born in
the Isle of Man)? Do the authors come from the Isle of Man?
--
J.K.
John M. Kewley, ICL, Wenlock Way, West Gorton, Manchester. M12 5DR
Tel: (+44) 61 223 1301 X2138 Email: jk@cs.man.ac.uk / jk@nw.stl.stc.co.uk