rsdoiel / artemis Goto Github PK

Texts is used in most Oberon System Programs. There are two general use cases in a POSIX environment.

1. Integrated into a graphical application
2. Headless in an command line application

In a GUI target implementing Display on top of SDL2 makes allot of sense given the ability to wrap C code in a POSIX implementation of Oberon-07.

In a headless use case we could just use a dummy Display and Fonts. Which Display and Fonts included in a compiled program could be controlled via module include paths.

Oleg-N-Cher would like Artemis to work with OfrontPlus. OfrontPlus is built in Component Pascal. I need to figure out to setup and run an environment that supports Component Pascal compilation so I can install OfrontPlus and include that in the compatibility modules and testing.

I would like to port some of my text processing code from Go to Oberon 07. One of them is a preprocessor for Pandoc. It needs to build up data structures, write them out as JSON documents in a tmp file and then run exec using Pandoc to process the final output.

In Go (like Python or even C) this is provided in a module. The go "os/exec" module has a nice interface and is not far from being Oberon-ish. Think about adding an Exec.Mod, ExecTest.Mod to Artemis project source. It could be implemented using C's exec. I will need to pay close attention to handling standard input, error and output.

If I want to have Artemis folded easily into other Oberon project I need to using the prefix "art" so that Artemis modules can be easily adopted. There are three cases to consider about prefixing (all related to modules which are not canonical to Artemis).

1. Artemis ports of modules from other projects, these should be prefixed
2. Artemis implementations of Oberon System modules for POSIX, these should be prefixed
3. Artemis implementations of Oakwood modules, these must be prefixed "art"

Q: Should Artemis' canonical modules be prefixed?

I've already run into the case where I had a MAXSET value in Obn2.Mod, Chars.Mod, DStrings.Mod. I think having the module Artemis.Mod only hold common constant values (currently two) is problematic because on small Oberon Systems there is a price to load one more module. Also I am not sure a common global modules improves modularety. I need to make a decision on this and document it.

I need to add information about using OfrontPlus compiler for compiling Artemis modules. Also need to explain my "art" prefix naming approach.

In my C extensions I've used a sub directory to hold the bodies of the C functions I've implemented. In this directory I've used the conventions of the module name, period, function name with an "inc" extension. I've also include example C programs where I though it useful to show the behavior of the libc or other C libraries I am wrapping for use in Oberon-07.