index.html

<!DOCTYPE html>
<html>
<head>
    <title>Project Artemis</title>
    <link rel="stylesheet" type="text/css"  href="/printfonts/print.css" media="print" />
  <link rel="stylesheet" type="text/css"  href="/webfonts/fonts.css" media="screen" />
    <link href="/css/site.css" rel="stylesheet" />
</head>
<body>
<header>
Project Artemis
</header>
<section>
<p>
<a href="https://www.repostatus.org/#concept"><img src="https://www.repostatus.org/badges/latest/concept.svg" alt="Project Status: Concept – Minimal or no implementation has been done yet, or the repository is only intended to be a limited example, demo, or proof-of-concept." /></a>
</p>
<h1 id="artemis">
Artemis
</h1>
<p>
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.
</p>
<p>
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.
</p>
<p>
Initial development is being done in a POSIX environment and relies on Karl Landström’s <a href="https://miasap.se/obnc/">OBNC</a> compiler. As time permits I am attempting to port the changes to other Oberon-07 implementations including Mike Spivey’s <a href="https://github.com/Spivoxity/obc-3">Obc-3</a> and Oleg N. Cher’s <a href="https://github.com/Oleg-N-Cher/OfrontPlus">OfrontPlus</a> compiler.
</p>
<p>
Artemis draws inspiration from Wirth and Reed’s Project Oberon 2013, Joseph Templ’s <a href="https://github.com/jtempl/ofront">Ofront</a> with V4. It also draws inspiration from the discussions and community on the <a href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">Oberon List</a>.
</p>
<p>
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 or books about the language and system. All have help me study the path Prof. Wirth and Prof. Gutkneckt pioneered all those many years ago.
</p>
<h2 id="project-status-2023">
Project Status 2023
</h2>
<p>
It’s the end of 2023 and I haven’t had time to work on this. Busy life. I still think this is a worth while effort as I head into three years of a lingering project on my todo list. I like Oberon-07 very much as a language but can’t really use it conveniently for my personal projects yet. Time is a bottle neck right now and feeling comfortable asserting some design choices is another. My guess is I need to have a specific project as a use case to really get this effort off the ground. In 2023 the Oberon community is still active but is generally is small, dispersed and largely aging (as am I). Makes me feel a little like Don Quote. I have hope 2024 may allow time for Artemis but I suspect I’ll reach mid 2025 before I revisit it again. I remain hopeful but not expecting to much as I finish 2023.
</p>
<h2 id="project-layout">
Project layout
</h2>
<ul>
<li>
root
<ul>
<li>
obncdocs
</li>
<li>
obnc (not portable)
</li>
<li>
oxford (not portable)
</li>
<li>
ofrontplus (not portable)
</li>
</ul>
</li>
</ul>
<p>
The directories named for their compilers will implement modules providing a common definition but specifically written to that compiler. This typically will be modules that rely on an underlying C library or behavior. The plan is for commonly defined modules targeting 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.
</p>
<h3 id="descriptions-of-the-structures">
descriptions of the structures
</h3>
<p>
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.
</p>
<p>
The <strong>obncdocs</strong> directory contains documentation of the module definitions for the common modules in the root directory.
</p>
<p>
The <strong>obnc</strong> 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.
</p>
<p>
The <strong>oxford</strong> 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.
</p>
<p>
The <strong>ofrontplus</strong> directory contains modules that target the OfrontPlus compiler. This is primarily integration with C based libraries. These modules are not portable between compilers but should work across POSIX systems where OfrontPlus is available.
</p>
<h2 id="module-naming">
Module naming
</h2>
<p>
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.
</p>
<h2 id="artemis-modules">
Artemis Modules
</h2>
<p>
<a href="Chars.Mod">Chars</a> 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.
</p>
<p>
<a href="DStrings.Mod">DStrings</a> 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.
</p>
<p>
<a href="Tests.Mod">Tests</a> is a minimal test library used to implement module tests in Artemis. It tries to honor the advice of “simple but no simpler”.
</p>
<p>
<a href="Obn2.Mod">Obn2</a> is a module provides compatibility for some built-in Oberon-2 procedures that were dropped in the evolution to Oberon-07.
</p>
<p>
<a href="Path.Mod">Path</a> 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 <code>SetDelimiter()</code> and <code>SetExtDelimiter()</code> procedures.
</p>
<h2 id="obnc-specific-modules">
OBNC specific modules
</h2>
<p>
The following modules are not portable to Project Oberon are implemented specifically for a targeted compiler.
</p>
<p>
<a href="obnc/artUnix.obn">artUnix</a> provides access to some Unix/C facilities.
</p>
<ul>
<li>
<code>Exit(exitCode : INTEGER);</code> will cause a program to exist with the given POSIX exit code.
</li>
<li>
<code>KernelName(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate <code>dest</code> with the name of the host OS kernel if known
</li>
<li>
<code>Architecture(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate the <code>dest</code> with the name of the host architectures, e.g. x86_64, armv7.
</li>
</ul>
<p>
<a href="obnc/artClock.obn">artClock</a> provides an abstraction layer working with the system clock. The implementation uses the C <code>clock_gettime()</code> and <code>clock_settime()</code>.
</p>
<h2 id="oxford-specific-modules">
Oxford Specific Modules
</h2>
<p>
<a href="oxford/artArgs.m">artArgs</a> provides an OBNC compatible Args module
</p>
<p>
<a href="oxford/artEnv.m">artEnv</a> provides an OBNC compatible Env module
</p>
<p>
<a href="oxford/artConvert.m">artConvert</a> provides an OBNC compatible Convert module
</p>
<p>
<a href="oxford/artUnix.m">artUnix</a> provides access to some Unix/C facilities.
</p>
<ul>
<li>
<code>Exit(exitCode : INTEGER);</code> will cause a program to exist with the given POSIX exit code.
</li>
<li>
<code>KernelName(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate <code>dest</code> with the name of the host OS kernel if known
</li>
<li>
<code>Architecture(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate the <code>dest</code> with the name of the host architectures, e.g. x86_64, armv7.
</li>
</ul>
<p>
<a href="oxford/artClock.m">artClock</a> is an abstraction layer for working with the system clock. It uses the C <code>clock_gettime()</code> and <code>clock_settime()</code>.
</p>
<h2 id="ofrontplus-specific-modules">
OfrontPlus Specific Modules
</h2>
<p>
NOTE: These modules are in the planning stages and hopefully included in the next release of Artemis.
</p>
<p>
<a href="ofronplus/artArgs.Mod">artArgs</a> provides an OBNC compatible Args module
</p>
<p>
<a href="ofrontplus/artEnv.Mod">artEnv</a> provides an OBNC compatible Env module
</p>
<p>
<a href="ofrontplus/artConvert.Mod">artConvert</a> provides an OBNC compatible Convert module
</p>
<p>
<a href="ofrontplus/artUnix.Mod">artUnix</a> provides access to some Unix/C facilities.
</p>
<ul>
<li>
<code>Exit(exitCode : INTEGER);</code> will cause a program to exist with the given POSIX exit code.
</li>
<li>
<code>KernelName(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate <code>dest</code> with the name of the host OS kernel if known
</li>
<li>
<code>Architecture(dest : ARRAY OF CHAR)</code> uses the POSIX command <code>uname</code> to populate the <code>dest</code> with the name of the host architectures, e.g. x86_64, armv7.
</li>
</ul>
<p>
<a href="ofrontplus/Clock.Mod">artClock</a> is an abstraction layer for working with the system clock. It uses the C <code>clock_gettime()</code> and <code>clock_settime()</code>.
</p>
<h2 id="project-approach-to-portability">
Project approach to portability
</h2>
<p>
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.
</p>
<ul>
<li>
Portable modules are in “root” project directory
</li>
<li>
Compiler specific modules their own sub directories (e.g. “obnc”, “oxford”and “ofrontplus”)
</li>
</ul>
<p>
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.
</p>
<h2 id="putting-it-all-together">
Putting it all together
</h2>
<p>
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.
</p>
<p>
An example is using <a href="Tests.Mod">Tests.Mod</a> for the <strong>clocktest</strong> implementations in both <strong>obnc</strong> and <strong>oxford</strong> 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 <strong>clocktest</strong> in the <strong>obnc</strong> directory.
</p>
<pre><code>export OBNC_IMPORT_PATH=&quot;.:../&quot;
obnc -o clocktest ClockTest.obn</code></pre>
<p>
With Obc-3 you can just provide the full path to the module you want to include. Compiling the implementation of <strong>clocktest</strong> in the <strong>oxford</strong> directory looks like —
</p>
<pre><code>obc -07 -o clocktest Clock.m ../Tests.m extEnv.m ClockTest.m</code></pre>
<p>
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.
</p>
<p>
FIXME: Document handling of imports and compiling OfrontPlus compiler.
</p>
</section>
<nav>
<ul>
<li>
<a href="/">Home</a>
</li>
<li>
<a href="./">README</a>
</li>
<li>
<a href="license.html">LICENSE</a>
</li>
<li>
<a href="install.html">INSTALL</a>
</li>
<li>
<a href="./obnc/">OBNC Modules</a>
</li>
<li>
<a href="./oxford/">Obc-3 Modules</a>
</li>
<li>
<a href="./ofrontplus/">Ofront+ Modules</a>
</li>
<li>
<a href="./development-notes.html">development notes</a>
</li>
<li>
<a href="https://github.com/rsdoiel/Artemis">Github</a>
</li>
</ul>
</nav>
<footer>
copyright (c) 2021 all rights reserved.
Released under the BSD 3-Clause license
See: http://opensource.org/licenses/BSD-3-Clause
</footer>
</body>
</html>