release-2.2

This release features a single bugfix, relating to handling newline-tokens after REM statements.

• Reported in #122, by @donproctor.
  • Resolved in #123.

As part of that the CI process was updated to disable the use of the buildvcs flag.

release-2.1

This release features a few minor changes to our internals, and a single correctness fix:

• It is now possible to specify a Context when creating an interpreter.
  • This is useful if you embed the package and wish to avoid DoS attacks, via infinite loops and similar.
  • Reported in #116, and resolved in #118.
• Without using whitespace we now do a better job of differentiating between subtraction and the use of negative literals.
  • Reported in #120, resolved in #121
• We've updated our fuzz-testing implementation to use that available natively within recent releases of the golang toolchain.
  • Reported in #117, and resolved in #119.

Issues reported in the future will continue to be addressed, but otherwise I think this is a nice stable and complete point at which to leave the project so I don't anticipate making significant updates going foward.

release-2.0.1

release-2.0.1

The previous release, release-2.0, did not contain the associated binary resources.

This release fixes that problem. There are no functional changes.

release-2.0

release-2.0

This release features a small number of updates and new features, as well as improvements to the linting which is carried out via the Github Actions every time a pull-request is submitted or merged.

New features include:

• Allow users embedding the interpreter to setup input/output streams, added in #98
• Removal of mandatory newline on output, added in #101.
• Addition of the SPC primitive, in #104.
• LOG as a synonym for LN.
• Updated example scripts/contents in #103.
• Allow string multiplication (PRINT "*" * 80), added in #114.

I've updated the installation instructions to work with newer releases of the golang toolset too.

release-1.9

This release contains no functional changes; it is being made solely to transition the testing and release process from TravisCI to github actions:

• github-action-tester
  • Used to run tests.
• github-action-publish-binaries
  • Used to make releases.

release-1.8

This release makes a small number of improvements to the interpreter:

• Allow assignments without LET.
  • #80
• Allow DATA to be READ into an array-variable.
  • Previously only scalar-variables could be the target of READ.
  • #88
• Publish binaries for Microsoft Windows.
  • #84
• Mentioned some of our limitations, and limit the scope of the project in our README.md file.
  • Specifically this section of the README.md file.
  • #79
• We now correctly ignore DATA and DEF FN statements inside comments.
  • #93
• We've added the SWAP primitive to allow exchanging two variable contents.
  • This is demonstrated in the 100-array-sort.bas example program.
  • #90

release-1.7.1

This release includes two minor changes:

• GOTO becomes optional in IF statements:
  • #83
• Added support for go modules:
  • #74

The former change is the only user-visible one, and it allows the following two lines to be treated as identical:

• 10 IF A < 10 THEN GOTO 300 ELSE GOTO 400
• 10 IF A < 10 THEN 300 ELSE 400

release-1.7

This release focuses upon improvements to error-handling, and resilience, both as a result of extensive fuzz-testing.

I've successfully run fuzz-testing for 28 hours without a single error now - ignoring "crashes" which were the result of timeouts, due to infinite loops & etc:

  2018/12/23 21:57:45 workers: 1, corpus: 456 (1h20m ago), 
    crashers: 292, restarts: 1/1213, execs: 7742522 (75/sec), cover: 2107, uptime: 28h42m

I don't believe there will be any user-visible changes except for the handling of GOTO/GOSUB statements that pointed to invalid lines. In the past this program would result in an infinite loop:

 10 PRINT "Hello, Steve\n"
 20 GOTO 2000

This was caused by the "GOTO" statement looking for line 2000, not finding it, and jumping to line zero. Now a GOTO/GOSUB statement which points to a missing line is a fatal error.

release-1.6

This release was primarily aimed at improving the correctness of FOR loop handling, with regard to the handling of the termination condition (#73).

In addition to the bugfix of looping we added the ability to initialize 1D and 2D arrays, via the new DIM statement, this was implemented in #76, and the following example demonstrates their use:

 10 DIM a(10)
 20 LET a[3] = 3
 30 LET a[4] = "steve"
 40 FOR I = 0 TO 9
 50   PRINT I, a[I], "\n"
 60 NEXT I

2D-arrays are initialized as:

   10 DIM foo(10,10)

And get/set works as you'd expect:

    20 LET foo[3,3] = "*"
    30 PRINT foo[3,3], "\n"

release-1.5

This release, once again, focuses upon implementation cleanups.

The code base now has 98% test-coverage! That doesn't mean the interpreter is bug-free, but it does mean that some kinds of errors should now be detected by me, before users.

New Features

• It is now possible to construct an interpreter from a string, without needing to know about the tokenizer class.
  • See eval.FromString().
• 98% test-coverage of our internal implementation!
• FOR loops can now use a calculated expression for the STEP token. For example:
  • FOR I = 0 TO 20 STEP 1 + 1

BugFixes

• Numerous minor bug-fixes.
  • Partly as a result of the increased/reworked test-coverage.
  • Some more found via fuzz-testing.

Breaking changes:

The New() function, which is the constructor for the eval package now returns a second value, which can be used to detect errors in parsing the program at load-time.

(Programs are parsed at run-time, before they're executed, to process DATA and DEF FN statements. It might be possible to call these at run-time, but it is preferable to catch errors sooner rather than later.)