563bc20a75980dbf641d72b39b97d47ebc9c4183
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  AnachronautandClaude Opus 5
|
563bc20a75 |
Tab lists its matches in columns, and says what it can in colour
Tab's listing was six instructions: print the name, print two spaces. It was the crown of this shell for a while and looks plain next to ls. Columns cost NOTHING EXTRA. Tab already walks its candidates twice - once to find the answer, once to show the matches, and tabRunSources exists because those are the same walk asked two questions. The longest match is counted on the first, which already visits every one of them, so the listing needs no walk of its own to know how wide a column should be. Padding goes before a name rather than after, so a row ends on a name. Directories are blue and the shell's own commands are green. Both are free: Tab appends the separator itself, and a built-in is not a file at all - which is also the only way anybody could know it will run. A FILE IS NOT COLOURED, and that is a decision. Whether a file will run is a read of its first block, which is what ls does and what makes ls cost twice what it otherwise would. Here it would be worse than slow: candidates are offered from inside a directory walk, and looking a file up would overwrite the very fields holding the walk's own position. Doing it safely means holding every candidate name in memory, which is a buffer the shell would carry whether anybody pressed Tab or not - and ls is one keystroke away. A Tab press already costs about 200,000 cycles, so the read was not the objection. ---- And the machine could no longer build itself ---- Found by make test, not by reading. The native assembler ran out of room for label names on cosmos.asm: 16,758 bytes against 16,384. The index was 1,341 of 1,536 in the same breath. Which is scratch.asm's own warning happening a second time - "two ceilings a hundred bytes apart look like one ceiling until the first is lifted" - so both were raised, out of the seventeen kilobyte page that file deliberately left unclaimed against exactly this. Names to 26,624 and the index to 2,048, both left about a third clear, with 1,792 bytes still unclaimed for the same reason. A name is thirteen bytes on average and an index entry is four, so the arena will always be the one that speaks first. That is now written down where the two numbers are. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW |
||
|
AnachronautandClaude Opus 5
|
3c76934a9a |
Tab reaches the disk
Paths and programs, which is the half that makes it worth having. The first word of a line is a command or a PROGRAM, offered under the name somebody would type - the extension taken off - and anything after it is a file, offered as it really is. A separator anywhere in the word says which directory to look in. A directory answers with a separator on the end instead of a space, which says what it is and lets the next part be typed straight away. The answer ending in one is also what stops a space being added, so that is one test rather than a flag. PROGRAMS ARE LOOKED FOR WHERE THE SHELL WOULD LOOK to run one: where you are, /Apps on the disk you are on, and /Apps on drive 0. Offering something the shell would not find would be finishing a word into a thing that then does not work. Drive 0's is skipped when that is already the drive, or every program in it would be offered twice and nothing would ever be the only match. Walking somebody else's directory means standing in it, which is the only way to walk one here, so where the person was and which drive they were on are put down first and restored whatever happens. Three bugs, all found by running it: THE DIRECTORY TEST WAS INVERTED. dir asks the same question the same way round four hundred lines further up, which is what made it obvious once looked at. THE /Apps WALK OVERWROTE THE TYPED PATH. The whole search runs a second time to list the matches, and by then TabDir said "/Apps" - so a word that had named nowhere went looking in the wrong place and listed nothing at all. Two ways into the walk now, and the typed path is never written over. AND LISTING ONLY KNEW ABOUT COMMANDS, because it was a second copy of the walk. It is the same walk with a flag now: finding the answer and showing the matches are the same question asked twice. Also cosmosMonitor, which had been RE-BLESSED INTO MEANINGLESSNESS by the wall move. It disassembles a loaded program, at an address the input names - and that address moved a page while the recording was simply re-recorded to whatever came out, which was a page of zeroes. It is pointed at 5000 again. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW |
||
|
AnachronautandClaude Opus 5
|
bb065fe221 |
Tab finishes a word somebody started
The first word of a line, against the shell's fifteen commands. One match goes in with a space after it, because a word that can only be one thing is finished. Several are folded into their longest common prefix and that goes in, which is the most that can be said without guessing which was meant - and if that adds nothing, the matches are listed and the line put back underneath. THE LINE COMING BACK IS THE HALF I EXPECTED TO BE HARD and it was already solved. The prompt has been reprinted somewhere else entirely, so the editor's idea of where the line begins is wrong - but editAnchor works that out backwards from where printing ended, precisely so it survives the screen moving. Listing is a redraw it already knew how to do. editInsert became editPut, a routine, because completing a word puts in several characters and every one of them is that. Which cost a bug immediately: the old inline code left the insertion point in A, and a RET puts A back to what the caller had. Two more bugs worth naming, both mine and both the same shape - a pointer that had moved: THE CANDIDATE'S START HAS TO BE KEPT. The comparison walks DP3 through the name as it matches, so by the time a match is declared, DP3 points at the part AFTER what was typed - and that is what got copied. "he" completed to "he" because the answer taken was "lp". AND THE INSERTION STOPS AT OR PAST, not exactly equal. With the wrong answer the two counters passed each other and the loop ran off the end of the buffer, filling the line with whatever was next in memory. They cannot pass each other now, and the branch stays, because the cheaper failure is worth nothing. MY OWN TEST HAD A HOLE and breaking the code found it. The later-word case pressed Tab after a space, where there is nothing to finish anyway, so it passed whether or not the shell checked which word it was on. It types "echo he" now, which would become "echo help" if it did not. The assembler's label table went past 1024 and is doubled. A ceiling reached once will be reached again, and it is pointers into source already in memory. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01E2JrLzFvuFX9fgi1LDRjrW |