Live data from Hacker News

Some of the error messages produced by Apple's MPW C compiler (2006)

cs.cmu.edu

101–110 of 154 posts

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#101

Earlier quoted context omitted.

...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.

You're probably looking for "#if 0" / "#endif".

The fact that you can't do this with new fangled languages is one of the reasons I don't use new fangled languages

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#102

My favorite error message was produced by the Univac Fortran V compiler, circa 1970: “Warning: floating point equality tests are nugatory.” I pride myself on my vocabulary, but I had to use the dictionary.

I recall from 1965 getting an error message message something like this from the Fortran complier on a Univac 1107 system after receiving too many error messages: "Do not attempt to learn Fortran using Monte Carlo method. Buy a manual in the user office."

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#103

Earlier quoted context omitted.

You're probably looking for "#if 0" / "#endif".

The fact that you can't do this with new fangled languages is one of the reasons I don't use new fangled languages

That and other things I dislike about many of the new fangled languages.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#104
post #4

"Call me paranoid but finding '/*' inside this comment makes me suspicious" That, Sir, is none of your business.

...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.

Not terrible at all.

It's super-useful to temporarily comment out a bit of code, and then to comment out a larger block surrounding it. Especially when debugging.

Sadly I've never used a language that supported that.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#105
post #91

The old Clipper 5 compiler had some fun error messages. The two that I remember running into were “Ford Maverick Error”, and my personal favorite, “Carnage! Module name crushed in compilation disaster!”. I ran across both abusing its preprocessor.

I’m so curious, what could a Ford Maverick error possibly signify?

I’m honestly not sure. I met a couple of the developers at a convention a few years later, and found out the carnage one was where a stack of tokens from the tokenizer was unexpectedly deleted, but we didn’t talk about the other one. I suspect someone probably owned a Maverick that was buggy tho, or didn’t run.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#107
post #21

> "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer" Ah, the old times when one could purchase a RAM upgrade or upgrade RAM after buying a computer. Now this would be: "Symbol table full - fatal heap error; please go buy a new Mac with more RAM"

You can always use a PC if you want upgradeable RAM.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#108

Earlier quoted context omitted.

There’s nothing stopping anyone from going back and using all of that old software exclusively. For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?

> There’s nothing stopping anyone from going back and using all of that old software exclusively. Monthly bills are stopping me. Can I use Apple's MPW C compiler to build for iOS?

I don't know what boxes need to be ticked, but tcc is around 200kb and supports ARM.

Re: Some of the error messages produced by Apple's MPW C compiler (2006)

#110

Earlier quoted context omitted.

...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.

Not terrible at all. It's super-useful to temporarily comment out a bit of code, and then to comment out a larger block surrounding it. Especially when debugging. Sadly I've never used a language that supported that.

Common Lisp has nested comments with the #| reader macro.

https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node191.html

Post reply on HN