August 2002 - Oberon - mailman3.inf.ethz.ch

backward compatible
by Charles Angelich 22 Aug '02

22 Aug '02

>From: muller(a)inf.ethz.ch >Date: Wed, 21 Aug 2002 19:04:05 +0200 >To: oberon(a)inf.ethz.ch >Cc: muller(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich <cangelich(a)famvid.com> wrote: >> 640x480 video display driver: >> System track = 36 Oberon10.Scn.Fnt chars >> User track = 63 Oberon10.Scn.Fnt chars > >Since Oberon10 is a proportional font it makes no sense to >count the number of characters. Or did you mean Courier10? > >> To increase the usefulness of the >> System.Directory display I have made the following changes. [...] >Not a good idea to make non-backward-compatible changes in a >low-level module. I've changed this code since my original post. I will need to go back and review my changes but I think I may have only changed ONE module now rather than two. Can you please specify the exact lines of code that you deem "non-backward compatible". Use of full space characters within the Directory procedure would seem to have NO effect other than to make the display readable and correct an error. Directory displays are not INSTALLED they are requested by the user on-the-fly. There should be no existing older displays within a previously installed Oberon to "interfere" with? >Neither is field padding with a proportional font. You have ignored the fact that this _does_ actually work! Columnar alignment is normal in the real world. The existing "\d" display is almost unreadable yet you dismiss this offhand even though I included example displays that are properly aligned by "counting chars" and padding. What you are telling me seems more a personal decision rather than a decision based upon real world evidence that this will do harm to the Oberon code. Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0

option to chose system default font in Native
by Charles Angelich 22 Aug '02

22 Aug '02

>From: muller(a)inf.ethz.ch >Date: Wed, 21 Aug 2002 19:04:05 +0200 >To: oberon(a)inf.ethz.ch >Cc: muller(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich <cangelich(a)famvid.com> wrote: >> 640x480 video display driver: >> System track = 36 Oberon10.Scn.Fnt chars >> User track = 63 Oberon10.Scn.Fnt chars > >Since Oberon10 is a proportional font it makes no sense to >count the number of characters. Or did you mean Courier10? > >> To increase the usefulness of the >> System.Directory display I have made the following changes. [...] >> Changes were required within Texts.Mod to the Writeint >>procedure to correct mismatched columns in the more complete >>directory display. > >Not a good idea to make non-backward-compatible changes in a >low-level module. Neither is field padding with a proportional >font. I have installed the W31 version of Oberon and found that the user can chose the default system font by editing a text INI file. I did post a message here asking if this option could be added to Native Oberon (chose the system font default) but have, as yet, no reply. I have modified my Oberon.Mod to auto-detect display sizes and chose the default font. I use different display sizes here on different machines. In part to see what others see rather than argue with them that "It looks fine to me" and because my different hardware has different capabilities. I originally did this to see HTML pages in various sizes. btw: What happened to the Syntax#.Scn.Fnt I find in W31. I like that font! Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0

documentation for ETH N-O installs
by Charles Angelich 22 Aug '02

22 Aug '02

>From: muller(a)inf.ethz.ch >Date: Wed, 21 Aug 2002 19:04:05 +0200 >To: oberon(a)inf.ethz.ch >Cc: muller(a)inf.ethz.ch >Subject: Re: [Oberon] ETH N-O Native/Beta directory display >Reply-To: oberon(a)inf.ethz.ch > >Charles Angelich <cangelich(a)famvid.com> wrote: >> 640x480 video display driver: >> System track = 36 Oberon10.Scn.Fnt chars >> User track = 63 Oberon10.Scn.Fnt chars > >Since Oberon10 is a proportional font it makes no sense to >count the number of characters. Or did you mean Courier10? > >> To increase the usefulness of the >> System.Directory display I have made the following changes. I haven't viewed the displays produced by this newer code but I'm guessing they scatter all over the screen in a somewhat random fashion? >Since 07.02.01, System.Directory on Native Oberon supports >additional flags. This is currently only documented in >http://www.oberon.ethz.ch/native/WebAlpha.html, excerpt below: Not including documentation within Oberon installs seems to be a reocurring theme. Charles Angelich The Ghost in the Machine! DOS and W31 Tech website: http://www.undercoverdesign.com/dosghost Stories, poems, music, and photos website: http://www.undercoverdesign.com/dosghost/faf

1 0

Re: RX; (was [Oberon] Re: Oberon digest, Vol 1 #49 - 2 msgs)
by peter_easthope＠gulfnet.sd64.bc.ca 22 Aug '02

22 Aug '02

Charles & others, ca> I don't quite understand your need to combine lines. Yes; it was a trivial hypothetical example. Here is a real example. In a regular expression in Unix, the beginning of a line is indicated by the character ^. Thus, the regular expression for any line beginning with "Begin" is "^Begin*" or possibly "^Begin*$" (I've forgotten whether the end of the line is specified). RX.Tool in Oberon does not mention any means of identifying the beginning of a line. I thought of 'RX.SetSearch c "Begin" {~c} c'. Logically it should work for any line except the first but fails apparently because it spans two lines.

1 0

Re (2): [Oberon] ETH Oberon/Gadgets: System Freeze in unloading
by muller＠inf.ethz.ch 22 Aug '02

22 Aug '02

"Patrick, Dr. med. Hunziker" <PHunziker(a)uhbs.ch> wrote: > ETH PlugIn Oberon for WindowsTM / Win32 2.4 (15.12.2000) You are using a quite old version of Windows Oberon. This problem seems to have been fixed in later versions (see below). > However, in several years of working with Oberon, I have only found > three ways to produce C-like system freezes > apart from using the unsafe SYSTEM feature: > A) calling C programs from within Oberon > B) passing very large arrays as value parameters in procedure headings > C) unloading modules whereby some visual gadget is still hanging > around somewhere, as mentioned above. > I feel system stability is a prominent one of the many highlights of > Oberon, so the points B and C hurt the more... BTW Both B and C are addressed in Native Oberon, and A is not relevant there. The problem in B is a stack overflow. For example, try the following command on your Oberon system to see how it handles stack overflow (warning: it may crash): MODULE Temp; PROCEDURE Trap*; BEGIN Trap END Trap; END Temp. Temp.Trap Here are the results on the four ETH Oberon systems I tested (latest versions): 1. Native Oberon: > TRAP -14 Stack overflow ( 00103FFCH ) (PC Native 20.08.2002) > Temp.Trap PC = 10 > Temp.Trap PC = 15 > ... 2. Oberon for Aos: > [1] TRAP -14 PL 3 stack overflow Aos 20.07.2002 > CS:=0000001B DS:=00000020 ES:=00000020 SS:=0000002B CR0=80040031 FPU=00000000 > EIP=00574012 ESI=00573F70 EDI=8427F694 ESP=84261000 CR2=84260FFC PID=00000001 > EAX=00898DC0 EBX=0057400F ECX=00000000 EDX=005A8FF8 CR3=02FFE000 LCK=00000000 > EBP=84261000 FS:=00000000 GS:=00000000 ERR=00000006 CR4=00000000 TMR=00027BCA > EFLAGS: cPaZstIdo iopl3 {1..2, 6, 9, 12..13, 16} > Process: 18 run 1 2 0057A1B0:AosCommands.Runner AosLocks.ReleasePreemption pc=859 {0, 28} > Temp.Trap pc=10 > Temp.Trap pc=15 > ... 3. ETH PlugIn Oberon for Windows (14.5.2001): > TRAP stack overflow in thread Oberon.Loop > > Temp.Trap PC = 7 > Temp.Trap PC = 15 > Temp.Trap PC = 15 (this was running on Windows 2000 Version 5.0.2195 Service Pack 2) 4. Oberon for Linux x86 crashes (terminates the Oberon process). I suspect this is simply a bug that can probably be fixed by Günter. So problem B is solved already in the latest versions of Native Oberon and Windows Oberon. Native Oberon and Aos solve this problem by leaving the bottom page of the stack area in virtual memory unmapped. This causes a page fault when the stack overflows. This is reliable, even for large local variables, since stack clearing is done from top to bottom using PUSH instructions. Felix Friedrich <friedrich(a)gsf.de> wrote: > Do you see a solution for C) ? Native Oberon solves this problem, but AFAIK the solution was not ported correctly to any other ETH Oberon system. Felix Friedrich <friedrich(a)gsf.de> wrote: > So the "solution" is: Do not System.Free a Module when its Objects are > still displayed, since they are not deallocated and the Handler is called > any time a Display.Broadcast (or update message) is sent (which is the case > when new Viewers like a Trap-View are opened.) True, but if this happens we would like the system to trap gracefully, and not crash. Frank van Riet <Fvanriet(a)spescom.com> wrote: > I believe the best way to solve the problem is to have a termination handler > for each module. True in most cases, e.g. if you have installed a task, or some other upcall that can be uninstalled again. In the case of visual gadgets, this is difficult, because the gadgets are not linked anywhere except in the display space (by design). Even broadcasting a "remove yourself" message to the gadgets of the module will not always work, since the gadget may be in a covered track. Felix Friedrich <friedrich(a)gsf.de> wrote: > On the other hand: I want to be the boss of my computer: I say System.Free > and I want the system to execute System.Free unless there are very specific > reasons not to do, like depending modules. I do not accept depending > objects as a reason since there seems to be no way to check if displayed > objects depend on any of the freed objects. ) I agree. See below. "Douglas G. Danforth" <danforth(a)greenwoodfarm.com> wrote: > I would think the simplest solution would be to tie a visual > gadget to the module that created it. Freeing of that module > could then not occur as long as an instance of the gadget > occured anywhere. I remember reading somewhere (perhaps in something written by M. Hof?) that some version of Linz's Oberon used their metaprogramming facilities to trace procedure variables and refuse to Free a module that is still referenced by a procedure variable. They found it was a nuisance in practice. The pragmatic solution to this problem in Native Oberon is: 1. Where possible, the module termination handler (installed with Modules.InstallTermHandler) cleans up so that this problem does not occur. 2. When a frame handler traps, the frame is closed. This avoids recursive traps and stack overflows, which avoids system crashes. The code for this is a bit of a hack, but it seems very effective. It is implemented in Viewers.Broadcast, Viewers.Close and System.Trap. In some cases it produces false positives, e.g., sometimes when a command linked to a gadget traps, the (innocent) frame containing the gadget is closed. System.Recall can be used to recall it. -- Pieter P.S. When posting to oberon@inf, please use the email address that you have subscribed, otherwise your posting is delayed until manually approved by the administrator. There is also a chance that it gets mistaken for spam and deleted. -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1

Re: [Oberon] Identify Calling Command
by muller＠inf.ethz.ch 22 Aug '02

22 Aug '02

> Is there a portable way to identify the caller of a procedure, I need I don't really know a portable way (since ETH Oberon does not have full-featured metaprogramming facilities in all versions), but the following works on Native Oberon and Windows Oberon. MODULE Temp; IMPORT SYSTEM, Kernel, Out; PROCEDURE Identify(VAR modname: ARRAY OF CHAR; VAR pc: LONGINT); VAR ebp, eip: LONGINT; m: Kernel.Module; BEGIN SYSTEM.GETREG(SYSTEM.EBP, ebp); SYSTEM.GET(ebp, ebp); (* stack frame of caller *) SYSTEM.GET(ebp+4, eip); (* return address from caller *) m := Kernel.GetMod(eip); IF m # NIL THEN COPY(m.name, modname); pc := eip - SYSTEM.ADR(m.code[0]) ELSE modname[0] := 0X; pc := MAX(LONGINT) END END Identify; PROCEDURE Test*; VAR name: ARRAY 32 OF CHAR; pc: LONGINT; BEGIN Identify(name, pc); Out.String(name); Out.String(" PC="); Out.Int(pc, 1); Out.Ln END Test; END Temp. The gives you the calling module name and PC offset, which can be used with Compiler.Compile \f to find the calling location. If you just want this for debugging, consider writing a HALT statement, which also gives a stack traceback. On Native Oberon you can use the hack HALT(MAX(INTEGER)) for a halt that produces a trap and then continues running. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

2 1

Re: [Oberon] Is this a bug ?
by muller＠inf.ethz.ch 21 Aug '02

21 Aug '02

cglur(a)onwe.co.za wrote: > Normally, Inet fetches (email, News or html) are most convenietly > packed away to the appropriate partition, by changing the Name > appropriately, before [Store]. The Store command stores pictures in Oberon .Pict format. Change the extension to .Pict instead of .gif, then loading will work. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] n-o alpha 2001: please confirm/deny this bug
by muller＠inf.ethz.ch 21 Aug '02

21 Aug '02

cglur(a)onwe.co.za wrote: > 1. OFSTools.Mount <oldPartiton> AosFS IDE<IdeNo>#<partnNo> ~ > > 2. System.Directory <oldPartiton>:* > > 3. Select and open file ( < 1 screen viewer size) > > 4. cutNpaste viewer contents to <tempViewer> > > 5. Close viewer opened in 3. > > 6. OFSTools.Unmount <oldPartiton> > > 7. move or otherwise access <tempViewer> > > 8. Observer (or not): > TRAP -14 NIL reference ( 0000006CH ) (PC Native 11.10.2001) The problem is that you are unmounting a file system containing files that are still referenced. Because of the way the Oberon text system works, cutting (deleting) and pasting (recalling) text does not make a copy, but just creates another reference to the same underlying text file (see Project Oberon). Even if you copy the text (MR-MM or ML-MM interclick), the same underlying file is still used. The only solution I see is to copy the original text file to another file system that will remain mounted, or to refrain from unmounting the original file system. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] ETH N-O Native/Beta directory display
by muller＠inf.ethz.ch 21 Aug '02

21 Aug '02

Charles Angelich <cangelich(a)famvid.com> wrote: > 640x480 video display driver: > System track = 36 Oberon10.Scn.Fnt chars > User track = 63 Oberon10.Scn.Fnt chars Since Oberon10 is a proportional font it makes no sense to count the number of characters. Or did you mean Courier10? > To increase the usefulness of the > System.Directory display I have made the following changes. Since 07.02.01, System.Directory on Native Oberon supports additional flags. This is currently only documented in http://www.oberon.ethz.ch/native/WebAlpha.html, excerpt below: Command line options on System.Directory: d for detail (time and size), t for time, s for size, r for recursive into subdirectories, f for fixed font and name first. > Changes were required within Texts.Mod to the Writeint procedure > to correct mismatched columns in the more complete directory display. Not a good idea to make non-backward-compatible changes in a low-level module. Neither is field padding with a proportional font. -- Pieter -- Pieter Muller, Computer Systems Institute, ETH Zurich / MCT Lab, Zurich Native Oberon OS: http://www.oberon.ethz.ch/native/

1 0

Re: [Oberon] ETH Oberon/Gadgets: System Freeze in unloading
by Patrick, Dr. med. Hunziker 21 Aug '02

21 Aug '02

>>Gadgets.Insert BasicGadgets.NewButton >>to Insert a button somewhere. >>Then I execute >>System.Free BasicGadgets~ >> makes the system freeze... >Felix wrote: >Don't be so cruel to the poor Button. You have stolen its Handler. ;-) >Seriously: The Problem is: When freeing a Module, Oberon checks if there >are still other Modules depending on that module but it cannot check if >Objects are still using any Allocated Memory in that Module. In that >special case the allocated Memory was the Handler and moreover any >type-checks and type-casts could't work since the Module did not exist any >more (after successful freeing it) etc. >So the "solution" is: Do not System.Free a Module when its Objects are >still displayed, since they are not deallocated and the Handler is called >any time a Display.Broadcast (or update message) is sent (which is the case >when new Viewers like a Trap-View are opened.) >Felix. Thanks for the info. I see the problem. However, in several years of working with Oberon, I have only found three ways to produce C-like system freezes apart from using the unsafe SYSTEM feature: A) calling C programs from within Oberon B) passing very large arrays as value parameters in procedure headings C) unloading modules whereby some visual gadget is still hanging around somewhere, as mentioned above. I feel system stability is a prominent one of the many highlights of Oberon, so the points B and C hurt the more... Greetings Patrick

3 2