[Info-vax] HP wins Oracle Itanium case

[John Wallace]

On Aug 22, 8:25 am, Paul Sture <nos... at sture.ch> wrote:
> On Tue, 21 Aug 2012 18:19:47 +0000, ChrisQ wrote:
> > On 08/21/12 17:40, David Froble wrote:
>
> >> I've found debuggers to be quite useful. Many times they have pointed
> >> out something that was right in front of my nose, and I didn't see it.
> >> Great harm to the ego.
>
> >> But yeah, you really need to understand the code.
>
> > Most manufacturers embedded tool chains come with an ide and debugger
> > these days and they are sometimes quite usefull for finding a subtle
> > problems. However, there is a tendency in some quarters for the debugger
> > to be used first to find a problem, rather than analysing where the
> > problem is from program behaviour and reference to the source. Over
> > reliance just takes away the instinctive ability, if that doesn't sound
> > too pretentious. Keep the mind sharp, problem solving is what it's for
> > and all that :-).
>
> The one thing I miss with the demise of line printer fan fold paper is
> the ability to print out source code or compilation listings for
> debugging purposes.  With source code typically less than 80 characters,
> the white space at the RHS of the 132 character printout gave you plenty
> of room to pencil in notes and new bits of code.
>
> One place I worked had a quiet room full of desks where you could retreat
> from the hubbub of chatter and phones, taking your listings with you.  I
> found this a really good way not just to concentrate on the problem in
> hand, but to avoid the impulse to make a minor change, recompile, make
> another minor change, recompile and so on.
>
> > I start out with the maxim that code should should work right first
> > time, but that requires up front effort. Obviously it doesn't always,
> > but if the effort is put in first, then any bugs should be easier to
> > find, with or without a debugger...
>
> I still find printing source code a useful way to review code.
>
> --
> Paul Sture

For the last few days I have been trying to sort an unfortuante
scenario where embedded compiler A does the right thing but embedded
compiler B doesn't, and for regulatory reasons life would be (much)
easier with compiler B.

Today I covered my desktop with five columns of A4. Four columns of
four sections where compiler A matches compiler B, and one for the one
where the differences are. Lots of scribbling. Green and white would
have been good too.

It also occurs to me that in documenting this occurence, CDA (compound
document architecture) and its transparent integration with text-only
apps would have been quite handy. But CDA was two decades ago and
Microsoft haven't reinvented it properly yet, though OLE descended
from bits of it.

Lots of readers probably aren't familiar with CDA (it's not even
mentioned in Wikipedia's Compound Document article, despite the OLE
connection) but the CDA compound document stuff was what allowed DEC's
GUI applications on VMS, Unix and some x86 OS or other (word
processing, pictures, spreadsheets, etc) to integrate text and non-
text stuff, and one application's data with another's, and so on. [How
many people even knew DEC did "productivity" applications on
workstations? How many people knew that there was a CDA-compliant
picture-capable version of VMSNotes?]

What CDA did that its more widely known successors did not, by using
RMS and other CDA magick, was allow text-only applications to open a
compund document file in their usual way and simply see the relevant
text (or some representation thereof), while the intended application
sees rich text, or whatever, in a way that "modern" word processor/
spreadsheet/etc users can only dream about.

And in my dreams this afternoon I wondered about putting relevant bits
of the source I was investigating, plus various other "plain text"
files, into CDA documents, which would look just like ordinary files
to an ordinary compiler, but to a word processor would allow me to
e.g. highlight the problematic code for printing/emailing/publishing,
and do stuff that no IDE/toolchain I'm aware of can do (do IDEs even
understand RTF files?).

The CDA side of things could even be used to (transparently) implement
some of the "metadata" stuff which Hoff referred to earlier - which
version of Word created this file, for example?

Digital Technical Journal Volume 2 Number 1 (Winter 1990) covers some
of CDA's gory details. It's not available as original PDF that I could
find (the HP site goes no further back than Volume 3). Courtesy of
some kind volunteer efforts it is available as scanned (and OCR'd)
image [1].

A CDA-like implementation of something like PDF would in principle
have meant that compatible apps would be able to read a the text from
a PDF file, by means of some intervening layer whose API was all they
needed to know, without actually needing to know about PDF itself.
Gee, would anyone be able to use something like that?

Give it another ten years, maybe CDA will get reinvented and Apple or
MS will patent it in the US and elsewhere.

[1] http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v02-01_1990.pdf