[Oberon] Oberon for a C++ user.

[Andreas Pirklbauer]

Sorry, typo in the links. Here are the correct links:
https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Documentation/DIFFERENCES-between-Experimental-Oberon-and-Original-Oberon.pdf
https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/Kernel.Mod
https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/Modules.Mod

https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/ORG.Mod

--------------------------------------Srinivas,

The way the problem was mitigated is by checking references from other modules before unloading, and simply keeping the module in memory, as long as there are references to the unloaded module in the remaining part of the system.

It is described in section 5 of this document (forget the rest, just skip to section 5):

https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Documentation/DIFFERENCES-between-Experimental-Oberon-and-Original-Oberon.pdf


Or, if you want, you can just check out the source code that implements all this here:

https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/Kernel.Mod  (adds procedure CheckRef)


https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/Modules.Mod  (adds procedure CheckRef)


https://github.com/andreaspirklbauer/Oberon-experimental/blob/master/Sources/ORG.Mod (adds procedure variable offsets to descriptors)


Note that, as outlined in the PDF document cited above, in order for this to work, the type descriptor (and therefore also the Oberon object file format) and the descriptor for global data (e.g. global procedure variables) had to be extended with a list of *procedure variable offsets* - an idea that was originally implemented in MacOberon around 1990 and which I (essentially) adopted but also extended with a mechanism to *automatically* collect no longer referenced modules. But the changes needed to implement all that were absolutely minimal: just a few minor adaptations and only 2 (!) additional lines in the compiler (see procedures ORG.FindFlds, ORG.BuildTD, ORG.Nofrefs, ORG.FindRefs and ORG.Close) and only 3 (!) additional lines to module loader (see procedure Modules.Load). That's it!

In total, the implementation cost for all of the above was about 50-70 lines (depending on how one counts).


It completely does away with the need for finalization - which I always viewed with great suspicion (too complex, too many issues, seems like tinkering with the symptoms rather than with the root cause).

Andreas
------------------------------------------------------------------------> Srinivas Nayak sinu.nayak2001 at gmail.com > Sat Nov 12 08:39:10 CET 2016
> Yes, Andreas wrote...
> "The case of inheritance (type extension in Oberon) is now fully covered in the latest version of safe module unloading in Experimental Oberon. ..."
> Can anybody please summarize how he mitigated the problem?> I was thinking, Finalization can help us here.> But, interested to know the approach taken by Andreas to barring such deviousness.
> With thanks and best regards,
> Yours sincerely,> Srinivas Nayak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20161113/d1be8651/attachment.html>