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

Re (2): Communicating with aliens
by peter＠easthope.ca 14 Jan '16

14 Jan '16

From: Joerg <joerg.straube(a)iaeth.ch> Date: Tue, 12 Jan 2016 11:31:53 +0100 > 2) ... a little unfortunate that Project Oberon has no > standardized definitions of the key codes for the up, left, right and > down keys. ... Important detail. Thanks Joerg. > 1) In the original Input.Mod there is an array for key code mapping. No offense to authors but a more difficult small accessory trail from the main route Input. > 2) add constant definitions in Input.Mod (either fix or varying per > platform) for the control keys ... Thanks again, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

3 2

Keyboard substituting for mouse; was Communicating with aliens
by peter＠easthope.ca 13 Jan '16

13 Jan '16

P.s. > 2) add constant definitions in Input.Mod (either fix or varying per > platform) for the control keys ... 3) What about a driver for the keyboard substitution, parallel to the mouse driver? Pressing <Scroll Lock> would install the keyboard substitution driver. Pressing again would reinstall the genuine mouse. I'm not asking anyone to work on it. Just wondering whether any of the veterans recognize a difficulty for the idea. Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Fwd: Obstacles when programming in RISC Oberon and proposed patches
by ɹǝzıuıʇnɹɔs ǝoɾ 13 Jan '16

13 Jan '16

Hi, while we are at improvements and error fixing in ProjectOberon, please allow me to repost Michael's message, which might have gone unnoticed at the time. cheers! >Date: Sat, 24 May 2014 22:13:07 +0200 >From: Michael Schierl <schierlm(a)gmx.de> >Subject: [Oberon] Obstacles when programming in RISC Oberon and proposed patches >To: ETH Oberon and related systems <oberon(a)lists.inf.ethz.ch> Hello, in general I like the simplicity of Oberon (and that you usually can find the cause of some problems quickly since Oberon itself is written all in Oberon and small enough to find what you search) but at some places, I think Oberon could be more pleasurable without making it a lot more complex. Therefore I prepared a few patches - if you like them, feel free to incorporate them, and if not, I can still use them :) If there is a better place to submit patches (or Git pull requests) like this, feel free to tell me. 1. Uninitialized local variables ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When something is allocated on the heap with NEW, all bytes are zeroed out (in Kernel.New). Variables declared at the top of the module are also zeroed out (in Modules.Load). Only local variables that live on the stack are not zeroed out, but stay what they are. It is easy to miss an initialization, resulting in a program that "sometimes works". On the other hand, it is also easy to patch the compiler to zero out these stack areas: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/init… When recompiling all Oberon from scratch and using it for a few days, you will notice that System.Clear is no longer working (since its "buf" variable was not initialized). Before it worked most of the time, but TRAPped sometimes... Patch to fix: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/syst… 2. Allocation failures and Garbage Collection ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ One of the disadvantages of Oberon's simple garbage collector (but still complex enough that I did not find time to wrap my head around it) is that it can only run "between" commands. So, when you compile something while 30% of the heap are used an allocation fails during compilation, it is not possible to run the GC to collect these 30% and then continue with compilation. Basically I guess the reason is that objects referenced from stack are ignored by the garbage collector, so it would collect "live" objects if it was run from within Kernel.New (but I'm not sure there, correct me if I'm wrong). As I said, the GC is too complex for me to "fix" (and probably it would make it even more complex if it was fixed), so I'm trying a different approach. In practice, it is no big deal to just run System.Collect followed by a recompilation if this situation arises. The largest problem is when running own code, whether the TRAP is a real programming error or just some allocation failure in the middle of some core library. Therefore I created a patch which will check in Oberon.Loop if there was a failed allocation since the last invocation and prints a message to Oberon.Log: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/log-… That way, it is clearly visible whenever allocation fails and it may be a good idea to just re-run the command after garbage collection. 3. Trap Backtraces ~~~~~~~~~~~~~~~~~~ Sometimes, when programming, you get some TRAP null dereference somewhere deep in Texts of Files or another system module and need to add some debugging statements to find out which of your calls to these modules passed the NIL value. This is a tedious task, and other programming languages like C or Java have a simple solution for it: On an assertion or breakpoint, scan the stack for pointers to code that are directly behind a branch (BL or BLR in case of RISC Oberon), and print the offsets of these instructions. In case of C, you'll get some false positives sometimes, but in practice that does not matter as it is still a lot better than having no backtrace at all (in Java, the frames are linked and therefore the JVM can tell exactly which of the values are return pointers and which are data, therefore a backtrace is "exact" there). I think it got most popular by laxly configured Java webservers, which often print long stack traces on its HTTP 500 error pages visible to customers. In combination with debug symbols, these offsets can also be decoded back to original line numbers. Oberon does not have debug symbols, but traps already use some unused bits in the BLR instruction to encode the position where the trap occurred. So it is easy to change the other BLR instructions to include the position at the same place. BL instructions, however, don't have enough free bits to encode the position, so I decided to prefix every BL instruction by a dummy BLR instruction that uses condition flags 0FH (which can never be fulfilled) and encode the position in there. To make the lines of the backtrace easier "followable", the position is printed as 123@ModuleName, and Edit.Locate is enhanced to detect this syntax and if the marked viewer does not have ModuleName.Mod open, open a new viewer with that module and locate the position in there. This can certainly be enhanced to scan for an open viewer and use it, but in practice where there are no more than 2 or 3 different interesting modules in the backtrace, this simple solution suffices for me. Patch is here: https://github.com/schierlm/OberonEmulator/blob/master/ProposedPatches/trap… Tell me what you think about it - or if you have ideas to solve these problems in a better way :) Regards, Michael

1 0

Re: [Oberon] Virtualbox disk image of Native Oberon 2.3.7
by peter＠easthope.ca 13 Jan '16

13 Jan '16

Hello Srinivas, > I downloaded the latest NativeOberon_2.3.7.tar.gz from native Oberon Sourceforge site. Not posted by me. I do not know the origin of the release number, 2.3.7. The last release number on the ETH server is 2.3.6. The Alpha release is identified by a date. 05.01.2003. You can see it in http://www.ethoberon.ethz.ch/native/ . All I posted on sourceforge is the Alpha Oberon0.Dsk, the OberonCF0.Dsk and accompanying README. > I am able to run Oberon0.Dsk file on Virtualbox. Good. I use QEMU. http://www.ocp.inf.ethz.ch/wiki/Documentation/Installation#toc23 > I would like to see a complete Oberon desktop similar to the > screenshots present on Sourceforge site. No problem. Using VB, install Oberon0 using Oberon0.Dsk or OberonCF0.Dsk with diskette emulation. See above. To complete the full system retrieve packages by FTP and unpack. Open http://www.ethoberon.ethz.ch/native/ . Under "Latest PC Native Alpha" follow "Download". There find the packages *.zip. Retrieve and unpack. My notes have the commands to retrieve and unpack by pointing and clicking. http://easthope.ca/OberonUsage.html After that the installed full system can run under VB or or directly on the machine. > However, I don't think, I shall be able to prepare a disk > image with complete Oberon installed in it with all available tools and gadgets. Yes, a conceivable method but I don't know of any such image. The instructions above accomplish the full installation. Is there a reason to aim for another method? I have copied to oberon@lists for benefit of anyone with similar interests. Regards, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0

Use of resources.
by peter＠easthope.ca 11 Jan '16

11 Jan '16

Did Wirth write something about refraining from use of a resource merely because it is available? I'm almost certain I read it in something he wrote or in something biographical. Haven't found it with Google. A citation? Thanks, ... Lyall E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 or +1 604 822 7107 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

9 14

(no subject)
by None 11 Jan '16

11 Jan '16

1 0

Elektor Magazine news item
by Chris Burrows 10 Jan '16

10 Jan '16

There is a news item about Project Oberon in the online Elektor Magazine titled: "No Linux, no Python, it's Oberon all the way" https://www.elektormagazine.com/news/no-linux-no-python-it-is-oberon-all-the -way Regards, Chris Burrows CFB Software http://www.cfbsoftware.com

5 7

Oberon usage; was OberonStation
by peter＠easthope.ca 09 Jan '16

09 Jan '16

>From lab.eas at gmail.com Tue Dec 22 04:18:49 2015 > I must accept what they publish ... You refer to a HTML document or to a browser? HTML can be edited by a human using an editor such as ET in NO. > ... html & the browser-race ... In a contemporary Linux system a browser is installed automatically or manually in a few minutes. Updates can be installed automatically. Compare to installing a TeX system. > Expectedly ETHO can't handle <current html standards>. Native Oberon displays most of the text of Category2.html. Praiseworthy, considering that Desktops.OpenDoc was written roughly two decades ago. The A2 browser also renders PNG, SVG and tables. Mon, December 21, 2015 12:28 pm, skulski at pas.rochester.edu wrote: > Not a great example because several links are broken. The Cat List archive was moved and the link is revised now. Thanks. The other links worked. Which failed for you? Thanks for the feedbacks, ... Peter E. -- 123456789 123456789 123456789 123456789 123456789 123456789 123456789 12 Tel +1 360 639 0202 or +1 604 822 7107 http://easthope.ca/Peter.html Bcc: peter at easthope. ca

1 0