See if I can add support for OfrontPlus

[rsdoiel]

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.

[rsdoiel]

It looks like I need an i386 virtual machine so I can build BlackBox then build OfrontPlus. Both are expecting a 32 bit environment.

[Oleg-N-Cher]

You don't need a virtual machine and a 32-bit environment. Ofront+ natively works on any version of Linux or *BSD.

Quick build instructions:

• go to Target/Your_platform/Lib/Bin and run ./build (rebuild libOfront.a)
• go to Target/Your_platform/Bin and run ./build (rebuild Ofront+ and tools).

If your platform is not in the list, you can still try to build it, but you'll need to generate intermediate C files under another host system (Lib/Bin/o2c; Bin/o2c), move them (Lib/Obj/*; Obj/) to your system, and then compile them (Lib/Bin/cc; Bin/cc).

[rsdoiel]

On 7/25/21 1:33 PM, Oleg N. Cher wrote: You don't need a virtual machine and a 32-bit environment. Ofront+ natively works on any version of Linux or *BSD. Quick build instructions: - go to Target/Your_platform/Lib/Bin and run ./build (rebuild libOfront.a) - go to Target/Your_platform/Bin and run ./build (rebuild Ofront+ and tools). If your platform is not in the list, you can still try to build it, but you'll need to generate intermediate C files under another host system (Lib/Bin/o2c; Bin/o2c), move them (Lib/Obj/*;Lib/Obj) to your system, and then build them (Lib/Bin/cc; Bin/cc).

Thanks Oleg, this is good news (I don't have to setup another box!).  Let me give it a try.  I want to write a post about getting OfrontPlus up and also add any needed OfrontPlus specific modules to Artemis so that I can write Oberon-07 code and have it work with more compilers. All the best, Robert

[Oleg-N-Cher]

Dear Robert,
there are typos in Obn2.Mod:

PROCEDURE MAX*(x, y : INGTEGER) : INTEGER;  (* must be: INTEGER *) 

PROCEDURE MAX*(x, y : INTEGER) : INTEGER;
  VAR res : INTEGER;
BEGIN
  IF x > n THEN (* must be: IF x > y THEN *)

PROCEDURE MIN(x, y : INTEGER); (* must be: PROCEDURE MIN(x, y : INTEGER): INTEGER; *)

PROCEDURE ROT(VAR x, n : INTEGER);
BEGIN
  ROR(x, n);
END ROT;

Must be:

PROCEDURE ROT(x, n : INTEGER) : INTEGER;
BEGIN
  RETURN ROR(x, n)
END ROT;

Since SYSTEM.ROT is defined as:

Name	Argument types	Result type	Description
ROT(x, n)	x, n: integer type*	type of x	rotation (n > 0: left, n < 0: right)

SYSTEM.ROT does not get x as VAR parameter, but has returned result. See BlackBox: Dev/Docu/P-S-I.odc
Or see Ofront/Docu/OfrontUser.doc

PROCEDURE ROT (i: Int; n: LONGINT): Int;

After these fixes, Ofront+ builds Obn2.Mod:

ofront+ -s7 -48 Obn2.Mod

Artemis-Ofront+.zip

It is a little more complicated with other modules, since there are dependencies on Math, Out. Of course, we can develop these modules or layers for the libOfront.a library. What is your vision of this?

[rsdoiel]

Good afternoon Oleg,

Thanks for spotting this. I will correct it. My goal with Obn2.Mod is to easy the path of bringing historic
Oberon/Oberon-2 to Oberon-07. The less changes we need to make to the historic code the more likely we can keep
the code sustainable into the future.

I've started looking at Math and Out. Out in particular has allot of variance between dialects would benefit
from a common approach. In a POSIX environment I think Out will need C level integration so I'm stuck implementing
versions per compiler given the variance in how C code is integrated.

Math I think is in the same boat as Out but I am reluctant to attempt it yet. I've been out of University a very
long time and my mathematics is rusty. To get a good Math I need to develop a comprehensive set of tests to
verify the code. I have zero background writing Math libraries. It'll be a steep learning curve for me. Happy for
contributions, help or suggestions there.

My current thinking based on looking at Ofront+ and using OBNC and Obn-3 is any module(s) requiring C
need to have compiler specific versions. They should all have identical interfaces so the applications
importing them think of them as unified. Modules that can be implemented in pure Oberon-07 should be implemented
in pure Oberon-07. I think modules like String fall into that category.

A secondary goal (which Ofront/Ofront+ offer a path towards) is making the standard Oberon System libraries like Text
accessible as a standard library module in the POSIX environment. Most computing systems are graphical instead of the
old serial terminals I remember when I was young. While I happen to like the command line I don't want to be limited to
it. I haven't sorted out how a Text module should work to have compatibility with the many historic implementations
of Text. I think Ofront, for a POSIX environment, is probably a strong path forward.

Like with compiler specific Out, Math, etc, may Artemis should simply have multiple implementations of Text. You'd
include the version you want (e.g. S3, V4). Seems like allot of code to write and maintain but that might be best.

I know that Display will need to be compiler specific (assuming something like SDL2 or OpenGL is used for implementation)
at the C level). So there's that.

I want to thank you for both your contributions and patience. I'm new to Oberon and Oberon Systems and as I mentioned on the
list I'm can only be considered an Oberon hobbyist at this point. I'm looking forward to adding support for Ofront+ in Artemis.

All the best,

Robert

[rsdoiel]

Using Ofront+ after fixing typos I get the correct output per Oleg.

rsdoiel@notebook-rd2:~/src/github.com/rsdoiel/Artemis$ ~/OfrontPlus/Target/Linux_amd64/ofront+ -s7 -48 Obn2.Mod 
Obn2.Mod  translating Obn2  new symbol file    1616    

I've added a sub directory called ofrontplus to Artemis for any Ofront+ specific modules.

[Oleg-N-Cher]

Good afternoon Robert,
I want to inform you with joy that Ofront+ was able to translate all Artemis modules.

I even compiled it into a static library Artemis.a, which can be linked to our projects in the future.

I attach all the scripts for the build. I hope this will be interesting for you.

Artemis.zip

But I still don't have any implementations of the modules Math, Out, Strings and extConvert. Ofront+ has a sufficient set of libraries to make a layer for redirecting these interfaces to existing libraries located in Ofront.a

As for the other Oberon-07 compilers - I have no influence on their development or support.
If you'll have any questions specifically about Ofront+, I will be happy to answer, as I offer free support for my users.

Thank you for your activity!

[rsdoiel]

Hello Oleg, This is very exciting. I'm still learning ofront+. The fastest way for me to create In, Out, Err and Math would probably be to wrap C code. Is this acceptable in ofront+?  If so I think I can add those the next chance I get to work on Artemis. One of my motivations in Artemis is that working code is a really good form of getting people to support things. I think if I can have working code with three very different compilers, Ofront+, Obn-3 and OBNC then I can sorta prove that we (the Oberon programming community) should support a common standard set of modules again. So that make my job sorta two part, provide working usable code that works with at least three compilers and two then have conversations with the compiler's authors about normalizing Oberon-07 code support towards what make sense. It'll take me a while because this is all new and is happening when I can spare time. But I am patient about this and don't expect changes over night and more likely over a year or two. Again our exchanges has been so helpful. All the best, Robert

…

On 7/31/21 2:02 PM, Oleg N. Cher wrote: Good afternoon Robert, I want to inform you with joy that Ofront+ was able to translate all Artemis modules. image <https://user-images.githubusercontent.com/1090608/127752199-1cdaa27d-81e2-4e77-9a59-dbeac21f85a0.png> I even compiled it into a static library Artemis.a, which can be linked to our projects in the future. I attach all the scripts for the build. I hope this will be interesting for you. Artemis.zip <https:/rsdoiel/Artemis/files/6911813/Artemis.zip> But I still don't have any implementations of the modules Math, Out, Strings and extConvert. Ofront+ has a sufficient set of libraries to make a layer for redirecting these interfaces to existing libraries located in Ofront.a As for the other Oberon-07 compilers - I have no influence on their development or support. If you'll have any questions specifically about Ofront+, I will be happy to answer, as I offer free support for my users. Thank you for your activity! — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https:/notifications/unsubscribe-auth/AABJIPI6YLDIZL6ISIYGJRDT2RQIFANCNFSM5A62NE6Q>.

[Oleg-N-Cher]

Hello, Robert. I am also glad of our productive communication.

Ofront+ has very good support for linking to the C language, partly inherited from Ofront, partly from CPfront, I did a lot myself.

I am attaching a new Artemis build to show you these features. I think I've done everything except Out.Real. I didn't have any ideas for it, although it's supposed to be easy to do with UNPK.

Artemis-Ofront+.zip

But I didn't test this code!

.Def differs from .Mod in that it does not generate .c, but only .oh (Oberon Header). Using extension ".oh" is the suggestion of Stewart Greenhill to avoid a name conflict with C (for example, math.h is a C library, and Math.oh is a header generated from Oberon). I didn't agree at first, but then I realized the wisdom of this decision. I am sure that there are many more such things, thanks to which Ofront+ will seem to you a well-thought-out translator, made very carefully.

Perhaps we can profit from the implementation of Out.Real from libraries for other Oberon-07 translators/compilers. But I'll leave that up to you. I would have made Out.Real long ago, but I am confused by the second parameter (margins).

[Oleg-N-Cher]

Slightly optimized/fixed module extConvert.zip