perm filename APR.MSG[2,TES] blob sn#039427 filedate 1973-04-29 generic text, type T, neo UTF8
LARRY,
	I TRIED TO RECOMPILE COMP AND FOUND SEVERAL BUGS.
- SET_UP_FIELD CALLS "ARRAY" IN A SCREWED UP WAY (ALLOC[3]???)
- I COMMENTED OUT THAT OFFENDER AND THEN GOT THE FOLLOWING MESSAGE:
	*** ERROR ***, RECORD_GEN SHOULD HAVE 3 OPERANDS BUT IT HAS 2 OPERANDS,
	NAMELY: ((IDENTIFIER) ((PNAME PRIVATE (STRING)) (PROPERTIES PRIVATE
	(LIST))))
WE'VE GOT TO TRY TO KEEP A FUNCTIONING VERSION OF THE FILES AROUND!
					-- DAVE

27-APR-73  2023		L70,DAV
SORRY, THAT NOTE WAS TO TED.  OBVIOUSLY, I MISSED BY ONE KEY.

27-APR-73  1857		D,LES
Larry,
Before Rich leaves here, is there any chance you have fixed the footnote
hacks in Pub that turn the whole rest of the doc into a footnote
if you make a footnote when near the bottom of the page?  We're
really getting sick of it.  We don't have new Sail up yet, so we
can't just grab your new Pub.  Can you give us pointers into
bug fix, assuming such exists.
		somewhat desperately,
			Lee

27-APR-73  1321		LDE,DCS
Anything which we either rejected or appears in our or their proposal may
as well be deleted.  CTI references may as well be deleted.  I can't think
of anything to keep offhand except your argument for sets, but look
and see.

I am leaning away from LISP70 again, even though it's looking like
it may be ready in time.  The reason is that we will probably want
our own pattern matching notation anyway and I suspect it may not
require fancy backtracking.  As for the combined formatter/paginator,
the Xerox folks pointed out that Lou Paul Flip Charts are a pretty
unusual case.  Most insets go along with a text (viz. any dictionary)
and can be placed by the formatter.  Most diagrams are full column
or two column.  We shouldn't lose the galley stage and simplicity of
the two-part scheme (and CMU writing the paginator) just for these
wierdo cases.  If we want to handle them, the paginator can make a little
file and swap in the formatter to reformat a few paragraphs when needed,
which will be rarely.  It was also pointed out that people will want to
interact with the paginator to give advice, so it ought to be a separate
pass to simplify that.  We can always switch to LISP70 later, but I think
we should plan around Standard Lisp and I think you should learn ILSP.
How does that sound?

20-APR-73  1949		2,TES
JMC NOTES THAT "FIND" USES AN OLD SAIL SEGMENT.  PUT IT
IN THE LIBRARY OR SOMETHING.
******************************
WHEN A PAGE FRAME IS HIGHER THAN 53 LINES, THEN PUB LOOKS TO SEE
IF YOUR INTENDED OUTPUT DEVICE IS LPT OR TTY.  IF LPT, IT PUTS
OUT A SPECIAL LINE FEED AFTER EACH LINE THAT KEEPS THE LINE PRINTER
FROM JUMPING THE FANFOLD CREASE.  ON DATADISCS, THIS SPECIAL LINE
FEED PRINTS AS A ⊃ AND MESSES UP YOUR PAGE PRINTER AS WELL.
SO IF YOU WANT TO READ YOUR DOC FILE ON THE DATADISC, TELL PUB
THE OUTPUT DEVICE IS GOING TO BE A TTY. THERE ARE TWO WAYS TO DO
THIS: THE .DEVICE TTY; COMMAND AND THE (T) COMPILATION SWITCH, E.G.:
	.COM FOO.PUB(T)
THE TROUBLE IS THAT IF YOU PRINT THE RESULTING DOC FILE ON THE LPT,
THEN ONLY 54 LINES WILL BE ON ONE PAGE, THE REST ON THE NEXT!  SO
YOU HAVE TO RECOMPILE FOR EACH DEVICE.  HOWEVER, IF YOU ARE GOING TO
THE XGP INSTEAD OF THE LPT, YOU ARE OK, BECAUSE THE XGP IS A TELETYPE
AS FAR AS PUB IS CONCERNED.

17-APR-73  2036		L70,TES
What is PUB doing to FOO.PUB[1,GG]? The DOC-file contains the
character "⊃" at left side of every line...
				PAX VOBISCUM
17-APR-73  1856		1,GG
LARRY,  I'VE MODIFIED SYNTAX.L70, SO BE CAREFUL NOT TO CLOBBER IT WHEN YOU
RESTORE SYNTAX.NEW .  WE'LL HAVE TO DO A SRCCOM.  I'VE ALSO CHANGED COMP.L70 .
					-- DAVE

17-APR-73  1602		L70,DAV
Larry,
	On second thought, if the documentation is going to be simple
fixed width stuff with nothing very fancy (can't imagine what that
means), then just the doc file will be ok.  Guess the only thing that
we would treat ugly is underlining and lpt chars that are hidden behind
the delete; if those are there, then the .pub would be better.
Hope to have something to you tomorrow (Friday).
			Lee

12-APR-73  1008		LDE,DCS
Yes to May 15.  Remind me when I get REMIND written.  I thought "code"
just meant the low-order dimension of the matrix.  I guess the other
thing I wanted a name for doesn't really need one now that the absolute
matrix has the same dimensions as the relative one.  Tovar also wants
the reference to himself deleted--he finds it disparaging.  (I didn't
mean it that way, honest!)  You didn't answer why you restrict a
whatchamacallit file to 91 glyphs.  Actually not only shouldn't CTI
be mentioned but maybe neither should CTI's names for things, etc.
I'm not too worried about it, though.  Maybe thee entire document
should be marked internal and not for release without our permission.
LES got a notice about a talk at Stanford by somebody from Honeywell
about what purports to be our system, maybe sort of.  Did you see the
notice?  We should certainly attend!  When do you want to meet?

09-APR-73  2037		1,BH
Proposal looks pretty good; I'm not sure it's a good idea to circulate
something with CTI's name on it, however (in the part I wrote) in an
"official" document.  A meeting is fine with me, any time is ok.  By the
way, I see you ducked the question of what to call a code+set+case,
and have undone the distinction between what you are now calling a glyph
and its hardware representation (or at least you now have no atomic name
for the latter).  Also, since "paginated galley" is a contradiction in
terms, you should call the paginated galley guide a page guide instead.
Oh, yeah, serif is spelled with an f (p. 2).  Why doyou limit glyph files

to 91 glyphs?

09-APR-73  1050		1,BH
LARRY,
	WOULD PROBABLY LIKE BOTH .PUB AND .DOC.  COULD PROBABLY USE A NEW PUBMAC.DFS,
SINCE THE ONE WE HAVE IS PRETTY OLD AND PROBABLY BUGGY (NOT SURE ANYONE USES
IT HERE VERY MUCH).  YOU CAN SEND THE STUFF TO A610LE03 (PASSWORD:"SAC" IF YOU
NEED IT), OR JUST GIVE ME A POINTER AND I'LL GOBBLE IT UP MYSELF.
		THANX,
			LEE
P.S.  ANY RESPONSE ABOUT MY COMING OUT THERE ABOUT MAY 15?

09-APR-73  0530		LDE,DCS
Larry,
	Ok, awaiting the block diagram with hope and fear.
We currently have:
1)  Lisp 1.6 circa June, 1970 (I may be wrong, it may be newer;
I will check on it.).  We have MLISP running on it.
2)  Maclisp of Aug-72 (try that one for size!).
3)  ILISP (Irvine) which is new; all our Lispers are moving over to
it and loving it, I hear.

Let me drop one on you: we are strongly convinced that the
doc file should be 8-bit character oriented.  I won't make all the
arguments here (I'll wait to hear the screams first), but I will
point out that we are essentially operating in that mode on the 
XGP now, without overly obnoxious results.  Waiting to get
responeses,
		Lee
P.S.  Looks like I may come out your way about May 15 to interact
with all you westerners -- don't know for sure yet.  How would that
fit in with peopls' schedules?
PUB keeps blowing up in my face (after 18:44 compute time!) after (or while)
reading 5FIGU.PUG. Message is:
Undefined label
just above (or on)  /0[99999/99]
CALLED FROM 402776 LAST SAIL CALL AT 4111
The message does not make sense to me - seems to indicate blown-out innards.
LF has the effect of repeating the same message a few times, after which I get
INVALID INDEX NO. 1 FOR ARRAY STBL
Besides the conjecture that PUB is not feeling well, I suspect it would run
substantially faster if you declared all arrays safe (on the system version).
Get in touch, please...
05-APR-73  0153		1,GG
Suggestion:  put GJA.BUG in NOTICE[UP,DOC] so that NEWS readers
will find it.
 
04-APR-73  2251		D,LES
Larry,
Please read tes.msg[lde,dcs]
		....Lee

03-APR-73  0804		LDE,DCS
Larry:
This is Rich Johnsson.  I read your message to Lee.  It sounds
good and also like a lot of work.  I'd be happy to work on such a system
because I would very much like to see a more integrated document
production system for LPT-XGP-scope type devices.

I'm not a part of the "in" group in the XGP scene here so I can't say
whether your proposals mesh with our thinking, but
whatever the outcome of that, I think we could produce a
much better system than what we have now.

If you have any messages for me you might send a note to A700RJ14 as
well as to A700PU00.

03-APR-73  0740		NET,GUE
PUB blows up on text-macros that used to work
(EXTRANEOUS `{' IN COMMAND LINE)
PUB.OLD seems to do better. What has been changed?
03-APR-73  0141		1,GG
Larry,
	We are chewing over your note of 31-Mar and trying to
understand it in the context of what we have been doing and thinking
about.  I (we) are still somewhat confused, but here goes a preliminary attempt
at some of our concerns.
	Our biggest concern is with your desire for the output
of the formatter to be device dependent with a different format
for each device.  This seems bad to us for several resons:
1)  There are an almost infinite # of devices.  e.g. each
xgp is really a different device in that each wants a different
input format because each has different interfaces with
substantially different capabilities.  Thus, every
program that wants to create ouput must know about every
device--a rather sorry state of affairs.
2)  If a document is formatted for one device & i wish to
see it on another, i must now rerun the formatter, which i
assume will take about the same amount of processing as
Pub now uses.  Besides being rather wasteful of my time
and the machine's, I'm still not very reassured that what I
see on one will look like what I see on the other --
this is a use of the devices that I very often like to
do, e.g. looking at my document on a display before printing
it on the xgp.
(got to go, more to come.  Lee)
If you don't log in before tonite I'll tell you this in person,
but it isn't quite true that there's no reason to worry about
font compatibility between machines.  The reason is that if
somebody at one site runs off somebody else's long document,
and then calls them up and says "look at page 36" there will be
a problem if the fonts are different.  Possible solutions:
1.  People have to learn to make such references using section
    numbers or the like rather than pages.
2.  Documents to be distributed around the net can be set in
    nofill nojust nonuttin with fixed pages.
3.  One could try to define a very conservative "standard font"
    which would be simulatable on any device, even a lpt; thus
    fixed width chars, and min(everybody's hardware) chars per
    line, etc.

03-APR-73  1620		1,BH
Larry,
Please read tes.msg[lde,dcs]
		....Lee

03-APR-73  0804		LDE,DCS
Larry:
This is Rich Johnsson.  I read your message to Lee.  It sounds
good and also like a lot of work.  I'd be happy to work on such a system
because I would very much like to see a more integrated document
production system for LPT-XGP-scope type devices.

I'm not a part of the "in" group in the XGP scene here so I can't say
whether your proposals mesh with our thinking, but
whatever the outcome of that, I think we could produce a
much better system than what we have now.

If you have any messages for me you might send a note to A700RJ14 as
well as to A700PU00.

03-APR-73  0740		NET,GUE
PUB blows up on text-macros that used to work
(EXTRANEOUS `{' IN COMMAND LINE)
PUB.OLD seems to do better. What has been changed?
03-APR-73  0141		1,GG
Larry,
	We are chewing over your note of 31-Mar and trying to
understand it in the context of what we have been doing and thinking
about.  I (we) are still somewhat confused, but here goes a preliminary attempt
at some of our concerns.
	Our biggest concern is with your desire for the output
of the formatter to be device dependent with a different format
for each device.  This seems bad to us for several resons:
1)  There are an almost infinite # of devices.  e.g. each
xgp is really a different device in that each wants a different
input format because each has different interfaces with
substantially different capabilities.  Thus, every
program that wants to create ouput must know about every
device--a rather sorry state of affairs.
2)  If a document is formatted for one device & i wish to
see it on another, i must now rerun the formatter, which i
assume will take about the same amount of processing as
Pub now uses.  Besides being rather wasteful of my time
and the machine's, I'm still not very reassured that what I
see on one will look like what I see on the other --
this is a use of the devices that I very often like to
do, e.g. looking at my document on a display before printing
it on the xgp.
(got to go, more to come.  Lee)