[Ed. Note: Permission to publish this excerpt of the OberonNews (Nr. 2, Jul-1994) in The ModulaTor was granted by Johannes Marais, 10-Oct-1994.]
The Institute for Computer Systems of the ETH Zuerich and the Oberon User Group of Switzerland are pleased to announce that the Oberon newsletter is now the official information source about Oberon and related events. The newsletter is published on a semi-regular basis four times a year, to announce new Oberon versions, report about Oberon events, and to give information about the latest research and dissertations of the Institute for Computer Systems.
We do our best to present in each newsletter topics that we think might be interesting for Oberon users. In this issue we have diverse topics like using Oberon in art and in education, in addition to many announcements. We hope that you enjoy this issue.
Recently, after many months of hard work, the new DOS-Oberon System 3 version has been released. Although no conceptual changes have been made since the last version, a considerable part of the work involved incorporating suggestions from users and making smaller improvements (and of course, many bugs have been fixed!).
Most important, the main change in the new version is not only the release contents, but a new, more open, attitude towards Oberon. As Oberon is our main vehicle of research and the principal programming language taught at ETH, we have many active Oberon programmers. Oberon is used extensively in student works, resulting in many new Oberon tools and packages per year. Most of the programs are thrown away and never used again, although many are of such a high quality that Oberon users start using them for private purposes. Most of these programs never leave the domains of ETH, often giving an impression of closedness to the Institute.
However, in the last few years, many of the projects have shifted their emphasis from more technical and specific research to more end-user oriented applica- tions, making them much more suitable for general use by the Oberon community. This can be partially attributed to Oberon System 3, where the Gadgets toolkit increases programmer productivity by providing large sets of program components or gadgets for reuse, and in this way enables us to give students more ambitious projects to be completed in the same time frame.
Some of the more useful applications are now provided in an application package collection with each DOS-Oberon release. Most important, more example programs and the source code of some of the application packages give more realistic examples of typical Oberon programs. In our opinion we should not only teach how to build better software, but also provide examples of how to do so, and this is exactly why so much is now donated to the public domain.
The largest improvement is the new System 3 online tutorial system with a set of tutorials ranging from using the class Oberon system to programming new gadgets (more details can be found in another article). A further improvement is in the handling of diskettes. The old version could only read and write double density diskettes; the new version reads and writes both double and high density diskettes, and provides transparent support for MSDOS diskettes in addition to our own backup format.
Further improvements include better support for the Oberon desktop, an improved gadget locking model, print support for all standard gadgets, and a new gadget to make fixing program syntax errors a little less tedious. In addition, the new notebook gadgets are provided in source form, giving a stable basis for the development of container gadgets.
In conclusion, the Oberon System 3 distribution now includes the base system, the Gadgets user interface toolkit, the tutorial system, an assembler toolkit, the source of the display drivers, sample programs, the event simulation package, an enhanced text editor, a file archiving tool, a game, the demo Leda page layout version and an offline text formatter.
-Johannes Marais, Institute for Computer Systems
Each DOS-Oberon System 3 version includes an electronic tutorial system. The idea is to provide the system documentation in an electronic book form that not only allows you to jump from topic to topic in the well-known hypertext fashion, but also to make the book active by having working examples integrated inside it. So it is nothing strange to find completely working user interfaces floating in the book, or to include in the book a working panel that explains how to use that very panel. To promote the use of electronic books in Oberon, we also provide a tutorial development kit with each System 3 release in the hope that application developers will document their work in this way.
We also request our students and other application developers to document in the same way (some of the packages provided with DOS-Oberon already have electronic book descriptions). Each electronic book is structured as a normal book: you have a table of contents, the contents as paragraphs with footnotes, and an index of terms. Inside the book, in addition to buttons and other gadgets you click on, you will find highlighted words that act as hyperlinks to other places in the book, to other books, to footnotes, or as executors of Oberon commands.
Although books are fundamentally text based, you can also add panels and other gadgets inside the text. Buttons allow you to navigate backwards and forwards through the book or to backtrack your steps. A history facility ensures that you don't get lost in hyperspace.
Behind the scenes, each book is generated from a text file containing markup symbols and embedded elements. A book compiler compiles the book by reading the text file, linking the hypertext jumps with each other, collecting the index terms and building the table of contents. The compiled book is thus ensured to be consistent and can be used immediately. The editing of the book is done with a standard text editor; in this way larger changes can be made without too much trouble. Of course, to get you started with building your own books, a meta-tutorial will give you the needed instruction.
The System 3 release contains a number of tutorials including topics on how to use the textual user interface of Oberon, an introduction to the Gadgets system, how to use the Gadgets system and how to program new gadgets.
-Johannes Marais, Institute for Computer Systems
The Backdrop generator is one of the fun Oberon System 3 applications included in each DOS-Oberon release. Backdrops or wallpapers, as they are known from other systems, are texture bitmaps that we use to beautify our desktop backgrounds. The main problem with these backdrops is finding some you like and the time you waste trying out the ones you have found! As our contribution to your lack of productivity, we now have a backdrop generator for Oberon that allows you to create and then modify backdrops on the fly.
Each backdrop is generated by a user parameterized algorithm for a certain backdrop style. The student who created this tool let his fantasy free and came up with a whole set of interesting texture algorithms including fractals, surfaces, marble, textiles, spirals, bows, trees, cells, bricks, threads, clouds, molecules, coins and plasma. Each algorithm can be parameterized with a few numbers, or even be combined with others. There are countless combinations that you can try out.
Afterwards, should the colors or contrast not suit your taste, a color manipulation feature allows you to remap colors, make the image darker or lighter etc. And finally you can install your new backdrop immediately. How the backdrops are generated can be read in the corresponding electronic book. We hope you have lots of fun! -Johannes Marais, Institute for Computer Systems
The rule-based offline text formatter of Oberon System 3 allows you to create high quality documents with little effort. In the same manner as the well known TeX typesetting program, the formatter interprets markup symbols in a conventional text file to control the typesetting.
A user-defined stylesheet controls the text formatting and can be used for creating uniform documents between several people. The guiding principle is to keep things as simple as possible for a person unexperienced in electronic type- setting. This has been made possible through the efforts of our own font designer and typesetting expert, who has made the rules of typesetting and good taste explicit in several dozen typografic rules. These rules control how the text and embedded figures are poured into the columns on the page. More demanding users can override these intelligent defaults, although this is seldom necessary.
Users who have used offline text formatters might remember some of the set of cryptic markup sequences that have to be inserted into the text stream; the Oberon formatter though, many will be glad to know, uses a much simpler and intuitive strategy. The formatter tries to determine the semantic of the text contents by analyzing the fonts used (what size and style for example) and a few symbols like parenthesis and braces.
This means that the source text remains easily readable and easier to edit. For example, footnotes are simply written in square brackets and titles are written in a slightly larger font. Furthermore, gadgets and pictures can be included and placed automatically on the page. As examples, a few demanding page layouts are provided with the formatter, such as a dictionary and newspaper article. The documention of the formatter is an example in itself. The offline formatter is provided with source code with each DOS-Oberon System 3 release.
-Johannes Marais, Institute for Computer Systems
Four dissertations have recently been completed at the Institute for Computer Systems, ETH Zuerich.
As continuous evolution in hardware results in more powerful computers, new programming techniques and concepts must be developed to master the consequently increasing software complexity. Separate compilation of modules is such a technique that has proven valuable in Modula-2 and in Oberon, among other strongly-typed languages.
The module is both the structural unit and the compilation unit of programs. Replacing a module by a new one does not affect the rest of the system, providing that the module interface has not changed. Otherwise, client modules of the modified interface have to be recompiled to maintain system consistency. The last opportunity to detect an inconsistency is when modules are linked to form an executable unit.
The check usually consists in comparing, for each imported interface, the expected key of that interface, as known at compilation time of the client, with the key of the effectively supplied interface. A mismatch indicates an incon- sistency. The model is simple and efficient, but not very flexible. Indeed, a minor modification of an interface, such as the insertion of a new procedure, can trigger many unnecessary recompilations.
This thesis presents two new models for fine-grained consistency checking and their implementation. These models allow the interface of separately compiled modules to be extended without requiring a recompilation of client modules. This is particularly valuable in systems with dynamic loading, where the clients of a library are not known when the library is revised or extended. Interface editing that does not require client recompilation is not restricted to extensions, since the modification of an existing item does not invalidate clients not using this particular item. Even if they use it in a way that is upward-compatible with the modification, they still do not need a recompilation.
These techniques have been implemented in the Oberon system, but they are neither specific to the Oberon Language nor to the Oberon System. They can be applied to any modular programming system in order to improve its safety, its flexibility or both. Furthemore, these techniques are not available to the programmer as a separate tool whose use remains optional, but have been fully and transparently integrated into the compiler and module loader. Safety must not be optional.
With distributed programming it is possible to support cooperation among users in a network, and to develop programs that use resources of remote machines to enhance their availability and performance. This potential is even more important nowadays where networks of workstations become an increasingly attractive alternative to big mainframes for organizing bussinesses and computing environments. In this work, a system that promotes distributed programming in a network of personal workstations is presented. It is implemented on top of an existing operating system as a collection of modules that introduce new functionality in an incremental fashion.
The key idea of our approach is to view data items as abstract objects coupled to abstract descriptions indicating how their content can be written and read. This allows generic data transfer programs to be built without a priori knowing the type of the data items that are to be transfered. As an extension of this model, an asynchronous mechanism is developed for exchanging arbitrarily complex messages over the network. At the application level, sending and receiving of messages occur asynchronously to each other so that a decoupling between the communicating processes is achieved.
Finally, using the provided primitives a component is built which supports programming of extensible application objects that can be dynamically installed, referenced, and collected over a network. Such objects are automatically notified about incoming messages, thus they operate like special state machines whose transitions are triggered by message events; this technique is appropriate for capturing a wide range of distributed programs.
Due to its clean internal structure, the system presents itself as a set of well separated, yet cooperating parts which can also be individually accessed by the programmer. This allows for great flexibility in application development. Furthermore, the system encourages a disciplined programming style and guarantees type safety which we consider to be an important property of development environments. Our implementation also demonstrates that the proposed approach leads to acceptable performance at only a modest software cost.
The term metaprogramming refers to programming at the level of program interpretation, or in other words, to extending the interpreter of a given programming language in an application specific way. Traditionally, this concept is available only in dynamic typed and interpreted languages as Smalltalk or Lisp. This thesis investigates the possibilities of metaprogramming in a statically typed and efficiently compiled programming language.
In the course of a case study, we introduce metaprogramming facilities for the Oberon programming language and system. The result is a variant of the Oberon operating environment which allows a seamless integration of useful met-level facilities. The key to this integration is a generalized notion of persistent objects and object libraries and its application to components of Oberon programs.
Types and procedures are considered to be persistent objects collected in a special kind of library, namely module. We introduce a metaprogramming proto- col which allows to manipulate arbitrary data structures based on the notion of object riders. An object rider is an iterator which can be used to scan the components down to an arbitrary nesting level. We introduce also facilities for controlling procedure activations based on the notion of active procedures.
An active procedure is a procedure object which has its own instance specific behaviour expressed by a message handler. Active procedures can individually respond to invocation messages and perform any computation as response. We investigate the implications of this approach with respect to the overall system structure and to the implementation of critical components of the run-time system, such as the library loader and the garbage collector.
A new approach to safe library loading and unloading is introduced as well as a simple finalization technique and a way for optimizing libraries with a large number of objects. We show that the integration of meta-programming facilities does not introduce undue static or dynamic complexity into the Oberon system. A number of realistic applications serve as proof-by-example of the feasibility of the metaprogramming approach.
A technique for representing programs abstractly and independently of the eventual target architecture is presented that yields a file representation twice as compact as machine code for a CISC processor. It forms the basis of an implementation, in which the process of code generation is deferred until the time of loading. At that point, native code is created on_the_fly by a code_generating loader.
The process of loading with dynamic code_generation is so fast that it requires little more time than the input of equivalent native code from a disk storage medium. This is predominantly due to the compactness of the abstract program representation, which allows to counterbalance the additional effort of code_generation by shorter input times.
Since processor power is currently rising more rapidly than disk_access times and transfer rates are falling, the proposed technique is likely to become even more competitive as hardware technology evolves. To users of the implemented system, working with modules in the abstract representation is as convenient as working with native object_files. Both kinds of file_representation coexist in the implemented system; they are completely interchangeable and modules in either representation can import from the other kind. Separate compilation of program modules with type_safe interfaces, and dynamic loading on a per_module basis are both fully supported.
Deferring code_generation until loading time can provide several new capabilities, especially when the intermediate program representation is machine_independent and thereby portable. It is argued that the combination of portability with practicality denotes an important step toward a software- component industry.
Further benefits include a potential for reducing the number of recompilations after changes in source text, and a mechanism to decide at load time whether or not run_time integrity checks should be generated for a library module, eliminating the need to distinguish between development and production library configurations. All of these new possibilities have the potential of lowering the cost of software development and maintenance.
In the long run, fast on_the_fly code_generation may even replace binary compatibility for achieving software portability among processors implementing the same architecture. Already today, different models of a processor family are diverging more and more and it is becoming increasingly difficult to serve all of them equally well with just one version of native code.
If code is generated only at the time of loading, however, it can always be custom_tailored toward the specific processor that it will eventually run on.
-Compiled by Johannes Marais, Institute for Computer Systems
Oberon for Windows is available for almost a year now. The statistics on our ftp server neptune.inf.ethz.ch reveal that it has become one of the most popular implementation of the Oberon family, in terms of number of downloads. While even version 1.0 was running quite stable, the current version 1.31 contains some refinements and bug fixes. A nice point-and-click installation program has been added, making the installation of Oberon foolproof. You just specify the target directory and click ok, and the rest will be done automatically. Editing of autoexec.bat is no longer necessary.
A telnet client application provides a terminal emulation viewer class that allows to connect to remote systems. The terminal viewer is fully integrated into the Oberon system, i.e. text may be copied over from and to the terminal viewers. The telnet client makes use of any Windows-compliant sockets implementaion installed on a system.
The Kernel has been overhauled and at that time object finalization has been made safe. Any Oberon application may now register objects for finalization, together with a finalization procedure. When the garbage collector reclaims memory, it calls the registered finalization procedure which in turn may perform cleanup operations.
The file system is a client of this finalization service. Finalization handlers for file objects delete temporary files on disk if they are no longer needed [Editors note: The object finalization implementation is based on the dissertation of Josef Templ, Metaprogramming in Oberon].
Oberon for Windows has the future built in already: early tests have shown that it runs flawlessly on Beta versions of Microsoft's upcoming Chicago as well as on Daytona (Windows NT version 3.5). Some restrictions that are present now on Windows 3.1 systems will vanish when using Chicago. A port of Oberon System 3 is nearly finished, and will be advertised when complete. Stay tuned!
-Matthias Hausner, Institute for Computer Systems
The Oberon User Group (OUG), a sub-goup of the Schweizerischen Informatiker Gesellschaft (SI), has the goal to popularize Oberon and to collect all information about the Oberon language and system.
Every year we organize the Oberon Day, one of the major Oberon events of the year, where we present a full day of talks by well-known speakers around a specific topic. We also publish the Oberon Newsletter together with the Institute for Computer Systems.
The User group provide user support by e-mail and has a telephone hotline (details at the end of the newsletter).
-Markus D~atwyler, Oberon User Group
The Oberon User Group manages an internet FTP server called hades.ethz.ch (188.8.131.52) on which public domain Oberon software is archived. The directories are organized according to the system in /pub/Oberon, with each system sub-divided again for Oberon V4 and Oberon System 3.
A special directory contains programs that have been written for non-ETH Oberon implementations. You may upload your programs to /pub/incoming, from where they will be copied by the system administrators to their correct directory. Don't forget to include a README file in ASCII when uploading.
The Oberon User Group cannot accept responsibility for the functionality of Oberon programs on the FTP server, and does not adjust software for newer Oberon versions.
-Patrick Saladin, Oberon User Group
The Institute for Computer Systems is proud to announce the availability of the Oberon System V4 for Amiga computers. Oberon for Amiga is an implementation of the standard Oberon System Version 4, featuring an Oberon-2 compiler. All Oberon programs written for any Oberon System V4 can be compiled without modification. The software package oberon.lha is available without fee via anonymous internet ftp from neptune.inf.ethz.ch (184.108.40.206) in directory /pub/Oberon/Amiga/.
-Stefan Ludwig, Institute for Computer Systems
For the second year, a course in digital design for Computer Science students at ETH was held with great success. During the course, students solve exercises in digital design by implementing a circuit on an FPGA board (Field-Programmable Gate Array), using CAD software written entirely in Oberon.
The software package consists of a hardware description language compiler, a graphical design editor, and a design checker for comparing a formal description of a design with its implementation. The portability of Oberon allowed an easy migration of the tools to various other machines, such that students could solve the exercises on their computers at home, and only needed the FPGA board for final verification of the designs.
-Stefan Ludwig, Institute for Computer Systems
Tired of having to select a font for your Oberon documents from a very narrow set of choices? Oberon System 3 now supports Apple's TrueType font technology, which is incorporated in such widely used systems as Apple Macintosh or Microsoft Windows.
This means that Oberon users may now use TrueType fonts within their documents, on screen as well as on paper. Unlike traditional Oberon bitmap fonts, which need one file for every point size, TrueType fonts come with only one file holding all necessary information.
There's not even a distinction between screen fonts and printer fonts anymore, since a TrueType font does not make a fundamental difference between the two. This allows users to have lots of fonts available at reasonable storage requirements. Integration into Oberon System 3 is so smooth that most users will hardly ever notice, because all existing bitmap fonts will continue to work as before. The only difference lies in the fact that if a font is requested but cannot be found, the TrueType machinery will look for an appropriate TrueType description instead of immediately returning a default font.
The bitmap patterns that are needed to display characters on the screen are generated the first time they are requested and are kept in memory for further uses. This makes sure that computation effort is only spent where it is needed, since no pattern will ever be generated for characters that are never used, and keeps response times short (as long as only short text stretches are affected). Another way to use TrueType fonts is to convert them to traditional Oberon font files, which is also possible. These can of course be used with Oberon V4, too, and may be edited manually to improve their appearance on the screen. The use of TrueType fonts within Oberon documents opens a whole new range of possibilities, and we hope that a lot of users will take advantage of this opportunity and use their TrueType fonts with Oberon, too [Editor's note: The TrueType interpreter is available with the Leda page layout system demo version in each DOS-Oberon release].
-Erich Oswald, Institute for Computer Systems
The growing interest in distributed services using the client/server paradigm has led to the development of a large collection of network protocols in the computer science community.
One, TCP/IP, currently dominates the scene as it is already serving as a de facto standard in the world of UNIX. Most remote services including telnet, ftp and www are based on the reliable connections offered by TCP/IP. The abbreviation TCP/IP indicates that TCP is based on IP, both of which are layers in the Internet layering model. Compared with the OSI reference model, they correspond to the network layer (IP) and the transport layer (TCP).
The Internet protocol family contains several other protocols, i.e. arp (address resolution) and icmp (internet correction message), which are used by TCP/IP. We have implemented the entire Internet protocol family for the client side with the exception of fragmentation of IP packets and dynamic routing. We support two different versions, i.e. one for the standard Oberon sytem and another for Concurrent Oberon. The two versions differ from one another in dealing with asynchronous input from a network. All ported versions of Oberon can rely on a unique TCP/IP interface so network applications are portable. The complete implementation is rather small (only around 15KB). For further information feel free to contact email@example.com.
-Martin Gitsels, Institute for Computer Systems
Most of the research reports, dissertations and technical reports of the Institute for Computer Systems are available electronically via Internet FTP from neptune.inf.ethz.ch in the /doc directory. In addition to the text files containing the report abstracts, you will find the reports in Postscript format.
Some of the Oberon related reports are listed in the next paragraphs; additional or older reports are listed in the abstracts on the server. Unfortunately we don't sell dissertations directly; these have to be ordered from the person who wrote it, or if it has an ISBN number, directly from your book store. If you don't have electronic access to the technical reports, please write to us and we will send you a copy if available. Please keep in mind that we print only a limited number of copies.
Technical Report 156, Mar. 1991: R. Griesemer, On the Linearization of Graphs and Writing Symbol Files C. Pfister (ed.), B. Heeb, J. Templ, Oberon Technical Notes
Technical Report 198, Jul. 1993: N. Wirth, An Extension-Board with an FPGA for Experimental Circuit Design S. Ludwig, CL - An Editor for the CLi6000 Field Programmable Gate Array and its Implementation S. Ludwig, CL-Editor User Manual
Technical Report 212, Feb. 1994: J. Supcik, HP-Oberon(TM): The Oberon Implementation for Hewlett-Packard Apollo 9000 Series 700
Technical Report 215, May 1994: H. Eberle, S. Gehring, S. Ludwig, N. Wirth, Tools for Digital Circuit Design using FPGAs
-Johannes Marais, Institute for Computer System
Several books have been written about the Oberon System and Language. We recommend these books for serious Oberon users. However, if you want to try out Oberon before buying a book, most Oberon releases have enough online information to get a new user started with Oberon.
N. Wirth and M. Reiser: Programming in Oberon. Steps beyond Pascal and Modula. Addison Wesley, 1992, ISBN 0-201-56543-9. Tutorial for the Oberon programming language and concise language reference.
M. Reiser: The Oberon System. User Guide and Programmer's Manual. Addison Wesley, 1991, ISBN 0-201-54422-9. User manual for the programming environment and reference for the standard module library.
N. Wirth and J. Gutknecht: Project Oberon. The Design of an Operating System and Compiler. Addison Wesley, 1992, ISBN 0-201-54428-8. Program listings with explanation for the whole system, including the compiler for NS32000.
H. M~ossenb~ock: Object-Oriented Programming in Oberon-2. Springer, 1993, ISBN 3-540-56411-X. Principles and applications of object-oriented programming with examples in the language Oberon-2.
All the different Oberon versions are available free of charge from our Internet FTP server neptune.inf.ethz.ch in the /pub/Oberon directory. The sub-directory System3 contains the Oberon System 3 versions.
Classic Oberon is available for Amiga, DECStation, MS-DOS, Microsoft Win- dows and Windows NT, HP 700, Mac II, IBM RS6000, SPARC and Silicon Graphics machines. Oberon System 3 Version 1.5 is currently only available for MS-DOS and SPARC computers.
If you do not have access to Internet, you can order diskettes from the address below. We charge a fee of Sfr 50.00 to cover our costs. We accept payment via Eurocard/Mastercard or VISA.
To order by credit card, specify your credit card number, expiration date, and your name exactly as it appears on the card. If you already purchased an Obe- ron version from us, we will upgrade you to a newer version for Sfr. 20. The upgrading policy applies only to versions of the same architecture; this means you cannot upgrade from an older Oberon V4 for Windows version to a newer DOS-Oberon version or vice-versa.
Institut fuer Computersysteme ETH Zentrum CH-8092 Zuerich, Switzerland Telephone +41 (1) 6327311 Fax +41(1) 632 12 20 e-mail firstname.lastname@example.org The Oberon User Group Bergstrasse 5 CH-8044 Zuerich, Switzerland Hotline: +41(1) 632 72 13 e-mail email@example.com
Big thanks to our contributors, and to Hans Eberle, Dominique Lebegue, and Stefan Ludwig for their effort in proof reading the newsletter.
From: Johannes Marais <firstname.lastname@example.org> Date: Tue, 4 Oct 94 13:33:53 +0100OBERON NEWS
The Institute for Computer Systems and the Swiss Oberon User Group publish a quaterly newsletter to announce new Oberon versions, list upcoming events, and to introduce people to interesting Oberon projects around the world. So far only two issues have been published with the contents provided by members of our institute.
I see the newsletter as an important forum for the Oberon community to present its work. We encourage short experience reports and "practicle" articles, rather than long and "too academic" ones. Contributing is intended to be easy; simply send me a mail with your article. We cannot publish everything; no advertizements are allowed at the moment (although "sponsors" would be nice!). I suggest looking at the last issue of the newsletter to get a feeling for the type of thing we are interested in. At the moment the most important publishing criteria we use is "importance to the Oberon community".
HOW TO GET IT
The newsletter is available electronically in postscript format from neptune.inf.ethz.ch:/pub/Oberon/Newsletter. We also distribute the newsletter on paper to our address list of about 1200 Oberon fans. Please let me know if you want to be added to this list.
THE NEXT ISSUE
I am currently planning the Christmas issue. This issue will concentrate on the recent Oberon Day in Zuerich and the JMLC conference. A few people at the JMLC conference promised me some interesting contributions which I am looking forward too. Regarding this conference I see some areas that are of interest:
Institute for Computer Systems, ETH Zuerich
Home | Site_index | Legal | OpenVMS_compiler | Alpha_Oberon_System | ModulaTor | Bibliography | Oberon[-2]_links | Modula-2_links |