[Oberon] Re (2): Explaining Texts.

peter at easthope.ca peter at easthope.ca
Thu Jul 26 17:42:09 CEST 2018


Joerg,

Thanks for the replies.  Certainly they help.

> On one hand you want to understand high level things like concepts and 
> abstractions and on the other hand you go down to low level things 
> like memory used.

A comprehensive understanding includes all levels of abstraction from 
lowest to highest.  If a specific error is detected, certainly I'll try 
to fix it.  You haven't convinced me yet to remove the memory column 
from the tables.  

> This memory thingy heavily depends on the compiler not on the language 
> and not on the module you want to understand.

Granted.  It's a mental exercise.  Trivial for you but possibly helpful 
to a novice.  Any other opinions out there?

> BTW: you always can find the nbr of bytes used by a type T by using  
> size := SYSTEM.SIZE(T);

Thanks.  Will have access to a V5 system again in a few days.

> https://en.wikipedia.org/wiki/Model-view-controller

Thanks.

> And you should read this documentation:
> https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf

Read it some years ago and have reread sections more recently. It 
applies to V5.  As you mentioned a few weeks ago, the TextsDesc in S3 
differs from V5.  For S3 I should return to Pieter Muller's thesis.  
Possibly also to articles in journals in the library.

> - Figure 2.2 gives you an view on how the kernel modules are layered.

For V5.  In S3 Texts is an extension of Objects.  The wikibook is 
intended to cover both.
https://en.wikibooks.org/wiki/Oberon#System_Variants

> - Chapter 5 explains Texts and its piece editor in detail.

Rereading that.

> If you implemented Text as ONE contiguous block in memory, then you 
> would have to move a lot of memory around if you insert or delete 
> text.

Yes.  I get that point.

> BTW: the two fields "pce" and "org" are not "pointers in a translation 
> cache", they are the cache. 

Thanks.  Precise use of language is essential.  In general a cache  is 
a set of any number of pairs (org,pce) or (pce,org).  A set theorist 
would insist that the distinction between the set and an element 
exists even when there is only one element.  Saying one pair _is_ the 
cache dismisses the distinction.  But I get your point that the 
distinction seems unnecessary when there is only one pair.  I'll think 
about different wording.

I'm not sure about the derivation of "org".  It's the character offset where 
the piece "originates"?

> ... minor implementation detail ...

Just a matter of completeness.  If it's there, why not explain it?  

> This cache is a minor implementation detail (optimization) of 
> "FindPiece" and not so important to understand the idea. When you want 
> to find the 3256th character ...

Nice explanation of the use of the cache.  Thanks.  I'll try to work 
it in, without plagiarized your words.  

Thanks again,                   ... Peter E.


-- 
Message composed and transmitted by software designed to avoid the 
need, overhead and vulnerability of antivirus software.

123456789 123456789 123456789 123456789 123456789 123456789 123456789
Tel: +1 360 639 0202                                                 
http://easthope.ca/Peter.html              Bcc: peter at easthope. ca


More information about the Oberon mailing list