Project Artemis

Project Status: WIP – Initial development is in progress, but there has not yet been a stable, usable release suitable for the public.

Artemis

Artemis is an Oberon-07 module collection. My hope is to encourage continued use and development of the Oberon-07 language and encourage convergence towards compatibility in implementations of Oberon-07 compilers. My focus in this project is using Oberon-07 on POSIX systems.

This project started as a re-imagining of the efforts that began at the Oakwood Hotel in the 1992. As at Oakwood I hope to encourage convergence to help code become more portable. Unlike Oakwood my focus is only on Oberon-07 and systems implemented in Oberon-07 or providing an Oberon-07 compiler. That is the scope of Artemis project for now.

Initial development is being done in a POSIX environment and relies on Karl Landström’s OBNC compiler, Mike Spivey’s Obc-3 and Oleg N. Cher’s OfrontPlus compiler.

Artemis draws inspiration from Wirth and Reed’s Project Oberon 2013, Joseph Templ’s Ofront with V4. It also draws inspiration from the discussions and community on the Oberon List.

A big thank you goes to all the inspiring people who contributed to Oberon and Oberon Systems over the years particularly where their source code is publicly available or through published articles, presentations and who wrote books about the language and system. All have help me study path Prof. Wirth and Prof. Gutkneckt pioneered all the many years ago.

Project layout

The subdirecties named for their compilers will implement modules providing a common definition but specificly written to that compiler. This typically will be modules that rely on an underlieing C library or behavior. The plan is for commonly defined modules targetting a specific compiler to use the “art” prefix. This will give room to the compiler developer to either adopt or create their own compatible implementations. E.g. current I’ve implemented a Unix and Clock modules for the OBNC and Oxford compilers. These will be renamed artUnix and artClock. Likewise the implementations of extArgs, extEnv I made for the Oxford compiler will be renamed artArgs and artEnv so that it is clear these are not the original OBNC modules extensions written by Karl.

descriptions of the structures

The root repository directory is for modules that are portable between POSIX Oberon-07 compiler implementations and portable to an Oberon-07 based Oberon System. Where I’ve provided non-canonical implementations I plan to use the “art” prefix in the module name.

The obncdocs directory contains documentation of the module definitions for the common modules in the root directory.

The obnc directory contains modules that target specific features of the OBNC compiler. This is primarily integration with C based libraries and services. These aren’t portable between compilers but should work across POSIX systems where OBNC is available.

The oxford directory contains modules that target the Oxford Oberon Compiler, aka Obc-3. This is primarily integration with C based libraries and services. These aren’t portable between compilers but should work across POSIX systems where Obc-3 is available.

The ofrontplus directory contains modules that target the OfrontPlus compiler. This is parimarily integration with C based libraries. These modules are not portable between compilers but should work across POSIX systems where OfrontPlus is avialable.

Module naming

Any modules which are not canonical to Artemis or are specific to a compiler implementation must be prefixed with “art”. This will allow for better re-use in other projects (e.g. OfrontPlus) and avoids name collisions.

Artemis Modules

Chars is a module for working with CHAR and ARRAY OF CHAR. It is inspired by the Oakwood Strings module. It goes beyond the Oakwood minimum. It can function as a drop in replacement for the Oakwood Strings module.

DStrings provides a dynamic string implementation for Oberon-07. The procedures signatures are often compatible with the Chars module. It leverages the Rider concept borrowed from Files and Texts in the Oberon System.

Tests is a minimal test library used to implement module tests in Artemis. It tries to honor the advice of “simple but no simpler”.

Obn2 is a module provides compatibilty for some built-in Oberon-2 procedures that were dropped in the evolution to Oberon-07.

Path is a module for working with POSIX style paths and file extensions. It does not directly interact with the OS. It does provided a means of working with path strings in a uniform way. By default it assumes the paths are delimited with the ‘/’ character and ‘.’ for file extensions. This is configurable by the Path module’s SetDelimiter() and SetExtDelimiter() procedures.

OBNC specific modules

The following modules are not portable to Project Oberon are implemented specifically for a targetted compiler.

artUnix provides access to some Unix/C facilities.

artClock provides an abstraction layer working with the system clock. The implementation uses the C clock_gettime() and clock_settime().

Oxford Specific Modules

artArgs provides an OBNC compatible Args module

artEnv provides an OBNC compatible Env module

artConvert provides an OBNC compatible Convert module

artUnix provides access to some Unix/C facilities.

artClock is an abstraction layer for working with the system clock. It uses the C clock_gettime() and clock_settime().

OfrontPlus Specific Modules

NOTE: These modules are in the planning stages and hopefully included in the next release of Artemis.

artArgs provides an OBNC compatible Args module

artEnv provides an OBNC compatible Env module

artConvert provides an OBNC compatible Convert module

artUnix provides access to some Unix/C facilities.

artClock is an abstraction layer for working with the system clock. It uses the C clock_gettime() and clock_settime().

Project approach to portability

Artemis is made up of two categories of Oberon-07 modules. Modules in the root should be portable across POSIX Oberon-07 compilers and portable to Oberon Systems with an Oberon-07 compiler (e.g. on Project Oberon 2013). A second category are modules written for specific POSIX based Oberon-07 compilers.

In the POSIX environment Oberon-07 compilers have not converged (2021-09-21). This is true for Oakwood module implementations and and particularly true for how C code is integrated. The later is the important divergence as integration with legacy C libraries and services is likely to be required for some time into the future.

Putting it all together

Both non-portable and portable modules can be used together in a project. This requires knowing the compiler you’re using and targeting it’s way of managing where to find modules.

FIXME: The next paragraph needs to include references for OfrontPlus.

An example is using Tests.Mod for the clocktest implementations in both obnc and oxford directories. With OBNC you need to set some environment variables to let the compiler known where to search for modules. Here’s what you can do to compile this implementation of clocktest in the obnc directory.

export OBNC_IMPORT_PATH=".:../"
obnc -o clocktest ClockTest.obn

With Obc-3 you can just provide the full path to the module you want to include. Compiling the implementation of clocktest in the oxford directory looks like —

obc -07 -o clocktest Clock.m ../Tests.m extEnv.m ClockTest.m

NOTE (2021-06-16): Not sure why yet but I found it necessary to rename Tests.Mod to Tests.m to get compilation with obc. It might be because the other files I am compiling use the ‘.m’ extension. Need to check with Mike.

FIXME: Document using compiling and handling import paths with OfrontPlus compiler.