steven@cwi.nl (Steven Pemberton) (06/09/88)
In article <1904@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: > i guess i'll stick with good 'ol alcyon (maybe slow but it works...) Ha! After months of fighting the buggy code produced by Alcyon, I threw the damned thing away and went over to MWC. I only wished I'd done it earlier, and saved all that trouble. The major problem with MWC is that there isn't an option to generate code to check for stack overflow (the suggestion in the manual to do it yourself is of course ridiculous), and I almost consider this as buggy code. It's absolutely infuriating to spend 2 days using the debugger, only to discover that you've overrun the stack. Does version 3 fix this, by the way? Steven Pemberton, CWI, Amsterdam; steven@cwi.nl
rosenkra@Alliant.COM (Bill Rosenkranz) (06/14/88)
-----
In article <360@piring.cwi.nl> steven@cwi.nl (or try mcvax!steven.uucp) writes:
->In article <1904@alliant.Alliant.COM> I wrote:
->> i guess i'll stick with good 'ol alcyon (maybe slow but it works...)
->
->Ha! After months of fighting the buggy code produced by Alcyon, I
->threw the damned thing away and went over to MWC. I only wished I'd
->done it earlier, and saved all that trouble.
->
well, what can i say...MWC was not around until about a year into my investment
of time,time,time. and when it did come out, it was probably worse (v1.x) and
lacked a lot of the things i needed anyway.
v2.x of MWC was better, but still not worth me throwing out (or trying to
convert) 30-40,000 lines of my own alcyon code as well as maybe another 60,000
lines of PD stuff that DOES work. i more or less like my current environment
which centers on alcyon.
your argument failed to include what could be your strongest argument: MWC
is evolving, alcyon is dead (though if ST sales wane, i doubt MWC will see
any more enhancements either :^).
i don't know what kind of stuff you write but at this point, i can easily
debug alcyon and have only found very few (and far between) actual bugs in the
compiler. it does have its limitations, mainly in the user interface area
(can't redir output, cp68 -I does not work like a unix compiler cpp would,
won't accept "/" in include files - does MWC do this? - etc). considering it
has been around for so long in basically it's original form, it is still a
good compiler. i wrote my own cc front end and have very few problems. the
library is very unix-like and those routines which did not work corectly i
replaced.
i often convert comp.sources.unix stuff to run under a gulam shell and find
that generally, the port requires ST-specific changes, not alcyon-specific
changes. i'm sure you can say the same for MWC.
there are a lot of us who still use alcyon, and like it. i will probably
buy MWC 3.x as well, once i get my personal libc makefile built :^). enjoy
your compiler but don't mislead everyone else.
adios...
-billhyc@math.lsa.umich.edu (Howard Chu) (06/15/88)
In article <1961@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) writes: %----- %In article <360@piring.cwi.nl> steven@cwi.nl (or try mcvax!steven.uucp) writes: %->In article <1904@alliant.Alliant.COM> I wrote: %->> i guess i'll stick with good 'ol alcyon (maybe slow but it works...) %-> %->Ha! After months of fighting the buggy code produced by Alcyon, I %->threw the damned thing away and went over to MWC. I only wished I'd %->done it earlier, and saved all that trouble. %-> % %well, what can i say...MWC was not around until about a year into my investment %of time,time,time. and when it did come out, it was probably worse (v1.x) and %lacked a lot of the things i needed anyway. Glad I missed that. I jumped into things with 2.0. % %v2.x of MWC was better, but still not worth me throwing out (or trying to %convert) 30-40,000 lines of my own alcyon code as well as maybe another 60,000 %lines of PD stuff that DOES work. i more or less like my current environment %which centers on alcyon. I dunno, looking at code written for alcyon reminded me too much of looking at something written for a bad C compiler I remember from MSDOS days. Yeah, that's it, it reminded me of Microsoft Fortran-77 and such. Manually invoked compile & link phases, weird command line switches to the linker, etc. Bleah. % %your argument failed to include what could be your strongest argument: MWC %is evolving, alcyon is dead (though if ST sales wane, i doubt MWC will see %any more enhancements either :^). Well, here's hoping that things continue to improve. Now that I've got the 3.0 compiler, I'm thinking about porting Gnu's GCC anyway though, so mebbe it won't matter... % %i don't know what kind of stuff you write but at this point, i can easily %debug alcyon and have only found very few (and far between) actual bugs in the %compiler. it does have its limitations, mainly in the user interface area %(can't redir output, cp68 -I does not work like a unix compiler cpp would, %won't accept "/" in include files - does MWC do this? - etc). considering it %has been around for so long in basically it's original form, it is still a %good compiler. i wrote my own cc front end and have very few problems. the %library is very unix-like and those routines which did not work corectly i %replaced. Yeah, include files were always a pain. I seem to recall that the '/' didn't get recognized. I always had to #ifdef 'em to something else... % %i often convert comp.sources.unix stuff to run under a gulam shell and find %that generally, the port requires ST-specific changes, not alcyon-specific %changes. i'm sure you can say the same for MWC. I've got Gulam, but I'm already too used to MWC's msh to switch over. Mebbe I'll wise up. (msh's attempt at a history mechanism is poor, at best.) I get a lot of Unix code running on my ST as well. Ported Larn 12.0 using MWC 2.0. (Has anyone ported compress yet? I started, since I just finished with ARC, but haven't gotten it working yet.) On the whole, the Mark Williams libraries have been pretty good at emulating Unix. % %there are a lot of us who still use alcyon, and like it. i will probably %buy MWC 3.x as well, once i get my personal libc makefile built :^). enjoy %your compiler but don't mislead everyone else. Oh yeah - you can also get the source for Mark Williams' libraries for a fee. I haven't yet, but plan to. Ah well. From the glimpse I got at alcyon via the UUPC sources, (which I tried vainly to fit into the MWC scheme of things on my system for a couple days...), I'm pretty sure I wouldn't like the system, and I *do* like MWC. I s'pose ya have to say "to each his own," but it'd be nice if there was a standard. It'd make the sources newsgroup a little more useful, f'r'instance.... -- / /_ , ,_. Howard Chu / /(_/(__ University of Michigan / Computing Center College of LS&A ' Unix Project Information Systems
steven@cwi.nl (Steven Pemberton) (06/15/88)
In article <1904@alliant.Alliant.COM> rosenkra@alliant.UUCP (Bill Rosenkranz) wrote: > i guess i'll stick with good 'ol alcyon (maybe slow but it works...) to which I replied > Ha! After months of fighting the buggy code produced by Alcyon, I > threw the damned thing away and went over to MWC. I only wished I'd > done it earlier, and saved all that trouble. to which he replied > there are a lot of us who still use alcyon, and like it. i will probably > buy MWC 3.x as well, once i get my personal libc makefile built :^). enjoy > your compiler but don't mislead everyone else. I'm not trying to mislead anyone. Quite the contrary in fact. You claimed that Alcyon worked, and I pointed out the the reason that I stopped using it was because it *didn't* work. I don't have Alcyon online anymore, so I can't go and try and recreate the problems it produced, but I do remember, as an example, that it was completely unable to cope with an initialised array declaration with nested {}'s that I had. But still, I don't want to stop you from using it. I just wanted to point out that for the programs I was compiling, it was essentially useless. Steven Pemberton, CWI, Amsterdam; steven@cwi.nl
rosenkra@Alliant.COM (Bill Rosenkranz) (06/17/88)
--- mislead was perhaps a bad choice of words. it's just that i can't see anyone having the total omniscience to say that "this is bad" (and imply "don't use it", kinda like the amiga/atari wars...). i agree that alcyon has problems. so does MWC. the bottom line is find something that works for you and use it. for me, at this point in time, alcyon is it. next year, probably MPW :^). casual programmers will buy one compiler and live with it. people doing this for a living will try them all (or as many as they can) and pick the optimal for them (features, speed, size, etc). no folowups, please...this particular issue is dead (not compilers, just THIS issue). adios -bill
sreeb@pnet01.cts.com (Ed Beers) (06/19/88)
While Alcyon seems to work ( I got it with my developers kit in addition to
MWC ), it lacks a source level debugger. I couldn't live without Csd now.
Csd seems to work very well. The only bug I have encountered is that integers
are displayed as if they were unsigned integers. It has cut my debugging time
in half.
UUCP: {cbosgd hplabs!hp-sdd sdcsvax nosc}!crash!pnet01!sreeb
ARPA: crash!pnet01!sreeb@nosc.mil
INET: sreeb@pnet01.cts.comThomas_E_Zerucha@cup.portal.com (06/23/88)
I don't li
I don't like CSD. They have a difficult setup for keys, you need to hit
several to do anything. It also replots the entire screen (fast, but it
still flashes irritatingly) each time you do anything. On my PC, and even
under PC Ditto, I have used Power C's C-Trace. For some silly reason, they
chose things like insert to set breakpoints and watchpoints, spacebar to
single step, and return to exectute in trace mode instead of some obscure
set of function keys. And it highlights successive lines until it actually
goes off screen and can handle graphics.
I also can't see the assembly instructions, so I had to also use db
separately to trace a problem - I can't see the low level in CSD. It also
crashed (db too!) when I ran a problem program. I don't think they did a
bad technical job with CSD - just a bad ergonomic job. I hope they fix it,
because otherwise it is a good debugger. The ST's function keys just aren't
the best to overload with functions, and I need both db and csd's functions
in one debugger.\jsp@sp7040.UUCP (John Peters) (06/25/88)
In article <3130@crash.cts.com>, sreeb@pnet01.cts.com (Ed Beers) writes: > While Alcyon seems to work ( I got it with my developers kit in addition to > MWC ), it lacks a source level debugger. I couldn't live without Csd now. > Csd seems to work very well. The only bug I have encountered is that integers > are displayed as if they were unsigned integers. It has cut my debugging time > in half. > I have to agree with this comment. Alcyon worked (with some problems) so I tried MWC. The first version I fought often with. Version 2 I thought was a breeze to use. With the release of 3.0 and CSD, all I can say is WOW!!! I found bugs in the first day I had been looking at for weeks. I did find one thing I think is a bug though, #line preprocessor statements confuse it. As for some of the others, I tried Lattic (Slow as snails) and anything that requires overlays on a 68000 system can forget it. A lot of the others I have not tried because either they were not around when I was looking or there were horror stories about there use. -- Johnnie --
kbad@atari.UUCP (Ken Badertscher) (06/28/88)
in article <359@clio.math.lsa.umich.edu>, hyc@math.lsa.umich.edu (Howard Chu) says: > (Has anyone ported compress yet? I started, since I just finished with ARC, > but haven't gotten it working yet.) Yup, there's an ST version of compress available (I got it off BIX, but from a non-public area). If there is interest, I'll post it to binaries. -- Ken Badertscher | Hey, umm, the stuff I said up there Atari R&D Software Test/Support | is, like, what _I_ think, okay? {portal,ames,imagen}!atari!kbad | So, y'know, don't bug Atari about it.