[Oberon] Explaining Texts.

[eas lab]

Jorg wrote:--
> So, Text has a cache of the last found position (org = 3256, and pce is
the piece, where postion "org" is in). If you search for the piece where
the 3260th character is in, you start from this cache instead from position
0 again.
--------
? That's why *nix is much faster for the immediate repeat of any
text-searching, eg:
 locate <token>


On Thu, Jul 26, 2018 at 2:53 AM, Jörg <joerg.straube at iaeth.ch> wrote:

> Peter E.
>
>
>
> 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.
>
> To overcome this: We introduce the idea of piece; a piece is a contiguous
> block of text (characters) in memory. A Text is a list of pieces.
>
> So, if you read-in an ASCII text from a file, the Text consist (in the
> beginning) of only ONE piece; all the ASCII characters are contiguous in
> memory and represented by one piece.
>
> Now, if you eg delete char 300 to 309 of that text, this one starting
> piece is spilt in two: first piece points to characters 1..299 the other
> piece points to 310..end. So, you deleted 10 characters without moving any
> memory around.
>
>
>
> BTW: the two fields "pce" and "org" are not "pointers in a translation
> cache", they are the cache. 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 in the Text, you basically have
> to go through all pieces in the list one by one and add up the piece's
> length until the sum is larger than 3256. Then you found the piece, where
> the 3256th character is in.
>
> As it is very often the case that you move the cursor back and forth or up
> and down, it is handy not do the whole piece length summation again and
> again. So, Text has a cache of the last found position (org = 3256, and pce
> is the piece, where postion "org" is in). If you search for the piece where
> the 3260th character is in, you start from this cache instead from position
> 0 again.
>
>
>
> br
>
> Jörg
>
>
>
> Am 26.07.18, 07:57 schrieb "Jörg" <joerg.straube at iaeth.ch>:
>
>
>
>     Peter E.
>
>
>
>
>
>
>
>     You have a "strange" approach: 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.
>
>
>
>     In my whole career I was only interested in the nbr of bytes and
> internal element memory alignment rules when I wrote compilers.
>
>
>
>     In my point of view, it's not too useful to understand Texts when you
> know how much memory a Piece occupies. This memory thingy heavily depends
> on the compiler not on the language and not on the module you want to
> understand.
>
>
>
>     BTW: you always can find the nbr of bytes used by a type T by using
> size := SYSTEM.SIZE(T);
>
>
>
>
>
>
>
>     Before going down to this detail, it is more important to understand
> this model:
>
>
>
>     https://en.wikipedia.org/wiki/Model–view–controller
>
>
>
>
>
>
>
>     This basic mechanism of separating data from user interface is used by
> Texts (data model) and TextFrames (user interface).
>
>
>
>
>
>
>
>     And you should read this documentation:
>
>
>
>     https://www.inf.ethz.ch/personal/wirth/ProjectOberon/PO.System.pdf
>
>
>
>     - Figure 2.2 gives you an view on how the kernel modules are layered.
>
>
>
>     - Chapter 5 explains Texts and its piece editor in detail.
>
>
>
>
>
>
>
>     br
>
>
>
>     Jörg
>
>
>
>
>
>
>
>     Am 26.07.18, 06:44 schrieb "oberon-bounces at lists.inf.ethz.ch im
> Auftrag von peter at easthope.ca" <oberon-bounces at lists.inf.ethz.ch im
> Auftrag von peter at easthope.ca>:
>
>
>
>
>
>
>
>         Hi,
>
>
>
>
>
>
>
>         For me, one the bigger difficulties in understanding the system is
>
>
>
>         from the multiple layers of abstraction. An intention in
>
>
>
>         https://en.wikibooks.org/wiki/Oberon#Oberon_Text
>
>
>
>         is to encapsulate abstractions concisely together.
>
>
>
>
>
>
>
>         Understanding the relationship of an abstraction to something
> concrete
>
>
>
>         can also help.  Hence the "Memory Occupied" column in the tables.
> Is
>
>
>
>         that information helpful or distracting or misleading?
>
>
>
>
>
>
>
>         Thanks,                 ... 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
>
>
>
>         --
>
>
>
>         Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related
> systems
>
>
>
>         https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
>
>
>
>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20180727/b0902f33/attachment.html>