Back on R18, and again on R20, I collected and distributed some of the informal programmer remarks included in the Pro/E executable code. These aren’t the formal comments in a computer program, which a compiler will ignore. But the spontaneous personal comments of the people writing the code. PTC seems to be the only major software vendor that allows these kinds of personal comments in the released code, all the other software vendors carefully remove them.
Wondered if I’d bother to check again on 2000i2 (R22). But right away I found this new comment:
Yep, those are the exact words burned into every CD of Pro/E 2000i2 distributed to all PTC customers worldwide (use ‘strings’ and ‘grep’ to find them, in Unix).
Well, after that, wouldn’t be human not to look for more. Just one additional benefit of being a PTC customer, you can sit alongside the programmers as they work, get to know them, listen to their thoughts. All the indented lines below come right off the CD, everyone who has 2000i2 has them, right on the CD, in the executeable itself.
Computer users usually have to interface with customer support to identify problems, and rarely get to talk with the programmers themselves. But in the Pro/E code, Konstantin has always been an important figure:
- Please tell Konstantin
and
- Please complain to Konstantin
However now at last we get his full name, and internal extension number at PTC:
- ! Author: Konstantin Ignatiev, x6885
So, why bother with customer support, call Konstantin directly:
Entire new model there of customer support. As long as the customers can get the names and phone numbers of the programmers in the CD, why bother to call customer support? Just deal direct with the programmers.
Programming may sound rather a dull job, solitary work at the keyboard, but it has its exciting moments, rating as many as 6 exclamation marks each:
- !!! Files Are Different !!!
- !!! Mass Props Are Different !!!
- !!! Line Counts Are Different !!!
And many more routine excitements, with from one to three exclamation marks each:
- UNKNOWN !!!
- impossible!
- Big Trouble!
- zero grid size!
- The model is gone!
- node array is junk!
- part rolled to nothing!
- Some points disappeared!
- could not swap diagonal!!!
- unknown coordinate system type !!!
- Assembly did not contain any members!
- Cannot recreate onesided surfaces – very bad error!!!
- Warning: retrieved complex entry pointing to nothing!
There can be serious problems, and even horrible errors, programming is certainly not for the timid:
- We have serious retrieval problems here.
a horrible error occured (feat id = %d) !!!
The very worst of all fears can strike:
- pat rec is neither leader nor member – death!
How can you know whom or what to trust:
- DO NOT RELY ON THIS!
And it’s hard for any engineer to learn to stop, to quit, to accept a less than perfect solution:
- Although buffers can work, we have to stop.
Often people are just asking, just as if they were sitting together at a workstation figuring out a problem, or just talking to themselves:
- Who put NULL on the oper stack?!
- you mean we don’t have a dwg view?
More questions abound:
- say what?
- Mark what??
- What did I forget?
- how did we get here?
- What brought us here?
- How did skamp #%d id %d get denied?
Confusion can be rampant:
- What ?!
- crazy ids!
- what — no input!?
- index is not supposed to be %d
- Negative diameter is too weird for me.
- no drawing, process asm, I’m confused!
- Somehow a duplicate node was inserted!
- Got regen error %d, but I’m not implemented yet
There are cries for help:
- Fix me!!!
And also requests and commands:
- don’t touch this!
- Possible memory leak! Fix it!
- tsk tsk, select same line please!
Say, “tsk, tsk”, that might be rather fun to see in the official error messages. Sort of a reprimand, but light hearted.
Now people, even programmers, do make mistakes:
- oops
- duh?
- arghh!
- oops, bad assumption
- oh, ignominy! [sounds like Shakespeare]
- Woops, this shouldn’t happen
And there are thoughtful reflections on the intricacies of software:
- we should not get an error at this point
- we should have written the code to avoid this
Although sometimes the strictly professional tone is absent:
- It’s already in the list, silly
- This is the crap you have to do to be able to use ugc_open_stream_input()
If you were a paying customer, and were trying to copy a layer, you probably wouldn’t want to get this comment:
- Stupid attempt to copy a layer.
But between themselves, these programmers seem to take a very direct and frank approach to commenting on each other’s work:
- Stupid shake.
- Stupid value: %d
- is a stupid function
- Stupid param type %d
- Stupid value %d passed.
- Stupid problem naming zone feat!
- Stupid input value in usr_input_parameter().
Sorrow can strike, even in a form known to many a computer user:
- Boo hoo, no backup!
And you might sometimes just abandon hope:
- GUESSING…. That’s it – I’m giving up!
But then, occasionally, there are reports of success:
- We get here after all – HMR
- Correct handling of swept blend tangents, finally!
Somehow fishing seems often on the minds of PTC programmers:
- fishy
- fishy incoming handle
- something fishy is going on!!!
- called with fishy banner line %s
Pro/E makes extensive use of memory, more than most other applications, and with a computer rebooting is the only way to clean up memory. These following comments seem to show the programmers see many possible memory problems:
- Memory leakage!
- Memory corrupted.
- Memory overwritten
- Memory leak is possible!
- memory allocation failure.
- Memory corruption detected.
- Memory overwrite may result.
Sometimes a customer calling PTC Customer Service may wonder if they are even speaking the same language. The customer says, “I had a crash”. And the Customer Service rep. says, “Ah, you had an unexpected exit”. The customer says, “Well, no, actually I had a crash”. And Customer Service says, “No, what you’re saying is, you had an unexpected exit”. And the customer says, “No! That’s not what I’m saying at all! I had a crash, C-R-A-S-H!”.
And so the conversation continues. Well, what do the programmers say? Do they speak the same language as the customer, or do they speak the same language as Customer Service? The evidence is totally conclusive. In all the 2000i2 compiled code, there is not a single mention of ‘unexpected exit’. While crashes occur often, and in many forms:
- Crash
- CRASH
- CRASH!!!
- Forced crash.
- crashing on bad entity.
- Crashing to avoid infinite loop
- crash_on_exit() called: look at trail.
That really doesn’t sound good, crash_on_exit, if it’s a function you hope you don’t see it called on you. Although sometimes it’s possible to survive an imminent crash:
- Continuing from a crash condition !
Or to work around a possible crash:
- should not happen: filling in_norm to avoid crash
Would be nice to have these two push buttons around, for use when needed, especially the second one:
- PushButtonCrash
- PushButtonDontCrash
But also apparently sometimes you just take your chances, sometimes you crash and sometimes you don’t:
- routine %s – crashing
- routine %s – not crashing…
Anyway, if Customer Service would just simply abandon entirely their use of ‘unexpected exit’, and just say ‘crash’, like the paying customers and like the programmers, then communcation between all three parties might be smoother.
Time now to end yet another installment of PTC programmer remarks. Probably best to conclude with these two lines, which I quoted before, for R18 and again for R20. The question:
- how could we have survived this?
And from the heart of the code this affirmative answer:
- But we created it!
Sun Microsystems