From Newsgroup: comp.lang.forth

In another thread discussing object-oriented Forth, I used my program epr-sim.4th as an example of using the compact OO system, mini-oof.4th. Running epr-sim.4th under the latest development versions of both
kForth-64 and kForth-32 results in a seg fault.

To reproduce the bug,

1. start kforth64 (v0.6.0) / kforth32 (v2.6.0)
2. "include epr-sim.4th"
3. Press menu option 'C' (continuous emitter).

This happens with the latest versions, above, but works in earlier
versions kForth-64 v0.5.1 / kForth-32 v2.5.0.

For kForth-64, a bug was introduced at git commit e3f3b8e in which
substantial revisions were made to the virtual machine. The latest
development versions passed all of the Forth system tests I use to
validate the system. These tests are provided in the git repo (under forth-src/system-test) but they failed to catch the current bug.

Interestingly, the fast versions of the latest kForth-64 and kForth-32 (kforthxx-fast) run epr-sim.4th properly. The VMs are substantially
different between the regular and fast versions.

--
Krishna Myneni




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.forth

On 10/4/25 9:53 PM, Krishna Myneni wrote:

In another thread discussing object-oriented Forth, I used my program epr-sim.4th as an example of using the compact OO system, mini-oof.4th. Running epr-sim.4th under the latest development versions of both
kForth-64 and kForth-32 results in a seg fault.

To reproduce the bug,

1. start kforth64 (v0.6.0) / kforth32 (v2.6.0)
2. "include epr-sim.4th"
3. Press menu option 'C' (continuous emitter).

This happens with the latest versions, above, but works in earlier
versions kForth-64 v0.5.1 / kForth-32 v2.5.0.
...

Found and fixed the problem. It was a bug within the non-standard word
USLEEP. Updates pushed to kForth-64/32 repos on GitHub. epr-sim.4th runs properly under the new versions of kForth-64 (0.6.1) and kForth-32 (2.6.1).

--
Krishna Myneni

--- Synchronet 3.21a-Linux NewsLink 1.2