jsalter@slo.paloalto.ibm.com (08/18/90)
In article <1990Aug17.115057.3821@galadriel.bt.co.uk> andy@galadriel.bt.co.uk (Andy Howcroft) writes: >From article <1990Aug15.163448.16205@cs.utk.edu>, by battle@utkux1.utk.edu (David Lane Battle): >> Also, one of our primary reasons for wanting xterm on the RS/6000 was so >> we could use graph and plot to draw simple graphs in the tektronix window, >> but tektronix support seems to have been omitted from the aix version of >> plot(?) Does anyone have any suggestions about how to get around this problem? The "aixterm" command has tektronix emulation (undocumented) through the -t option. Whether the lack of documentation is intentional or not, I don't know. Warning: this feature may go away in future releases. >> -David L. Battle >> battle@utkux1.utk.edu >Yes...but you won't like it. Try launching the IBM junk out of the >nearest window and the buy a 'real' workstation. If you don't like it you're more than welcome to. However, it would be nice to know why you think it's "junk" instead of casually throwing out comments like that. Specifics, please. In terms of floating-point it's the hottest thing on the market, though thats more my area. And yes, I have my own opinions on the product. IBM doesn't control my mind. Just my paycheck. :-) >----------------------------------------------------------------------- >Andy Howcroft Email: andy@galadriel.bt.co.uk >British Telecom Research Labs Phone: +44 473 643653 jim/jsalter IBM AWD, Palo Alto T465/(415)855-4427 VNET: JSALTER at AUSVMQ Internet: ibmsupt!jsalter@uunet.uu.net UUCP: ..!uunet!ibmsupt!jsalter "Waco is a state of mind. Once you've gone there, you never come back" - Leo
moore@betelgeuse.cs.utk.edu (Keith Moore) (08/23/90)
In article <1990Aug17.191659.13510@ibmpa> jsalter@slo.UUCP (James Salter) writes: >In article <1990Aug17.115057.3821@galadriel.bt.co.uk> andy@galadriel.bt.co.uk (Andy Howcroft) writes: (in response to an article by David Battle) >>Yes...but you won't like it. Try launching the IBM junk out of the >>nearest window and the buy a 'real' workstation. > >If you don't like it you're more than welcome to. However, it would be >nice to know why you think it's "junk" instead of casually throwing out >comments like that. Specifics, please. In terms of floating-point it's >the hottest thing on the market, though thats more my area. The hardware, however fast, isn't worth a lot without a decent operating system and development tools. I'm sure that after spending a lot of time with a compiler, debugger, and the BSD UNIX source code, that I could replace enough of the system so that I could stand to use it. (The tty and pty drivers would be a good place to start.) No matter how fast the machine, it wouldn't save me the amount of time I would spend fixing things that are broken. Add to that the fact that many of our automated system administration procedures (of the form `make this change to every system of type X on the net') don't work with AIX, and you'll understand why we don't want very many of these machines around. And when we point out, for instance, that the C compiler is brain damaged because its error messages can't be parsed by emacs for file name and line number, IBM suggests extensive changes to emacs's message parsing code. But it's not emacs that's broken -- it's worked just fine for years with lots of other C compilers. It doesn't take too many responses like this to convince me that AIX is suffering from a severe lack of understanding of UNIX design philosophy, coupled with a bit of an attitude problem. My advice to everyone who has asked has been ``If all you need is a utility machine to crunch numbers, buy it. But don't mistake the RIOS for a UNIX workstation.'' Wait until someone (CMU?) ports Mach to this machine and makes it available, and see how many more machines you sell. Keith Moore Internet: moore@cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus Telephone: +1 615 974 0822 Knoxville Tennessee 37996-1301 ``Friends don't let friends use YP (or NIS)'' Keith Moore Internet: moore@cs.utk.edu University of Tenn. CS Dept. BITNET: moore@utkvx 107 Ayres Hall, UT Campus Telephone: +1 615 974 0822 Knoxville Tennessee 37996-1301 ``Friends don't let friends use YP (or NIS)''
gerard@Bull.NL (GerardJan Vinkesteyn) (08/23/90)
In article <1990Aug23.032925.23403@cs.utk.edu>, moore@betelgeuse.cs.utk.edu (Keith Moore) writes: > In article <1990Aug17.191659.13510@ibmpa> jsalter@slo.UUCP (James Salter) writes: > >In article <1990Aug17.115057.3821@galadriel.bt.co.uk> andy@galadriel.bt.co.uk (Andy Howcroft) writes: > (in response to an article by David Battle) > >>Yes...but you won't like it. Try launching the IBM junk out of the > >>nearest window and the buy a 'real' workstation. > > > >If you don't like it you're more than welcome to. However, it would be > >nice to know why you think it's "junk" instead of casually throwing out > >comments like that. Specifics, please. In terms of floating-point it's > >the hottest thing on the market, though thats more my area. > > The hardware, however fast, isn't worth a lot without a decent operating > system and development tools. > > And when we point out, for instance, that the C compiler is brain damaged > because its error messages can't be parsed by emacs for file name and line > number, IBM suggests extensive changes to emacs's message parsing code. > But it's not emacs that's broken -- it's worked just fine for years with > lots of other C compilers. It doesn't take too many responses like this > to convince me that AIX is suffering from a severe lack of understanding > of UNIX design philosophy, coupled with a bit of an attitude problem. > Thank you Keith, for your comments. I don't agree, however, with the above comments. More computer manufacturers deliver these kind of C compilers (not Bull by the way). It is a more user friendly, stricter syntax checking, compiler, especially for the novice user. Nothing can be against that. Harris uses the same scheme. Though my emacs is called jove (I only use Jove for better performance and less memory use) and it is easily adjustable via the error-format-string setting. You can shoot at IBM for their silly advertisements, still don't who that Gonzales guy is. But if they are good then they come up with a very decent Unix machine. Marketing it is another issue. Perhaps CMU comes up with a nice BSD environment, perhaps by that time BSD is outdated because of SVr4, however, that is a whole different discussion all to gether. :entry "error-format-string" "Variable" This is the error format string that is used by "parse-errors" to find the error messages in a buffer. The way it works is by using this string as a JOVE regular expression search string, where the \('s and \)'s regular expression operators are used to pick out the file name and line number from the line containing an error message. For instance, a typical error message might look like this: "file.c", line 540: missing semi-colon For strings of this format, an appropriate value for "error-format- string" would be something like this: ^"\([^"]*\)", line \([0-9]*\): What this means is, to find an error message, search for a line beginning with a double-quote. Then it says that all the following characters up to another double-quote should be remembered as one unit, namely the filename that the error is in (that's why the first set of parens are surrounding it). Then it says that after the filename there will be the string ", line " followed by a line number, which should be remembered as a single unit (which is why the second set of parens is around that). The only constraints on the error messages is that the file name and line number appear on the same line, and that the file name appears before the line number. Most compilers seem to do this anyway, so this is not an unreasonable restriction. If you do not know how to use regular expressions then this variable will be hard for you to use. Also note that you can look at the default value of this variable by printing it out, but it is a really complicated string because it is trying to accommodate the outputs of more than one compiler at a time. -- Gerard Jan Vinkesteyn Bull Netherlands Internet: gerard@bull.nl Hoogoorddreef 66-68 Uucp: nlbull!gerard 1101 BE Amsterdam # name change because of French Connection... s/gertjan/gerard/
mouse@SHAMASH.MCRCIM.MCGILL.EDU (der Mouse) (08/24/90)
>>>> ... IBM junk ... >>> [I]t would be nice to know why you think it's "junk" >> And when we point out, for instance, that the C compiler is brain >> damaged because its error messages [are verbose and break >> previously-working parsing code] I once had the chance to try to use a machine whose compiler's complaints were verbose multiline monstrosities like the ones I assume you're complaining about. I do not recall whose machine it was. > I don't agree, however, with the above comments. More computer > manufacturers deliver these kind of C compilers (not Bull by the > way). It is a more user friendly, stricter syntax checking, > compiler, especially for the novice user. Nothing can be against > that. I have nothing against stricter checking in the compiler. What I objected (and object) to is overly verbose messages. Even that would be acceptable provided it's just a default which can be changed. On the system I used, I found no hint that there was any way to get reasonably terse complaint messages. I do not need five lines per complaint; I do not *want* five lines per complaint. If there were something I could do, an environment variable, even a compiler flag, to get one-line complaints after the style of the BSD compiler, this would satisfy me. If I had been going to work with the system I tried for very long, I would have written a wrapper to filter the garbage out of the complaints and preserve just the useful information. What's wrong with verbose complaints? (For me, that is.) Primarily, they scroll by too fast. I slip up once in my program and I can't (couldn't) hit ^C fast enough to keep the first complaint - the one that starts the floodgating - from being scrolled off the screen by the rest of them. (If I had had emacs working on the machine it would have helped, but only somewhat. Not enough.) Enough of this in an X forum anyway. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu