[Oberon] FPGA - TRAP 4

[Michael Schierl]

Hello Tomas,


Am 26.05.2020 um 09:38 schrieb Tomas Kral:
> Hi,
>
> Analysing some me crashed OBERON.FS
> (backed before recovery), I found this towards the end.
>
> It is most peculiar, I admit did something wrong, yet this seems
> echoing TRAP 4 into some [free??] sectors on the disk.

No, you did not do anything wrong. Did you never wonder how it can be
that some viewers (including the Log viewer) can contain more text than
fits into your RAM?

The reason is how viewer content is stored. Basically it is a list of
Texts.Piece elements. Text that is loaded/copied directly from a
loaded/opened file creates a Piece that directly references that file,
and its text lives only in the filesystem cache that gets "swapped out"
and later loaded from disk again when there is need. And any text that
is written through a Texts.Writer, like your TRAP above, is stored in a
piece that references an unnamed file. That file is never actually
forced to be flushed to disk, but in the correct memory situation
(enough other files opened), that unnamed file will be "swapped out" and
therefore flushed to disk and you will see it in the disk sectors. As
the file is unnamed, its space will be reclaimed on the next restart of
the system.

This is also the reason why System.DeleteFiles cannot reclaim space
immediately (and why Edit.Store renames the old file to a backup file
and writes a completely new file to different sectors on the disk):
Perhaps you still have a viewer of that file open which got "swapped
out"? When that viewer is interacted with next, the content would be
lost. Therefore, free space is not reclaimed immediately, but at the
next restart.

For more details, have a look at chapter 5 (or more precisely chapter
5.2) of the Project Oberon book.


Hope this clarifies the situation a bit,


Michael