OpenEuphoria

Re: Falling Speckles Exercise

• Posted by Robert Craig <robert_craig at COMPUSERVE.COM> Apr 26, 1997
• 862 views

James Powell writes:
> Also, if you find out exactly what was happening with the Causeway extender
> when I was writing off the screen, I am sure everyone would like to hear
> what it was, so that similar mistakes can be avoided.

I found that fall.ex was not writing off the screen, but it
was sometimes poking just beyond the 64000-byte area of memory
that was allocated using allocate(). You might have to run it
for several seconds before enough damage would be done to cause
a crash when you hit a key.

I don't know what may have been stored in the area of memory
beyond your allocated area. Perhaps you were trashing some
other block of memory containing data structures needed by
Euphoria or Causeway.

> Wow!  Can the disk error be traced back to fall.ex?

I'm not sure now. I think I crashed some other (non-Euphoria)
program before I started playing around with fall.ex.

When a program (written in Euphoria or any other language)
terminates badly, there is some potential for file system
damage. Being paranoid, I usually run scandisk immediately to
check for and repair any damage. If a bad crash happens when your Euphoria
program is doing a lot of swapping, the swap file might have to be cleaned up
by scandisk. By running scandisk and correcting problems right away,
you avoid getting into more severe file system problems later on.

Euphoria normally protects you by catching subscript out-of-bound
errors and so on, and you should rarely see a Causeway error.
However when you use poke(), mem_copy(), dos_interrupt() etc.
Euphoria does not protect you, and you have to be extra careful
to avoid nasty problems.

Regards,
  Rob Craig
  Rapid Deployment Software