Query about blank lines

[wopian]

After checking about 10% of the CONIC_SUBROUTINES.agc file, I've noticed that the digitisation is only using empty lines on lines marked as R0000 and ignores fully blank lines. However, outside of this file I've noticed in many places these fully empty lines have sometimes been included - the usage seems pretty inconsistent.

Which would be best to make this as accurate to the source files as possible?

cc @chrislgarry @rburkey2005

---

Example (Page 1266

This page has a mixture of empty lines marked with R0000 and empty lines with no line number.

The raw digitalised file has only used the R0000 empty lines (plus an erroneous blank line within the list)

Vs. this version that includes the empty lines with no line number

[oldmud0]

I believe that lines that do not have a corresponding line number are not part of the source code, so they should not be included. I think the final goal here is that every line number in a file corresponds to the line number in each page, so it's a 1:1 transcription. Of course though, we leave for last the actual removal of the page numbers from the code.

[chrislgarry]

Empty lines in the original should be empty lines here. Empty lines with a number at the beginning should be empty lines with a number at the beginning. The scans are the ground truth. This could be a bit of work. Lets use the broken windows theory and just make such fixes whenever we touch a file that happens to have this issue. Once we work our way through higher priority issues, we can focus on these. If we are at that point, then by all means. After a couple weeks, I am just now catching up on where we are at with everything.

[wopian]

@oldmud0 @chrislgarry we'll never get a 1:1 transcription.

The source code has multiple lines of code for some lines - i.e line 0119 has 01191 to 01199, then resumes with line 0120.

Page 1028

Other pages have duplicated line numbers - where one has code and another is 'empty'

{Page 1029](http://www.ibiblio.org/apollo/ScansForConversion/Comanche055/1029.jpg)

I'm veering more to keeping the empty lines as they're shown in the source images - whether they have a line number or not, since the readability of the code gets pretty poor in some places - such as here

[oldmud0]

Hmm.. I guess it comes down to best judgment.

[jimlawton]

Page 1028: I always assumed that these were cards that had been inserted into the source deck, and this numbering was used to avoid having to renumber subsequent cards, but I could be completely wrong about that.

The images are scans of "listings" not source code, i.e. they are one of the outputs of the GAP cross-assembler (along with object code, etc).

With respect to 2 lines with the same number, e.g. the page 1029 example above, the second page 0174 is not part of the source deck. The assembler is indicating that card 0174 in the source deck occupies 2 words in memory.

Finally, with respect to the blank lines, I would keep them. Possibly the original source deck had linefeed cards that are not otherwise represented in the listing (we'll never know I guess), but it does look like the vertical spacing is intentional.

[rburkey2005]

From my standpoint, question like this revolve around /criteria/, and I
admit I'm not fully clear on what your criteria for the work that's
being done are. For example, my criteria for the original
transcriptions we did was that the binary produced by my assembler,
yaYUL, had to 100% byte-for-byte match the binaries produced by the
original project's assembler -- which as Jim says was GAP by the time of
Apollo 11, though it was originally a different program, YUL. That,
then, served to demonstrate that the operational portion of the source
code was correct. Given that that was accomplished, I then wanted the
comments in the source code to match 100% as well, but we only had
limited resources and so were not able to always accomplish that. As
far as blank lines are concerned, I was happy with 1 line, for
readability, but I had no interest in multiple blank lines in a row, and
left them out. So by /my/ criteria, if you're working to cross-check
yet once again the source code, as well as to correct the comments, and
if it still assembles 100% byte-for-byte correctly, you're doing all I
would have hoped for.

As Jim also points out, the online page scans are not the original
source code, they are a printout from GAP. yaYUL now produces similar
printouts, except in much more readable form, with colorized syntax
highlighting and hyperlinks, all of which are posted online already
(see, for example,
http://www.ibiblio.org/apollo/listings/Comanche055/MAIN.agc.html).
They're not formatted quite the same as GAP did, for practical reasons.
I don't recall precisely, but I expect yaYUL is going to remove any
superfluous material (such as more than one blank line in a row) from
its final printout anyway. Keep them or not, as you wish, as long as
(according to my criteria) the binary output of the assembler is 100%
correct. yaYUL will also, I think adjust the column alignment of the
operand and comment fields.

As I understand it, GAP didn't operate directly from the card decks. I
believe that the cards were read into a magnetic-tape memory library, at
which point the cards became irrelevant until corrections had to be
made, and assemblies were all done from the material stored in the
library. Whether this process preserved extraneous info like extra
blank lines, I can't say.

Jim says we'll never know about the original intentions behind the blank
lines, but we can probably find out if you're really excited to know.
We can ask Hugh Blair-Smith, one of the original programmers, and the
writer of GAP. I'll do that, if you like, but I'd like a fairly
precisely-worded question before doing so. If the question just "should
we keep them or not?", I don't think he'll have any more insight into
the matter than I do ... but perhaps he would.

-- Ron

On 08/15/2016 04:18 AM, Jim Lawton wrote:

Page 1028: I always assumed that these were cards that had been
inserted into the source deck, and this numbering was used to avoid
having to renumber subsequent cards, but I could be completely wrong
about that.

The images are scans of "listings" not source code, i.e. they are one
of the /outputs/ of the GAP cross-assembler (along with object code, etc).

With respect to 2 lines with the same number, e.g. the page 1029
example above, the second page 0174 is not part of the source deck.
The assembler is indicating that card 0174 in the source deck occupies
2 words in memory.

Finally, with respect to the blank lines, I would keep them. Possibly
the original source deck had linefeed cards that are not otherwise
represented in the listing (we'll never know I guess), but it does
look like the vertical spacing is intentional.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALSveOU5whySpuBqZegGuzkQx4yTF5dtks5qgC76gaJpZM4Jc9E6.

[oldmud0]

If these are just GAP printouts, then where is the original source code?

[jimlawton]

It was originally on punch card decks, then at some point in 1965 or so, they moved it to magnetic tapes. The actual builds for the flights were done from those mag tape libraries. I guess those mag tapes were lost a long time ago. The printouts survived because people kept them as souvenirs.

[rburkey2005]

If you're responding to what Jim Lawton and I said, perhaps I wasn't
clear. The page images posted at VirtualAGC are scans of printouts from
GAP. The *.agc files are the transcriptions from VirtualAGC that
represent the source-code parts of those printouts. The original source
code existed only on cards and in tape memory banks, never in giant
printouts, and is therefore nowhere at all any longer, presumably. I
believe that the original programmers actually wrote the source code out
on paper, possibly on something like graph paper, and then handled it
over to a room full of WAFs who operated the keypunch machines and
created the cards, which were read into the mag tape library.

The point I was trying to make, ineptly, is that the formatting you see
in the GAP printouts existed only in the GAP printouts, and presumably
only partially reflects whatever material the original programmers wrote
down on paper, so preserving the formatting for posterity doesn't really
reflect the programmers' experience. I think.

-- Ron

On 08/15/2016 09:52 AM, oldmud0 wrote:

If these are just GAP printouts, then where is the original source code?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALSveGm0JqRK6e1QLChEnRV8qKBPnUAeks5qgH06gaJpZM4Jc9E6.

[proudindiv]

The original programmers worked mostly with the GAP printouts. They only
went to the card decks to submit changes. I programmed in that era with
similar assembler programs. I don't know about the MIT programmers, but we
programmers made the changes to the card decks ourselves and submitted or
ran them ourselves. Having another party punch the cards only adds another
layer for errors and misunderstanding. The assembler printouts were also
heavily used in debugging when referencing the contents of memory during
simulations. In our system, when the program failed, it produced a core
dump listing of the contents of memory at the time of the failure. I'm
sure the Apollo programerss did something similar on their simulation
systems. They also used a DSKY to examine memory referring to the
generated octal on the listing when simulating on the real computer. The
assembler printout is the only link to what the computer is doing.

On Mon, Aug 15, 2016 at 9:12 AM, rburkey2005 notifications@github.com
wrote:

If you're responding to what Jim Lawton and I said, perhaps I wasn't
clear. The page images posted at VirtualAGC are scans of printouts from
GAP. The *.agc files are the transcriptions from VirtualAGC that
represent the source-code parts of those printouts. The original source
code existed only on cards and in tape memory banks, never in giant
printouts, and is therefore nowhere at all any longer, presumably. I
believe that the original programmers actually wrote the source code out
on paper, possibly on something like graph paper, and then handled it
over to a room full of WAFs who operated the keypunch machines and
created the cards, which were read into the mag tape library.

The point I was trying to make, ineptly, is that the formatting you see
in the GAP printouts existed only in the GAP printouts, and presumably
only partially reflects whatever material the original programmers wrote
down on paper, so preserving the formatting for posterity doesn't really
reflect the programmers' experience. I think.

-- Ron

On 08/15/2016 09:52 AM, oldmud0 wrote:

If these are just GAP printouts, then where is the original source code?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/chrislgarry/Apollo-11/issues/
159#issuecomment-239822579>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/
ALSveGm0JqRK6e1QLChEnRV8qKBPnUAeks5qgH06gaJpZM4Jc9E6>.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#159 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AG4k0zPxgEwIqQ0oshfdhqtR_A8fvC2Yks5qgIHWgaJpZM4Jc9E6
.

[rburkey2005]

My apologies: I should have refreshed my memory about the WAF thing
before saying it. That wasn't an AGC thing at all (as has been pointed
out), but was rather something that was told to me by an MSC intern,
about his experiences in 1966 working on the engineering simulations of
various burns. To quote him, "Tedious work but it worked when we tried
it in the sim. The most fun part was taking the coding sheets to the
'swamp' for the keypunch operators to build the card decks to be taken
to the computer center. You see, the 'swamp' was a tiered auditorium
with many young women at keypunch machines on the tiers. Of course, we
young engineers would enter the room at the front at what was the focus
of the tiers--one felt a little like a bull at the rodeo
auction--without the brands on our butts, of course. For a 21 year old
it was a hell of a way to meet women--bored, horny women...." :-)

I guess my imaginary picture of that auditorium remained in my mind long
after the other details had vanished, for some reason.

On 08/15/2016 11:52 PM, proudindiv wrote:

The original programmers worked mostly with the GAP printouts. They only
went to the card decks to submit changes. I programmed in that era with
similar assembler programs. I don't know about the MIT programmers, but we
programmers made the changes to the card decks ourselves and submitted or
ran them ourselves. Having another party punch the cards only adds another
layer for errors and misunderstanding. The assembler printouts were also
heavily used in debugging when referencing the contents of memory during
simulations. In our system, when the program failed, it produced a core
dump listing of the contents of memory at the time of the failure. I'm
sure the Apollo programerss did something similar on their simulation
systems. They also used a DSKY to examine memory referring to the
generated octal on the listing when simulating on the real computer. The
assembler printout is the only link to what the computer is doing.

On Mon, Aug 15, 2016 at 9:12 AM, rburkey2005 notifications@github.com
wrote:

If you're responding to what Jim Lawton and I said, perhaps I wasn't
clear. The page images posted at VirtualAGC are scans of printouts from
GAP. The *.agc files are the transcriptions from VirtualAGC that
represent the source-code parts of those printouts. The original source
code existed only on cards and in tape memory banks, never in giant
printouts, and is therefore nowhere at all any longer, presumably. I
believe that the original programmers actually wrote the source code out
on paper, possibly on something like graph paper, and then handled it
over to a room full of WAFs who operated the keypunch machines and
created the cards, which were read into the mag tape library.

[wopian]

As far as blank lines are concerned, I was happy with 1 line, for
readability, but I had no interest in multiple blank lines in a row, and
left them out. So by /my/ criteria, if you're working to cross-check
yet once again the source code, as well as to correct the comments, and
if it still assembles 100% byte-for-byte correctly, you're doing all I
would have hoped for.

What I've been doing when cross-checking the files is: fixing typos in the comments, modifying the positioning of comments to better match what was shown in the images/GAP printouts - mainly just the paragraphs - and adding (or in the rare case removing) blank lines by however many were shown on the printouts.

Jim says we'll never know about the original intentions behind the blank
lines, but we can probably find out if you're really excited to know.
We can ask Hugh Blair-Smith, one of the original programmers, and the
writer of GAP. I'll do that, if you like, but I'd like a fairly
precisely-worded question before doing so. If the question just "should
we keep them or not?", I don't think he'll have any more insight into
the matter than I do ... but perhaps he would.

My question was indeed a simple "should we keep then or not" in the original post, however since then and looking back other past files I've cross-checked I came to notice that the single lines were mostly used for general formatting and legibility - such as separating each label and their instructions (although this appears to be inconsistent), while the double/triple lines were mainly splitting different sections of the documentation up. Page 1263 of the Comanche055 is one of the better examples of this: http://www.ibiblio.org/apollo/ScansForConversion/Comanche055/1263.jpg.

So my question is now: Was the formatting of the comments (with the multiple line breaks) the original intentions of the programmers who wrote the code, or formatting artifacts introduced in the keypunching process. As if it was intentional i'd rather these line breaks be restored.