December 2016 - Oberon - mailman3.inf.ethz.ch

Re (2): System.Directory; was Re (2): Oberon and TLS;
by peter＠easthope.ca 17 Dec '16

17 Dec '16

On 12/16/16, eas lab <lab.eas(a)gmail.com> wrote: > Your examples are all restricted to /usr/aos/ Pick a directory. Any directory. System.Directory /../../* /../run /../var /../lib /../sys /../security /../bootpart /../bin /../srv /../opt /../versions /../dev /../mnt /../root /../etc /../proc /../usr /../runin /../boot /../home /../media /../sbin /../tmp 22 files System.Directory /../../versions/* /versions/run /versions/running /versions/pristine /versions/updates /versions/sticky /versions/contents 6 files System.Directory ../olr/test/* /home/olpc/olr/test/t2 /home/olpc/olr/test/t1 2 files -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Text.Buffer usage.
by peter＠easthope.ca 16 Dec '16

16 Dec '16

In http://www.ethoberon.ethz.ch/ethoberon/defs/Texts.Def.html , (* Open a new text buffer B. *) PROCEDURE OpenBuf (B: Buffer); Note 3. at the end of the page explains, "Buffers contains large sequences of objects (both character and non-character) and allow low-level temporary manipulation. ... To prevent broadcasts being sent for potentially each character being written into a text, the text manipulation is first done in a buffer. Operations on buffers do not result in update messages being broadcasted. How is the manipulation of the buffer performed? Append a character to a buffer for example. There is no procedure WrtieBuf(b: Buffer; c: CHAR). Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Oberon and TLS;
by peter＠easthope.ca 14 Dec '16

14 Dec '16

Greetings Everyone, it's Xmas break, >From lab.eas at gmail.com Mon Jan 18 19:08:45 2016 > Can it handle the <TLS> protocol needed for gmail; Definitely. The Oberon subsystem receives and sends via localhost. Every *nix localhost can provide TLS. Receiving through a stunnel tunnel. Sending via Exim usually. Setup is almost routine. http://easthope.ca/UnixAosUsage.html When there is time I'll add some details about Exim. If you have any difficulty please reply. It should be clear as vodka. But don't overdo it because of the season and watch for hasty reindeer. Regards, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

2 1

Safe module unloading
by Andreas Pirklbauer 13 Dec '16

13 Dec '16

See responses inline below.. ------ > Lars noreply at z505.com > Tue Dec 13 13:51:23 CET 2016 > > Complete source code (modules Kernel, Modules): > > http://github.com/andreaspirklbauer/Oberon-experimental > > > Hey I saw that you have some movies/videos of oberon, in "mov" file > format.. might be useful to upload them to youtube and link to them as > when I click the mov file it does not play the video The videos can/will be uploaded to Youtube. > Also, with experimental oberon, does that mean that if I buy an > oberonstation I can install experimental oberon on it rather than the one > that it ships with? Sorry, I'm a newbie to this.. Yes, one can install Experimental Oberon on an Oberon station (instructions to upgrade from an existing Original Oberon installation are on the Experimental Oberon page; then just create an image using the building tools that are part of Experimental Oberon). > And, is experimental oberon ever going to work with the original oberon> code developer or it will remain a separate fork with no real input back> into the original source tree.. There is in a backward-compatible version of Experimental Oberon on the Github page as well. However, it does not contain all features. It would be an easy task to make the full Experimental Oberon backward compatible with Original Oberon, but I have refrained from doing so, for several reasons: it would lead to code duplications just for compatibility reasons, some modules of Experimental Oberon (MenuViewers, Viewers) are (will be) actually *simpler* than Original Oberon and that property would go aways, etc. I don't think Experimental Oberon will ever be merged back into Original Oberon. The two systems pursue different goals. Original Oberon tries to be minimalistic, so even the rather basic task of continuous scrolling - which makes the Oberon GUI considerably easier and much more natural to use, with zero initial learning curve - would be considered as "unnecessary bells and whistles". Original Oberon also does not really care that the user can put the system in an unsafe state merely by e.g. unloading a module (Oberon is an unsafe system anyway, in the sense that any user can just delete any system-critical file to break the system). By contrast Experimental Oberon believes in *sensible" extensions (think: 100-200 lines per added feature, not more) that add real value, e.g.,- completely safe module unloading (50 lines) .. for increased safety- virtual displays (100 lines).. important for touch devices- continuous line scrolling (200 lines).. making the GUI much easier to use etc.

1 0

"Check error" from LinuxAos.
by peter＠easthope.ca 13 Dec '16

13 Dec '16

Hello Guenter and anyone interested, When LinuxAos 6661 begins, "Check error" is repeated about 24 times in the AOS.nnnnn.Log. Autostart: executing PET.Open pe.Oberon.Mail.Mod {P cpuid= 0, pid= 51 Starting logger} SyntaxHighlighter: Auto-loading SyntaxHighlighter.XML ... done. ******* Check error ********** 1699 ******* Check error ********** 1720 ... ******* Check error ********** 3537 What is the significance of the Check errors? Related to PET or something else? Some inputs allow a small procedure added to Oberon.Mail.Mod to freeze the system. I want to understand the Check error a little before tackling the system freeze problem. Thanks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 Tel: +1 360 639 0202 Pender Is.: +1 250 629 3757 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Safe module unloading
by Andreas Pirklbauer 13 Dec '16

13 Dec '16

Given that - thanks also to the input received from this community - the semantics of "safe module unloading", as implemented in Experimental Oberon, has somewhat evolved over time, I have been asked to provide an updated description of the current status quo: Safe module unloading The semantics of unloading a module has been refined as follows. If clients exist, a module is never unloaded. If no references to the module exist in the remaining modules and data structures, it is unloaded and its associated memory is released. If there are references, however, the specified module is initially removed only from the list of loaded modules, but will later be automatically removed from memory as soon as there are no more references to it. Such references can be in the form of type tags (addresses of type descriptors) in dynamic (heap) objects of other modules pointing to descriptors of types declared in the specified module, or in the form of procedure variables installed in static or dynamic objects of other modules referring to procedures declared in that module. Modules that have been removed only from the list of loaded modules (hidden modules) are marked with an asterisk in the output of the user command System.ShowModules. To achieve their automatic final removal from memory, the Oberon background task handling garbage collection includes a call to the command Modules.Collect. Thus, module data is kept in memory as long as needed and is removed from it as soon as possible. In sum, unloading a module affects only future references to it, while past references from other modules remain completely unaffected, For example, older versions of the module’s code can still be executed if they are referenced by procedure variables in other loaded modules, even if a newer version of the module has been loaded in the meantime. A simple mark-scan scheme is used to check dynamic references to a module. In the mark phase, dynamic records reachable by all other loaded modules are marked. This excludes records that are reachable only by the module itself. The scan phase scans the heap element by element, unmarks marked objects and verifies whether the type tags of the encountered marked records point to descriptors of types declared in the module to be unloaded, or whether procedure variables in these records refer to procedures declared in that module. The latter check is also performed for all static procedure variables. In order to make such a validation pass possible, type descriptors for dynamic records and descriptors of global module data have been extended with a list of procedure variable offsets, adopting an approach employed in one of the earlier implementations of Oberon. These additional offsets are simply appended to the existing fields of each descriptor, i.e. their offsets are greater than those of the fields of the pointer variables needed for the garbage collector, in order not to impact its performance. The compiler generating these modified descriptors, the format of the Oberon object file containing them and the module loader transferring them into memory have been adjusted accordingly. The following code excerpt (of procedure Modules.Check) shows a possible realization of such a reference-checking scheme: PROCEDURE Check*(mod: Module; VAR res: INTEGER); VAR M: Module; pref, pvadr, r: LONGINT; BEGIN (*mod # NIL*) M := root; WHILE M # NIL DO IF (M # mod) & (M.name[0] # 0X) THEN Kernel.Mark(M.ptr) END ; M := M.next END ; Kernel.Check(mod.data, mod.var, mod.code, mod.imp, res); (*dynamic refs*) IF res = 0 THEN M := root; WHILE (M # NIL) & (res = 0) DO (*static refs*) IF (M # mod) & (M.name[0] # 0X) THEN pref := M.pvar; SYSTEM.GET(pref, pvadr); WHILE pvadr # 0 DO (*procedure variables*) SYSTEM.GET(pvadr, r); IF (mod.code <= r) & (r < mod.imp) THEN res := 3 END ; INC(pref, 4); SYSTEM.GET(pref, pvadr) END END ; M := M.next END END END Check; where procedure Kernel.Check implements the scan phase for dynamic references to the module, i.e. references from objects located in the heap: PROCEDURE Check*(type0, type1, code0, code1: LONGINT; VAR res: INTEGER); VAR p, r, mark, tag, size, offadr, offset: LONGINT; BEGIN p := heapOrg; res := 0; REPEAT SYSTEM.GET(p+4, mark); IF mark < 0 THEN (*free*) SYSTEM.GET(p, size) ELSE (*allocated*) SYSTEM.GET(p, tag); SYSTEM.GET(tag, size); IF mark > 0 THEN SYSTEM.PUT(p+4, 0); (*unmark*) IF (type0 <= tag) & (tag < type1) THEN (*types*) res := 1 ELSIF res = 0 THEN offadr := tag + 16; SYSTEM.GET(offadr, offset); WHILE offset # -1 DO (*pointers*) INC(offadr, 4); SYSTEM.GET(offadr, offset) END ; INC(offadr, 4); SYSTEM.GET(offadr, offset); WHILE offset # -1 DO (*procedure variables*) SYSTEM.GET(p+8+offset, r); IF (code0 <= r) & (r < code1) THEN res := 2 END ; INC(offadr, 4); SYSTEM.GET(offadr, offset) END END END END ; INC(p, size) UNTIL p >= heapLim END Check; Complete source code (modules Kernel, Modules): http://github.com/andreaspirklbauer/Oberon-experimental

2 1

How I know that nobody else USES ETHO ?
by eas lab 04 Dec '16

04 Dec '16

Apparently the populous USES what the market supplies. So they all get the uniform current outlook/ideas. How can a quick list of the newest files [ordered by recentcy] NOT be one of the most basic/essential requirements. It's as essential, but more difficult to know/remember than: "what directory of the file tree you are currently in". In the days of NativeOberon, I believe I hacked a script on ET.DO which did:- 1. List all files with dates, one per line: System.Directory *\d 2... Rearrange the fields, so that the date is first, with most-significant fields first 3.. Sort the lines 4.. Show only the first N As I recall commands existed for <filters 1,2,3 above>. I don't want to have to repeat the effort for V4. This is only one of the countless utilities that ETHO could throw together, if we had a mechanism to eg:- System.Directory *\d | <rearrange fields> | <sort lines> | <print first LinesArg:N> Yes, I remember: we've got a scheme interpreter in ETHO ! An extension to allow ETHO to concatenate-transformers, as above, should be simple, compared to a scheme interpreter? WDYS ?

1 0