L30CC@CUNYVM.CUNY.EDU (12/16/88)
Hello all, can someone please recommend a good Modula-2 compiler for the Amiga? I need it for an upcoming Pascal data structures class. Am I correct in assuming that Modula-2 is a super-set of Pascal and that standard Pascal source will compile under a Modula-2 compiler w/o any modifications? - krb - #! rnews
rsilvers@hawk.ulowell.edu (Robert Silvers) (12/18/88)
In article <1801L30CC@CUNYVM> L30CC@CUNYVM.CUNY.EDU writes: >Hello all, can someone please recommend a good Modula-2 compiler for the >Amiga? I need it for an upcoming Pascal data structures class. Am I correct >in assuming that Modula-2 is a super-set of Pascal and that standard Pascal >source will compile under a Modula-2 compiler w/o any modifications? >- krb - Pascal code will not compile directly with a Modula-2 compiler. They have different calls for I/O etc. Modula-2 has no built in I/O routines. They have to be explicidly imported from an I/O module. Modula-2 also handles begin/ends differently, etc. The differences are simple enough so that it can be easily ported if you understand both languages, but it will not just compile and run. As far as which compiler, BenchMark it probably the best. My friend bought TDI. This was last year, so it may be better now, but it was very buggy. It saved its error messages to a special file, not to the screen. This allowed the editor to jump to the errors like Turbo Pascal. The only problem was that it Gurued very often. I deemed it unuseable. You could not even use Emacs with it if you wanted to see the errors. On the plus side, the code it generated was very fast. Almost identical to Aztec C. I personnaly would not spend almost $200.00 for a Modula-2 compiler, at least not for a single project. Do the project on another system if availiable, and if you want to learn a good language for the Amiga, spend your money on C. Hope this helps, --Rob. Robert Silvers. rsilvers@hawk.ulowell.edu Box #1003 University of Lowell. Lowell Ma, 01854 (508) 452-5000 ex 2233
dan-hankins@cup.portal.com (Daniel B Hankins) (12/19/88)
In article <1801L30CC@CUNYVM> L30CC@CUNYVM.CUNY.EDU (krb) writes: >Hello all, can someone please recommend a good Modula-2 compiler for the >Amiga? There are three available. Which one you choose should depend on what you like. I have TDI Modula-2. I think it is fine, when combined with a public-domain utility that gives simple error message formatting, instead of forcing you to use TDI's integrated editor. I like TDI because it is *NOT* an integrated package. It is more like a component system. I am free to use whatever editor I like, and glue it together with TDI M2 by means of ARexx (if I ever get around to getting ARexx). I can't really speak for the others, but there was a recent issue of AmigaWorld that reviewed all three. >Am I correct in assuming that Modula-2 is a super-set of Pascal and that >standard Pascal source will compile under a Modula-2 compiler w/o any >modifications? 'Fraid not. However, the conversion should not be difficult. A good book with which to learn Modula-2 is "Modula-2 Wizard: A Programmer's Reference" by Richard S. Wiener. It is published by John Wiley and Sons. The syntax is somewhat different; more sensible. The standard libraries have to be imported. They are not part of the language definition. Things like Readln, Writeln, and so on have been moved into standard libraries (with name changes). Also, the language is case-sensitive and all reserved words must be in upper case. So there are some differences. Dan Hankins
richard@gryphon.COM (Richard Sexton) (12/19/88)
In article <1801L30CC@CUNYVM> L30CC@CUNYVM.CUNY.EDU writes: > >Hello all, can someone please recommend a good Modula-2 compiler for the >Amiga? I need it for an upcoming Pascal data structures class. Am I correct >in assuming that Modula-2 is a super-set of Pascal and that standard Pascal >source will compile under a Modula-2 compiler w/o any modifications? Get youself a copy of Aztec C, and relabel it as Modula-2. You'll be much happier. -- ``Wake me up when it's time to go to sleep'' richard@gryphon.COM {b'bone}!gryphon!richard gryphon!richard@elroy.jpl.nasa.gov
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/23/88)
In <12749@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes: > There are three available. Which one you choose should depend on what you > like. > > I have TDI Modula-2. I think it is fine, when combined with a > public-domain utility that gives simple error message formatting, instead > of forcing you to use TDI's integrated editor. > > I like TDI because it is *NOT* an integrated package. It is more like a > component system. I am free to use whatever editor I like, and glue it > together with TDI M2 by means of ARexx (if I ever get around to getting > ARexx). Benchmark modula-2 also allows you to use the editor of your choice. It is by no means tied to the integrated editor. As a matter of fact, my biggest complaint was with the editor, which is a MicroEmacs clone. My usual way of using it was to edit with CED (prior to CEDPro),, and to switch back to the benchmark editor for compile/error correction/link/run cycle. Any major editing was always with CED. It can also be run from the CLI. > I can't really speak for the others, but there was a recent issue of > AmigaWorld that reviewed all three. I can't speak for the latest version of the TDI product, because I got thoroughly disgusted with the first package and the first upgrade (which cost an additional $50, just to get a whole new set of bugs). I can, however, speak for Benchmark. Benchmark is in most respects, a great package, with few exceptions. The exceptions are the editor (not a big deal, but it would have been nice if Leon had documented the interface so we could integrate another editor into the package), and the few 'not quite M2' things. The other thing that has been keeping me from recommending Benchmark is that Avante-Garde and Oxxi were embroiled in a bitter battle over rights to the package. One result of this was that the early buyers, who bought beta versions (beta, he says, thinking that there were probably less bugs in the alpha Benchmark than in the latest from TDI), on the promise of receiving a full release version when the product came to market, were being left out in the cold, with no explanation from the author. my feeling was that if he could abandon those that supported him, that he was not to be trusted to support anyone else who bought the product. I am happy to report that this situation has drastically changed, and that Avante-Garde has mailed out letters to beta buyers that contain details on how to obtain the upgrade they are entitled to., so my major objection to Benchmark is gone, and I feel I can recommend it highly. Just to further confound the issue, TDI is no longer the North American distributor of the compiler from M2S (the original authors of the TDI product). M2S will be releasing an all new, single pass compiler, based on the ETH compiler (as are M2Amiga and Benchmark), and will be sending letters to all registered TDI owners advising them of the upgrade offer. The new product will be called M2Sprint, and sounds like a winner. It will come with full source for the libraries. -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
loyd@nth.UUCP (Loyd Blankenship) (12/25/88)
I spent 6 months trying to do something useful with TDI's compiler, and I
will unequivicobly give it my Worst-Product-Of-All-Time award.
1) The editor eats 50K of RAM every time it is invoked. The only way to
recover the RAM is rebooting.
2) The editor sometimes finds errors, and sometimes doesn't. Completely
random in functionality.
3) The example code given (the BOX code specifically) does not compile. De-
bugging is left as an excercise to the purchaser.
4) In the definition files, several variables and types are defined wrong.
It's been long enough that I don't remember specific examples.
5) The documentation is the worst collection of vauge and misleading statements
it's ever been my misfortune to wade through.
6) The index is wrong about 25% of the time.
7) Customer support is non-existant. When you call on the phone (I tried both
the UK & the US phone #'s), the person who knows anything about it is
'not available', and not *once* in over 20 attempts did anyone ever
return my call.
I was using the expensive 'Professional' version of the thing, too!
I finally just bit the bullet, considered it $225 down the tube, and
bought the Lattice C Professional kit. I am so much happier with it I am
like a new man! I don't know anything about Benchmark Modula-2, and wasn't
willing to risk another couple hundred dollars on an unknown product. Lattice
is a fantastic product, they have good customer support, and if you aren't
dead set to work in Modula-2, I'd recommend you go with Lattice.
Loyd Blankenship cs.utexas.edu!nth!loyd (UUCP)
Nth Graphics Ltd. Austin, TX 78758 w: 512-832-1944
h: 512-441-2916
Disc: It's my opinion, not theirs...loyd@nth.UUCP (Loyd Blankenship) (12/27/88)
In article <13030@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes: >In article <403@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes a >scathing criticism of TDI's compiler. > > Personally, I don't think that it's that bad. I've successfully >written a modestly sized program in it without too many problems. I'm now >in the process of writing an interpreter for an object-oriented language in >it (not a small project). Here's some answers to his points: > >>1) The editor eats 50K of RAM every time it is invoked. The only way to >> recover the RAM is rebooting. > > Their editor is lousy anyway. Don't use it. MG or DME or just about >any other editor is superior. MG in particular has the capability to be >customized to be syntax-sensitive. > >>2) The editor sometimes finds errors, and sometimes doesn't. Completely >> random in functionality. > > Again, don't use TDI's editor. Use the public domain program m2error >(available on Fish) which will invariably give the correct error code and >location. Hmmmmm. So if I buy a car and the engine doesn't work, your suggestion to stop whining about the crappy engine that came with the car and put in a *real* engine, right? >>3) The example code given (the BOX code specifically) does not compile. >> Debugging is left as an excercise to the purchaser. > > I won't argue with you here. I don't know, myself. In my book, >compiling example code is usually a waste of time, unless it does something >in particular that you need. But Dan, if you provide someone with example code that won't compile, that probably means that there's an error in it somewhere (or an error in the compiler- 50/50 either way with TDI.) What's the bleedin' point of providing non-working example code? "Here's some code that kinda might work, we aren't sure, but take a look at it, and if you fix it up, let us know." >>4) In the definition files, several variables and types are defined wrong. >> It's been long enough that I don't remember specific examples. > > Again, no argument. I haven't personally encountered any of these. >Is this in the documentation, or on the files actually provided on the >disks? I haven't yet encountered any errors in the files provided on the >disks. If the definition file is wrong, well then I would just use DecSym >to generate one from the .sym file. Haven't had a need to try that yet, so >it may not work. The errors were in the documentation. The fact that I could recreate my own version of the documentation in no way obviates TDI from putting correct information in the original. >>5) The documentation is the worst collection of vauge and misleading >> statements it's ever been my misfortune to wade through. > > I must have backlevel documentation. Mine is fairly short, clear, and >concise. You must. >>6) The index is wrong about 25% of the time. > > You mean you don't grep the .def files on the distribution disks? No Dan, I don't. Y'see, I have this little quirk about using a manual to look something up occasionally, so I expect the index to tell me where to look. See #4 above. >>7) Customer support is non-existent. When you call on the phone (I tried >> both the UK & the US phone #'s), the person who knows anything about it >> is 'not available', and not *once* in over 20 attempts did anyone ever >> return my call. > > I haven't needed this yet, so I wouldn't know. I get most of my >support from other users, when necessary. > >Dan Hankins Oh good. How fortunate for the other users. Dan, why are you making excuses for these weasels? I'm complaining about an obviously inferior product, and you sit and give me ways to work around TDI fuckups. The point is, I *SHOULDN'T* have to use another editor, and I *SHOULDN'T* have to rebuild my own documentation because they were to {lazy| careless|stupid} to do it correctly. And I certainly shouldn't have to rely on other users to support a product! With Lattice, I could actually *USE* the editor that came with the package, and the documentation was correct and reflected the contents of the manuals! Wow! What a concept! Plus every question I've ever had was cheerfully and quickly answered by placing one phone call. And yes, Lattice does return calls when they say they will. Loyd Blankenship cs.utexas.edu!nth!loyd (UUCP) Nth Graphics Ltd Austin, TX 78758 Disclaimer: These Opinions are Mine. Mine, you hear me? Leave them alone!
dan-hankins@cup.portal.com (Daniel B Hankins) (12/29/88)
In article <403@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes a scathing criticism of TDI's compiler. Personally, I don't think that it's that bad. I've successfully written a modestly sized program in it without too many problems. I'm now in the process of writing an interpreter for an object-oriented language in it (not a small project). Here's some answers to his points: >1) The editor eats 50K of RAM every time it is invoked. The only way to > recover the RAM is rebooting. Their editor is lousy anyway. Don't use it. MG or DME or just about any other editor is superior. MG in particular has the capability to be customized to be syntax-sensitive. >2) The editor sometimes finds errors, and sometimes doesn't. Completely > random in functionality. Again, don't use TDI's editor. Use the public domain program m2error (available on Fish) which will invariably give the correct error code and location. >3) The example code given (the BOX code specifically) does not compile. > Debugging is left as an excercise to the purchaser. I won't argue with you here. I don't know, myself. In my book, compiling example code is usually a waste of time, unless it does something in particular that you need. >4) In the definition files, several variables and types are defined wrong. > It's been long enough that I don't remember specific examples. Again, no argument. I haven't personally encountered any of these. Is this in the documentation, or on the files actually provided on the disks? I haven't yet encountered any errors in the files provided on the disks. If the definition file is wrong, well then I would just use DecSym to generate one from the .sym file. Haven't had a need to try that yet, so it may not work. >5) The documentation is the worst collection of vauge and misleading > statements it's ever been my misfortune to wade through. I must have backlevel documentation. Mine is fairly short, clear, and concise. >6) The index is wrong about 25% of the time. You mean you don't grep the .def files on the distribution disks? >7) Customer support is non-existant. When you call on the phone (I tried > both the UK & the US phone #'s), the person who knows anything about it > is 'not available', and not *once* in over 20 attempts did anyone ever > return my call. I haven't needed this yet, so I wouldn't know. I get most of my support from other users, when necessary. Dan Hankins
lphillips@lpami.wimsey.bc.ca (Larry Phillips) (12/31/88)
In <13030@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes: >In article <403@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes a >scathing criticism of TDI's compiler. And rightly so. > Personally, I don't think that it's that bad. I've successfully >written a modestly sized program in it without too many problems. I'm now >in the process of writing an interpreter for an object-oriented language in >it (not a small project). Here's some answers to his points: How accomplished a Modula-2 programmer are you? It really does make a big difference. For someone who is not in the 'expert' category, fighting a compiler in addition to trying to write code can be an almost herculean task. >>1) The editor eats 50K of RAM every time it is invoked. The only way to >> recover the RAM is rebooting. > > Their editor is lousy anyway. Don't use it. MG or DME or just about >any other editor is superior. MG in particular has the capability to be >customized to be syntax-sensitive. The editor, lousy as it is, is part of the package, advertised as a 'feature', and paid for by the buyer as much as is the compiler itself. To say it is lousy anyway and not to use it is ridiculous. Perhaps the user likes the editor in spite of the bugs and wants to use what he has paid for. To recommend another editor that he may not have or may not like, and may or may not have the skills and/or inclination to 'customize to be syntax sensitive' is to ignore the fact that he does not have something he paid for and expected to be in good working order. The real kicker to the editor issue is that TDI's answer to criticism of their non-functional piece of garbage was "You can buy the source from us and fix it." With attitudes like this, it's a wonder the criticism was only 'scathing'. >>2) The editor sometimes finds errors, and sometimes doesn't. Completely >> random in functionality. > > Again, don't use TDI's editor. Use the public domain program m2error >(available on Fish) which will invariably give the correct error code and >location. Sure. Well, that's two programs that you paid for that are unusable. Sounds like a great way to market software. Buy the package and then scrounge around finding programs that work. >>3) The example code given (the BOX code specifically) does not compile. >> Debugging is left as an excercise to the purchaser. > > I won't argue with you here. I don't know, myself. In my book, >compiling example code is usually a waste of time, unless it does something >in particular that you need. It obviously wasn't a waste of time to the one criticising the product, or he would not have bothered to mention it. Again, it rather depends on your level of expertise, no? >>4) In the definition files, several variables and types are defined wrong. >> It's been long enough that I don't remember specific examples. > > Again, no argument. I haven't personally encountered any of these. >Is this in the documentation, or on the files actually provided on the >disks? I haven't yet encountered any errors in the files provided on the >disks. If the definition file is wrong, well then I would just use DecSym >to generate one from the .sym file. Haven't had a need to try that yet, so >it may not work. I wonder... was DSM written in Modula-2 ? If so, it might help to explain why you haven't run across any problems in the dissk based or the book based .DEFs (yes, there are errors in both places). Not everyone sticks with plain vanilla IO, with no Amiga specific Intuition or graphics stuff. >>5) The documentation is the worst collection of vauge and misleading >> statements it's ever been my misfortune to wade through. > > I must have backlevel documentation. Mine is fairly short, clear, and >concise. And how much do you read between the lines, applying your past knowledge of the Modula-2 environment and idiom. Note that I am not saying that the manual should teach you how to program in Modula-2, but it should tell you how to go about compiling and linking in a clear manner. I'm afraid I have to agree with the critic on this one. >>6) The index is wrong about 25% of the time. > > You mean you don't grep the .def files on the distribution disks? Does he even have grep? Come on Dan, he paid for a manual as well, and got a slipshod piece of garbage that might be satisfactory for someone who doesn't need it. >>7) Customer support is non-existant. When you call on the phone (I tried >> both the UK & the US phone #'s), the person who knows anything about it >> is 'not available', and not *once* in over 20 attempts did anyone ever >> return my call. > > I haven't needed this yet, so I wouldn't know. I get most of my >support from other users, when necessary. How very nice for you that you are advanced enough to not need the support. How very nice that you have easy access to people who are wiling to help you around the pathetic quality of this package. Don't make the assumption that all users are as knowledgeable as you, or that they have the same access to help. It's attitudes like yours that will ensure the continuing production of garbage at high prices, under the guise of tools for the Amiga. The one good note about all this is that the people that actually wrote the compiler have recognized at least part of the problem, and TDI is no longer their North American representative. M2S will be coming out with a new single pass compiler called 'M2Sprint' early in the new year. Whether it is any good at all remains to be seen. At least we won't have to deal with the cretins at TDI any more. >Dan Hankins -larry -- "Intelligent CPU? I thought you said Intel CPU!" -Anonymous IBM designer- +----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +----------------------------------------------------------------------+
dan-hankins@cup.portal.com (Daniel B Hankins) (12/31/88)
In article <406@nth.UUCP> loyd@nth.UUCP (Loyd Blankenship) writes: > Hmmmmm. So if I buy a car and the engine doesn't work, your >suggestion (is) to stop whining about the crappy engine that came with the >car and put in a *real* engine, right? 1. I would hardly call the editor the engine of the compiler package. More like the stereo, if you're going to use the car analogy. Many compiler packages don't come with an editor at all. 2. If you don't like the crappy car stereo that came with the car, why then yes you *do* pull it out and replace it with a Blaupunkt or Alpine. > But Dan, if you provide someone with example code that won't compile, >that probably means that there's an error in it somewhere (or an error in >the compiler- 50/50 either way with TDI). The compiler isn't quite that bad. You were using a bit of hyperbole, I assume. > What's the bleedin' point of providing non-working example code? >"Here's some code that kinda might work, we aren't sure, but take a look >at it, and if you fix it up, let us know." What's the point of providing example code at all? I don't see a need for it. > The errors were in the documentation. The fact that I could recreate >my own version of the documentation in no way obviates TDI from putting >correct information in the original. Of course not. I'm simply saying that it's not an impassable barrier. Your comments earlier about giving up gave the impression that it was. Were it an impassable barrier, I wouldn't have been able to write code with the package. >> You mean you don't grep the .def files on the distribution disks? > No Dan, I don't. Y'see, I have this little quirk about using a manual >to look something up occasionally, so I expect the index to tell me where >to look. See #4 above. Yes, I understand that your standards are higher than mine. I suppose that after a few years of dealing with IBM's software and documentation thereof, *anything* looks good. > Dan, why are you making excuses for these weasels? I'm complaining >about an obviously inferior product, and you sit and give me ways to work >around TDI f***ups. I'm not making excuses for TDI. I'm making constructive suggestions about how you can make effective use of the package instead of just whining about it. You have a problem. TDI can't or won't fix it. I will, to the best of my ability. I'm not defending them; I'm just attacking you. :-) I'll be the first to admit that TDI's product is imperfect; hell, it's pretty lousy. In fact, I just rediscovered my major gripe with it: the compiler itself won't work on files in RAM:. But it isn't unusable. I'd rather create a few work arounds than spend $400 or whatever to go back to a language I really dislike (C, that is). Or even to spend $200 to move to a different Modula-2 compiler. >The point is, I *SHOULDN'T* have to use another editor, and I *SHOULDN'T* >have to rebuild my own documentation because they were too {lazy| >careless|stupid} to do it correctly. And I certainly shouldn't have to >rely on other users to support a product! No, of course you shouldn't. TDI's product certainly leaves something to be desired in areas that seem to matter to you and to some other people. But since you paid $200 for it, you might as well get *some* use out of it. If I can, you can. There are lots of things in life that one shouldn't have to do, yet you do have to anyway. Like lock your house to keep things from being stolen. Dan Hankins
peter@sugar.uu.net (Peter da Silva) (01/01/89)
In article <13074@cup.portal.com>, dan-hankins@cup.portal.com (Daniel B Hankins) writes: > 2. If you don't like the crappy car stereo that came with the car, why then > yes you *do* pull it out and replace it with a Blaupunkt or Alpine. But if you don't like the stereo, you tell the dealer "take this crappy stereo out or order me a car without one". Stereos are usually an option. So, what can you get off the TDI package if you don't buy the editor, examples, and manual options? -- Peter "Have you hugged your wolf today" da Silva `-_-' Hackercorp. ...texbell!sugar!peter, or peter@sugar.uu.net 'U`