| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4518.1 | | TOOK::MCPHERSON | pre-retinal integration | Tue Feb 09 1993 14:36 | 9 |
| Yeah, I noticed this too when I tried to use my olf MCC 1.1 regression
testing procedures against T1.3.
This has something to to with the way that FCL is handling terminal
output ("No sh*t, Sherlock," you're probably saying...). Evidently
there were some changes made for performance reasons after 1.1 (maybe
event in 1.2).
/doug
|
| 4518.2 | bug? | SKIGOD::PFROMER | Ed Pfromer, ESM Engineering | Tue Feb 09 1993 15:49 | 2 |
|
I would assume this is a bug, and not intended operation, correct?
|
| 4518.3 | C RTL / Batch | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Tue Feb 09 1993 17:50 | 6 |
| It's known of the way batch interacts with C RTL I/O routines.
Batch notices that the C RTL does a QIO of a short string, and stuffs
the bytes from it into a single line all by itself.
You can either fix batch, or change C, but I seriously doubt that you
will succede in getting either done.
|
| 4518.4 | what changed? | SKIGOD::PFROMER | Ed Pfromer, ESM Engineering | Wed Feb 10 1993 13:05 | 8 |
| >
>It's known of the way batch interacts with C RTL I/O routines.
>Batch notices that the C RTL does a QIO of a short string, and stuffs
>the bytes from it into a single line all by itself.
>
So what changed from MCC V1 to T1.3.1? C RTL or QIO? We didn't have
this problem before.
|
| 4518.5 | OK, it's a hack, but... | TOOK::STRUTT | Management - the one word oxymoron | Wed Feb 10 1993 16:33 | 13 |
| This is by no means a solution to your problem, but it may help you in
the interim.
There is a USE command with DECmcc FCL which controls which column the
"=" sign appears. You can modify it away from the default (which is 42).
MCC> use indentation 30
%MCC-S-INDSET, indentation level set to 30
MCC>
Put this command early in your MCC command file.
Colin
|
| 4518.6 | USE INDENT won't change it., | TOOK::MCPHERSON | pre-retinal integration | Wed Feb 10 1993 21:03 | 11 |
| Colin,
I'm pretty sure that what you suggested won't work.
There is movement afoot to 'undo' the performance change for the FCL (it only
affected ULTRIX terminal I/O).
My tests with a 'un-fixed' FCL worked out fine. We'll have to
wait and see if it will make it in the kit...
/doug
|
| 4518.7 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Thu Feb 11 1993 08:59 | 13 |
| Arrrgghhh, how depressing.
This is a side affect of one of the things done in V1.3 to attempt
to substantially increase notification throughput. It turns out
that "printf" to dxterms are very expensive and people have been
beating on us to make *significant* improvements (like an order
of magnitude or more) in the rate it which we can pump notifications
through the system.
Maybe we need an environmental variable defining whether you want
your output fast, or want it correct :-)
|
| 4518.8 | Fast|Cheap|Correct. Pick one. ;^) | TOOK::MCPHERSON | pre-retinal integration | Thu Feb 11 1993 11:05 | 9 |
| > Maybe we need an environmental variable defining whether you want
> your output fast, or want it correct :-)
Shhhhh! Don't let Mark S. hear you say that!
;^) ;^)
/doug
|
| 4518.9 | | RACER::dave | Ahh, but fortunately, I have the key to escape reality. | Fri Feb 12 1993 16:16 | 1 |
| Note that this has nothing to do with ultrix, as Ed is running on a VMS system.
|
| 4518.10 | | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Mon Feb 15 1993 10:19 | 3 |
| Who said it had anything to do with Ultrix? The code in question
is common to both platforms.
|