For years people (user people and PTC people) have mentioned there are personal names and comments embedded in the Pro/E code. But that fact apparently has never been documented. At the user conference in Orlando, I submitted a question to the PTC management track on these names and comments, with some examples, but didn’t get a reply.
Pro/E may be unique among major software applications because of all the personal observations distributed in the compiled code. These comments could be a contribution to the history of software programming—at times you feel as if you’re looking right over the individual programmers’ shoulders, as they express themself on the keyboard. You get an insight into the people, their work, their common culture and their personal differences.
To list out the plain text in any compiled code, you can use the Unix ‘strings’ command. That’s often useful to check a version, or to collect and compare error messages, normally very dull reading. But with Pro/E you get a lot more, not dull at all. Everything indented below is taken directly from the plain text in the R18 code, with comments added.
Customers don’t often talk directly to programmers. However here you can listen to the programmers talking among themselves. Often they are polite, courteous even:
- Please tell Konstantin.
Although there can also be a trace of stress:
- Please complain to Konstantin.
Mike and Jatin seem to share responsibility for part size:
- part size has increased, please notify Mike.
- part size has increased, please notify Jatin.
But it’s Anton who gets the calls with steadily increasing urgency:
- Please tell Anton
- Please tell Anton !
- cannot classify loop %d – please tell Anton !!
- Cannot raytrace this loop. Please tell Anton !!!!
Most of the personal names embedded in the code are Russian, not a big surprise, since for years many Russian technical immigrants relied on jobs with one of the Boston area MCAD vendors. And these Russian names usually appear with courteous and polite statements (like, “Please tell…”). There’s also at least one Scot in the crowd:
- Cannae find the entity
- Cannae find _any_ entities!
However other programmers are not quite so polite, here are some examples of a more abrupt native born American style:
- Not using your menu item font because it is too big.
- You have too many windows open. Quit out of a few and retry.
- Who called me with no expressions?
- do NOT pass negative index to me please
- very stupid call – no view buffer
Here’s a common observation, but surely not intended for the paying customer:
- Obviously You don’t know the Password
And us native born Americans can get pretty rude, even:
- Hey, fix the sect_flip!!
- Hey schmuck, what table is this %d
Sad to say, Konstantin’s children growing up in the US are more likely to talk that way than in the polite manner of their father.
NC programming often depends on using a quilt of surfaces to guide the tool, and if you lose the quilt that’s important:
- We lost the quilt !!
Another NC programming problem is gouges, caused when the cutting tool cuts into the part surface. Here the story is one of steady progress:
- resolve_vertical_jumps_3ax: SMALL GOUGE FIXED
- resolve_vertical_jumps_3ax: MEDIUM GOUGE FIXED
- resolve_vertical_jumps_3ax: LARGE GOUGE FIXED
- resolve_vertical_jumps_3ax: HUGE GOUGE FIXED
Data can have problems:
- BAD DATA.
- VERY BAD DATA.
- Dataflow screwup, please tell Piotr
But an explanation might be close to hand:
- somebody forgot to clean data last time
We all probably know someone like that, the kind of person who forgets to clean up after themselves, making problems for others.
In MCAD programming, geometry can be difficult to deal with:
- Tweak_faces error: new_geom is INVISIBLE. Please, tell Lev.
- Tweak_faces error: old_geom is INVISIBLE. Please, tell Lev.
Sometimes the whole outlook isn’t good:
- LOOKS BAD
- Something BAD !
- Very, very BAD !
Something can happen in different ways:
- Something happened.
- Something happened !
- Something happened !!!
Sometimes we get a few more details about something:
- Something is already there
- something didn’t get popped
- something’s wrong.
- something is wrong.
- SOMETHING WRONG !!!
Sometimes something wrong doesn’t mean much:
- draft ok setup ok picture wrong? Applying anyway.
- dropped through to the bottom. Returning TRUE anyway
Goofs happen in programming, that’s normal:
- Major goof: special_draw_brick.
- tri_insert goof. Please tell KMR
- Goofed
And mistakes too, sometimes big mistakes:
- eval_cl_chain_quick: big mistake
Imagine you’re on a plane, and you happen to hear this exclamation from the cockpit:
- NO OVERRIDE OCCUPY!!!!! DOING IT ANYWAY…
You might be concerned. But we’re not on a plane, this is just a software application, and it doesn’t seem to apply to any particular area of the software.
However here’s a warning message that might have any user worried:
- You better don’t push this button…
I tried to find out from the context, which button it is, that you’d better not push, but that isn’t clear. Hopefully you get the message before you push the button.
Of course, in any programming task, weird things happen:
- rgb_img_seek: weird dim
- rgb_img_seek: weird image type
- weird geom with no outer contour
- subkeys even though handle IS the parent of prev_handle –
Weird ! - subkeys, even though handle IS the parent of next_handle –
Weird !
Weird slots can jump on you almost any time, you’d better be alert— look out, be ready to duck down right under your desk!
- WEIRD FROM-TO ONE SIDE SLOT – LOOK OUT !
- WEIRD THRU-UNTIL BOTH SIDES SLOT – LOOK OUT !
You hear some pretty candid admissions:
- I don’t like infinite loops
- don’t know what to say about the failure!!!
- check_break_intersections () didn’t do the job!
- I think this function never works.
Sometimes the statement is the simplest possible fact:
- I am here!
(good at least someone is on the job there).
Sometimes questions appear just as they might have been asked right out in the hallway, or at the soda machine:
- What did I forget?
- Well is it or isn’t it?
- just found it, didn’t I ?
- how did we get out of the loop?
- Do we copy sub structures?
- Should copied surfaces be updated if they are cut?
- DOES THIS WORK?
And sometimes the tone is more discursive:
- Though I don’t know what the problem is
I suspect it may be related to either
%s(%d) or EDGE(%d).
Sometimes comments are tied to particular routines:
runmode %d — calling crash_on_exit (), sorry …
Yes, I’d hope you would say sorry, if you called crash_on_exit on me. Sorry is refreshing, would be nice to see more computer error messages that say sorry. Most of these were probably intended for fellow programmers, and not for users:
- sorry, not fully implemented yet
- Sorry, not implemented yet for connectors…
- Functionality doesn’t ready yet. Sorry.
- something is wrong – sorry, this is experimental
Anyone who’s done any programming should recognize these states of mind, when words just fail:
- ????
- ??????
- ?!?!?!?
And the monotony and routine of programming work can get you down:
- legacy_free_backup_feat_low
- What the bloody hell…
- legacy_recover_feat_low
- What the bloody hell…
Language becomes pretty colloquial at times:
- Guess transformation ain’t even close.
- ain’t no model
- add_algndtans_eq: This code ain’t written yet.
Perhaps by now you might agree with this statement:
- Sorry, too many messages…
To conclude, anyone who has ever worked on a major software development project has probably felt this way:
- how could we have survived this?
However from the heart of the code comes this affirmative answer:
- But we created it!
Sun Microsystems