Apple के MPW C compiler (2006) द्वारा बनाए गए कुछ error messages

 (cs.cmu.edu)
2 पॉइंट द्वारा GN⁺ 2023-08-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह Apple के MPW C compiler के error messages को इकट्ठा करने वाला एक पेज है, और कहा गया है कि ये compiler के String resources को decompile करके प्राप्त किए गए वास्तविक अंश हैं
  • सामान्य compiler diagnostics की जगह इसमें मज़ाक और व्यंग्य मिले हुए वाक्यों के जरिए ANSI C specification, type constraints, और syntax errors बताए जाते हैं
  • उदाहरणों में string literal की लंबाई, switch के अंदर label, typedef की position, volatile/register का संयोजन, और constant को modify करने जैसी C language errors शामिल हैं
  • void * manipulation, void casting, struct redefinition, और goto तथा automatic variable initialization से जुड़े errors जैसे खास compile situations को सीधे निशाना बनाया गया है
  • compiler का आकार 324KB है, और यह भी जोड़ा गया है कि प्रकाशित सूची पूरी नहीं बल्कि अंश हो सकती है, साथ ही copyright मुद्दा भी स्पष्ट नहीं है

MPW C compiler error messages का संग्रह

  • यह Apple के MPW C compiler द्वारा बनाए गए कुछ error messages को सूचीबद्ध करने वाला पेज है
  • messages को वास्तविक output के रूप में पेश किया गया है, और कहा गया है कि इन्हें compiler के String resources को decompile करके प्राप्त किया गया है
  • compiler का आकार 324KB है, इसलिए यह संभव है कि सूची पूरी नहीं बल्कि केवल कुछ अंश हो
  • copyright मुद्दे पर लेखक ने कहा है कि स्थिति स्पष्ट नहीं है

मज़ाक जैसे दिखने वाले वास्तविक diagnostics के उदाहरण

  • C syntax और ANSI specification को मोड़ते हुए messages

    • string literal लंबाई सीमा:
      • "String literal too long (I let you have 512 characters, that's 3 more than ANSI said I should)"
    • switch statement के अंदर सिर्फ case या default label होने चाहिए, इस error का संदेश:
      • "...And the lord said, 'lo, there shall only be case or default labels inside a switch statement'"
    • ऐसी स्थिति जहाँ एक अनपेक्षित typedef नाम मिला:
      • "a typedef name was a complete surprise to me at this point in your program"
    • ANSI C clause का हवाला देकर कहा गया है कि cast target scalar होना चाहिए:
      • "type in (cast) must be scalar; ANSI 3.3.4; page 39, lines 10-11 (I know you don't care, I'm just trying to annoy you)"

  • type और declaration से जुड़ी errors

    • volatile और register को साथ नहीं इस्तेमाल किया जा सकता, यह संदेश:
      • "'Volatile' and 'Register' are not miscible"
    • constant को modify नहीं किया जा सकता, इसे व्यंग्यात्मक ढंग से कहा गया है:
      • "You can't modify a constant, float upstream, win an argument with the IRS, or satisfy this compiler"
    • पहले से defined struct को फिर से define करने की स्थिति:
      • "This struct already has a perfectly good definition"
    • void से जुड़ी cast सीमा:
      • "Can't cast a void type to type void (because the ANSI spec. says so, that's why)"
    • void * को मनमाने ढंग से handle नहीं किया जा सकता, यह संदेश:
      • "can't go mucking with a 'void *'"

  • छोटे या अतिरंजित error expressions

    • छोटा और सीधा error:
      • "Huh ?"
    • ऐसी स्थिति जहाँ पहले ही process की गई function फिर से मिली:
      • "we already did this function"
    • block के बाहर से आए goto, initializer वाले automatic variable, और बहुत संकरी window—इन सबको एक साथ संभालता लंबा error:
      • "This label is the target of a goto from outside of the block containing this label AND this block has an automatic variable with an initializer AND your window wasn't wide enough to read this whole error message"
    • comment के अंदर /* मिलने की स्थिति:
      • "Call me paranoid but finding '/*' inside this comment makes me suspicious"
    • एक लाइन में बहुत ज़्यादा errors होने की स्थिति:
      • "Too many errors on one line (make fewer)"
    • symbol table भर जाने पर fatal heap error:
      • "Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer"

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-28
Hacker News टिप्पणियाँ

  • कंप्यूटिंग में ऐसी शरारत वाले दिनों की याद आती है
    जब मैं Amazon में था, तो मेरे मैनेजर ने बताया था कि पहले 404 पेज अपडेट करते समय उन्होंने अपनी बेटी की बनाई बिल्ली की ड्रॉइंग स्कैन करके पेज के body में डाल दी थी। 2009 में जब मैंने जॉइन किया, तब भी वह इमेज मौजूद थी, लेकिन किसी समय शायद किसी ने नोटिस किया और उसे कुत्ते की stock photo से बदल दिया। फिर भी asset का नाम अब भी kayli-kitty.jpg था, और बाद में जब उसे फिर rotating photos में बदला गया तो original के निशान मिट गए

    • वाकई कमाल है। कुछ Amazon 404 पेज, जैसे https://www.amazon.co.jp/404 में filename आज भी kailey-kitty.gif है, लेकिन इमेज standard icon में बदल चुकी है
      इससे जुड़ा blog comment भी मिला: https://www.davebellous.com/2006/09/25/what-the/#comment-290...
    • “compiler का size 324k” — हमने सिर्फ शरारत ही नहीं खोई है। software bloat अब comedy के स्तर तक पहुँच गया है
    • archive.org पर वह मुश्किल से मिलने वाली बिल्ली की तस्वीर तो नहीं मिली, लेकिन इसके बजाय यह कुत्ते की image मिली: https://web.archive.org/web/20030113144310/https://www.amazo...
      लगता है Amazon ने बड़ी कुत्ते वाली image के साथ मौजूदा error page जून 2016 के आसपास शुरू किया: https://web.archive.org/web/20160612232820/http://www.amazon...
    • www.amazon.com खोलिए और सीधे source देखिए :)
    • बेटी 18 साल की होने के बाद copyright infringement के लिए मुकदमा भी कर सकती थी ;)
      सच में जिज्ञासा है: अगर guardian ने पहले consent दे दिया हो, तब भी क्या ऐसा संभव है?

  • “Symbol table full - fatal heap error; please go buy a RAM upgrade from your local Apple dealer” सुनकर वे पुराने दिन याद आते हैं, जब computer खरीदने के बाद भी RAM upgrade खरीदा जा सकता था
    आज होता तो शायद “Symbol table full - fatal heap error; please go buy a new Mac with more RAM” होता

    • ज़रूरी नहीं। Classic Mac OS virtual memory support नहीं करता था, इसलिए जब तक program unused data को खुद disk पर न उतारे, सब कुछ RAM में ही रहना पड़ता था
      आधुनिक operating systems सभी swapping support करते हैं, इसलिए compile चलता रहता है, बस बहुत धीमा हो जाता है। आधुनिक computer पर सचमुच “out of memory” होने के लिए RAM और disk दोनों भरने पड़ते हैं
    • SoC की unified memory वाली logic समझ में आती है, लेकिन फिर भी अफसोस है। नए Mac Pro में भी RAM slots नहीं हैं
    • upgrade करने योग्य RAM चाहिए तो कभी भी PC इस्तेमाल कर सकते हैं
    • आजकल तो उलटा और भी ज़्यादा ऐसा है। Apple Silicon Mac समान memory capacity में दोगुनी जानकारी store कर सकता है, इसलिए मामूली 8GB configuration में भी FizzBuzz boilerplate के 16GB, Google Chrome के 4 tabs, या average node_modules का 20% समा सकता है

  • “a typedef name was a complete surprise to me at this point in your program”
    मजेदार compiler error messages वाले दिन अच्छे थे। पहले एक vendor compiler में मैंने ऐसा message देखा था: “No! But they'll only let me warn you. Danger Will Robinson! Danger!”
    और “Really! If you are fussing around with void *, just go home or at least back to your editor!” भी था। लगता है IT manager उसी message की वजह से उस vendor को इस्तेमाल करते रहे। SDK बस ठीक-ठाक था, लेकिन मजा था

    • मैंने C programming बहुत ज़्यादा नहीं की है; context जानना चाहता हूँ कि void* इतना बड़ा issue क्यों था

  • जब से संभव हुआ, मैंने original MacOS पर programming की। ये error messages बहुत याद हैं। खासकर “Too many errors on one line (make fewer)” याद है
    यह भी याद आता है कि एक header file बदल जाए तो build में 45 मिनट लगते थे

    • उन दिनों 68k, C, Pascal मिलाकर बस system extensions, plugins और XCMD बनाता था। projects सब छोटे थे, इसलिए compile time समस्या नहीं था और MPW स्वर्ग जैसा था
      सबसे बड़े XCMD में तीनों languages थीं, और MPW ने उन्हें बिना दिक्कत link कर दिया। ऐसे projects भी automate करना आसान था जिनमें एक file के अंदर paste करने के लिए छोटे code blocks होते थे। जब भी कोई rare error message आता, जोर से हँसी आती थी। जिसने बनाया, बढ़िया काम किया

  • इस compiler को कई साल इस्तेमाल करते-करते, अगर function बहुत बड़ा न हो तो generated 68k object code को दिमाग में तुरंत C code में “decompile” कर सकता था
    MacNosy इस्तेमाल करने पर आम तौर पर कुछ घंटों में app का C source फिर से बनाया जा सकता था। मेरे पास एक script थी जो app की MacNosy file को assembler file और rsrc file में बदल देती थी, और original के बराबर build हो सकने वाला app बनाए रखते हुए functions को एक-एक करके C में ले जा सकता था। शुरू में इसे game hacking के लिए इस्तेमाल किया, लेकिन कभी-कभी bug fix में भी काम आया
    MPW C compiler की code generation इतनी predictable होने की एक वजह 68k instruction set की symmetry भी थी। उन्होंने simple compiler बनाया और वह अच्छे से काम करता था। ज़्यादातर मेहनत कहीं और लगी। कौन-सा code निकलेगा, इसका काफी सटीक अंदाजा लगाया जा सकता था, इसलिए अगर code generation पसंद न आए तो source बदल सकते थे। javac compiler में भी ऐसी philosophy है, यह मुझे पसंद है। patterns समझ आने के बाद लगभग optimal bytecode बनाया जा सकता है

  • 90 के शुरुआती दशक में एक education company में इस्तेमाल होने वाला Glockenspiel C++ compiler, cfront से निकला हुआ था, और मेरा सबसे पसंदीदा syntax error message बस “core dumped” था
    C++ से ही जूझ रहे छात्रों को, पैसे लेकर पढ़ाए जा रहे course में, यह समझाना काफी awkward था

    • user बस debugger चलाकर core file में backtrace देख ले। फिर experience बढ़ने पर वे अलग-अलग hexadecimal addresses को अलग-अलग error types से जोड़कर सीख जाएंगे, तो इसमें कोई नुकसान नहीं

  • “Call me paranoid but finding '/*' inside this comment makes me suspicious” — यह तो先生 को चिंता करने की बात नहीं है

    • कभी-कभी सोचता हूँ कि compiler nested block comments support करता तो अच्छा होता। यानी /* के अंदर फिर /* हो तो खत्म करने के लिए */ दो बार चाहिए हों
      असल में शायद यह भयानक idea हो, लेकिन ऐसे काफी मौके आए जहाँ इससे समय बचता

  • page की बात से थोड़ा अलग, लेकिन कई MPW utilities जिस तरह error messages समेत output को command के रूप में generate करती थीं, वह मुझे बहुत अच्छा लगता था
    terminal एक editor buffer था, इसलिए cursor को उस line पर ले जाकर या click करके cmd-enter जैसा कुछ दबाने पर संबंधित file खुल जाती थी

    • selected text execute करना शायद सिर्फ Enter key था
    • Plan 9 जैसा लगता है

  • “a typedef name was a complete surprise to me at this point in your program”
    मैंने यह list अनगिनत बार देखी है, फिर भी यह message हर बार मुझे जोर से हँसा देता है

    • gcc के “Redefinition of ...” या “Static declaration follows non-static” से कहीं बेहतर है

  • पिछली चर्चा: https://news.ycombinator.com/item?id=30238928
    context जोड़ें तो, वह message बनाने वाला MPW C compiler असल में Apple की internal development नहीं था, बल्कि Green Hills Software[1] ने contract पर बनाया था। Wikipedia page[2] और उसके source[3] में भी यह आता है, और मजेदार बात यह है कि वह source खुद यही topic है
    [1] https://en.m.wikipedia.org/wiki/Green_Hills_Software
    [2] https://en.m.wikipedia.org/wiki/Macintosh_Programmer%27s_Wor...
    [3] https://web.archive.org/web/20140528005901/http://lists.appl...