Right now there are lots of tests in the Rust code and none in the TypeScript code. We don't have an unit testing infrastructure set up.

We need it, as he TypeScript code continues to grow in size and complexity.

This FR isn't asking for the writing of unit tests, just setting up the machinery to run them:

1. During development
2. From GitHub actions for PRs and pushes.

The github actions enforce that code changes on the Rust code adhere to best practices in code formatting, linting and so forth.

But similar checks don't exist for the web UI code (mainly TypeScript, CSS). We should at least run a linter. And, ideally, verify that the code is correctly formatted (I'm not very opinionated about what formatting choices to take, but consistency would be a good thing).

Describe the bug The current implementation of the exchange element (exchanger.rs) is based on the content of table 7-2 in the Users Handbook.

But, you compare the examples for config 2 in the descriptions of LDA (page 3-6) and STA (page 3-8) the movement appears to be opposite. See example number 3 in each case.

The existing code appears to match the load case, not the store case. Execution of stores appears to show backward behaviour compared to the examples in the STA documentation.

To Reproduce N/A

Expected behavior I am not 100% clear on this. For example what happens with sign extension and subword form?

Additional context The problem manifested in the intiial implementation of the STE opcode, but so far the boot code only makes use of config value 0 (full word, all quarters active). That probably explains why I did not previously see a problem.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [x] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [x] Your changes include unit tests (if they are code changes).
  • [x] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [ ] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [x] Your changes include unit tests (if they are code changes).
  • [x] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Not closing #68 yet as we need a test program to demonstrate that this works.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [x] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [x] Your changes include unit tests (if they are code changes).
  • [x] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [ x Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x ] You have done your changes in a separate branch.
  • [x ] You have a descriptive commit message with a short title (first line).
  • [x ] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x ] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [ ] Your changes include unit tests (if they are code changes).
  • [ ] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [ ] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [ ] Your contribution is made under the project's copyright license.
  • [ ] Make sure that your PR is not a duplicate.
  • [ ] You have done your changes in a separate branch.
  • [ ] You have a descriptive commit message with a short title (first line).
  • [ ] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [ ] Your changes include unit tests (if they are code changes).
  • [x] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

The motivation behind this was to definitiely identify which wasm file is being used for profiling mode, because we want to be able to identify which Rust function is being executed, instead of seing just numbered WASM functions.

This change doesn't solve that problem, but it does mean that we know a priori that the WASM file we're looking at is indeed the one build for profiling mode.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [x] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [ ] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [ ] Your changes include unit tests (if they are code changes).
  • [ ] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [ ] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [ ] Your changes include unit tests (if they are code changes).
  • [ ] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

The motivation behind this was to definitiely identify which wasm file is being used for profiling mode, because we want to be able to identify which Rust function is being executed, instead of seing just numbered WASM functions.

This change doesn't solve that problem, but it does mean that we know a priori that the WASM file we're looking at is indeed the one build for profiling mode.

Pull Request template

Please, fill in the following checklist when you submit a PR. The items you have done should be updated with a check mark (that is, [x] instead of [ ]).

• General
  • [x] Review the CONTRIBUTING.md file for detailed contributing guidelines before sending a PR.
  • [x] Your contribution is made under the project's copyright license.
  • [x] Make sure that your PR is not a duplicate.
  • [x] You have done your changes in a separate branch.
  • [x] You have a descriptive commit message with a short title (first line).
  • [x] You have only one commit. If not, either squash them into one commit or contribute your change as a sequence of smaller Pull Requests.
• Basic sanity checks
  • [x] You have run runchecks.sh and it said "Everything is OK".
• Testing and Documentation
  • [x] Your changes include unit tests (if they are code changes).
  • [ ] If your change relates to the behaviour of the simulator, please include comments explaining which part of the reference documentation describes the thing you're changing.
• If your change is a bugfix and it fully fixes an issue:
  • [ ] Put closes #XXXX in your pull request description to auto-close the issue that your PR fixes.

If any of the checklist items don't apply, please leave them un-checked.

PLEASE KEEP THE ABOVE IN YOUR PULL REQUEST.

Describe the bug The gap between consecutive lines of the Lincoln Writer 66 output on a Pixel 4 XL is slightly smaller than the gap between the last line of history and the "current" line. This produces a mild rippling effect as output lines are completed.

To Reproduce

1. Visit https://tx-2.github.io/demo/ on a mobile device.
2. Follow the getting-started instructions to load and run the "hello" tape.
3. Observe the "ripple" effect as the output is generated.

Expected behavior Output scrolls up with no discernible difference between the final two lines and any other pair or adjacent lines.

Screenshots Not at this time.

Platform and version information: Pixel 4XL, Android version 12. Reproduced with version 2d5f01642251dbabbe818e5db016b723dad454c9

Additional context This does not occur on the desktop Chromium instance I use for development. I don't know whether this affects other mobile devices.

In tx2-web/src/AlarmPanel.tsx there are callbacks into controller/alarm.ts, and also callbacks in the opposite direction. With a callback registry.

There is a similar picture between tx2-web/src/IoPanel.tsx and controller/io.ts.

This seems more complex than necessary. Someone more experienced with React than I am can likely suggest a simpler approach.

I think some of the design choices in the UI implementation have bad performance characteristics. For example, we update the I/O and Alarm status panels after every instruction. This could be the reason why it takes the simulator several seconds to read the 360 lines of the "hello.tape" example program even though (1) the data is in memory, and (2) the simulated tape reader should be able to do this in under a second.

I'd like this code to be usable on portable devices (e.g. tablets) and it needs to not eat battery.

The web UI includes instrucitons. These are important for helping people try the simulator out for the first time. But, once the user has read them they don't need to refer to them again, probably. It would be helpful for the user to be able to reduce the on-screen space taken up by the instructions once they've read them.

Is your feature request related to a problem? Please describe.

The assembler's error-handling strategy is modeled after https://eyalkalderon.com/blog/nom-error-recovery/ but our use of the "placeholder" denoting that we came across an invalid input is not comprehensive.

For example, this line of input is perfectly valid:

100|      REX₆₆   200     ** Set X₆₆ to 200.

If we add an extra symbol in there like this:

100|      REX₆₆   EXTRA 200     ** Set X₆₆ to 200.

We get a somewhat confusing error:

11:508: expected newline after a program instruction
11:508: expected end-of-file
2022-05-16T08:51:58.375986Z ERROR assemble{input="assembler/examples/hello.tx2as" output="hello.tape"}: tx2m4as: assembly failed: AsmFail(SyntaxError { line: 11, columns: Some((508, 3505)), msg: "expected newline after a program instruction" })
line 11, column 509: expected newline after a program instruction

Describe the solution you'd like An error message which is more understandable, making use of the existing LocatedSpan code to show the invalid/unsupported input.

Describe alternatives you've considered I'm hoping that the overall pattern described in Eyal Kalderon's blog post will be sufficient to give a good user experience.

Additional context See above for an example output.

The AE registers (A, B, C, D) are stored in the Arithmetic Element. E is stored in the Exchange Element, but is also described as an Arithmetic Element register. They are mapped into the Vff memory range.

I have a fuzzy recollection that they don't have metabits and so netabit operations take effect on the M register but have no effect on the actual AE registers themselves. But I can't right now find a spot in the documentation that talks about this.

The necessary action here is to find the relevant documentation and add tests relating to it. For example use of the SKM instuction on the addresses corresponding to some of the AE registers.