March 2026 - Oberon - mailman3.inf.ethz.ch

Re: [Oberon] Export of Oberon Mail.SendCmd().
by Joerg 30 Oct '26

30 Oct '26

Generally, re-using code instead of copying is a good approach. If you do so, then the whole code of Mail is imported in News. Possible but perhaps there is even a better approach to re-use code. What about this: try to separate all common code in an own module (e.g call it Communication.Mod or MsgBase.Mod or Utilities.Mod or so) and import this new module in Mail and in News. br Jörg > Am 14.06.2023 um 19:53 schrieb peter(a)easthope.ca: > > Hello again, > > Several procedures in Mail are used in Oberon News. Rg.: > Mail.ParseContent(), Mail.DecodeMessage() & Mail.GetSetting(). > > Is export of SendCmd() and use in News objectionable? > Ie. in Mail, change PROCEDURE SendCmd(...) to PROCEDURE SendCmd*(...). > > Thanks, ... P. > > - > mobile: +1 778 951 5147 > VoIP: +1 604 670 0140 > > -- > Oberon(a)lists.inf.ethz.ch mailing list for ETH Oberon and related systems > https://lists.inf.ethz.ch/mailman/listinfo/oberon

1 0

ulmo - revival of ulm oberon system
by նորայր 14 Mar '26

14 Mar '26

Hello, I would like to announce that i have managed to revive the Ulm's Oberon System. It didn't work for years, for different reasons, most importantly: a) libelf changes. that was possible to solve by downloading tof2elf executable frum Ulm's website. Or using your own archived copy. It's not possible anymore to download it, but I had one. b) Linux object file format changes, because of address space randomization. I was approaching this task many times, as I do with other things I want to do, over the years. Once I managed to compile my tof2elf, but then I realized libelf changed, and tof2elf logic should be changed as well. Then at some point I came up with a linker script that helps to prepare compatible object files. I had a binary installation from 2006, I used it to bootstrap the new version of the compiler. I remember, I liked Ulm's Oberon Compiler for some reasons, and disliked for others: Back then I was able to run Native Oberon on a very weak hardware. I could recompile the compiler. But Ulm's Oberon required lots of memory and would make my computers thrashing. I know that my computers had less memory than was normal at the time, but yeah, it is what it is. I felt that it's not good for an Oberon compiler to be as slow, and to not be able to compile a helloworld when I had 32mb of RAM. What I liked was that it behaved sort of like FreePascal, its standard library only used Linux syscalls, it had beautiful interface with System.Unixcall, and resulting binaries did not depend on libc, but only required kernel. That's a very important advantage, and it made this revival much easier, because I worked on a 64bit Linux. I also liked that it preserves the way Modula-2 worked with separate definition files that must be written by the programmer. Well I have relaxed that rule a bit, if the main module has no definition, the stub definition would be written so the compiler could build it. Ok long story short, there were two releases: In 0.9 I revived the compiler. It works on a modern Linux machine. It is able to compile files. It uses same way of building, with pons and cdbd. And it is slow even on my 11th gen Intel machine. In 0.10.0 I managed to make it possible to not use pons and cdbd anymore. Now the compiler is able to build files right from the file system. Not necessary to check in those to the db. However the old way is still supported, in case someone needs it. Now the build is so much faster! It's not as fast as OP2, the library is rich with abstractions, and the compiler uses those abstractions, and it's not as fast as OP2 is, but compared to today's compilers it's very fast and simple. I also made sure that the compiler can work like fpc works: you provide it the main module, and it'll automatically figure out dependencies, and build the dependencies. You may supply paths to sources. There's a test in src/test that illustrates this. Yes, there's a makefile, but it is just for showing the user the command. Makefile is not necessary, Oberon has strict module hierarchy, and compiler is able to figure out the dependency tree by itself. Actually that functionality already existed in Ulm's compiler, just it was working with files that exist in db, not on file system. So anyway, it works now, it produces 32bit binaries on 64bit system. tof2elf is compiled to a 64bit binary on a 64bit system, but that's fine. The project repository is https://github.com/norayr/ulmo currently. Sorry for github. I know I need to migrate everything from there one day. Ulmo is from Tolkien world, and I guess it's legal to use it. Vala is from there too and nobody complained afaik. Hope this will be useful. Meanwhile I'd like to gradually add amd64 support and HUGEINT type. Then maybe aarch64 and 32bit ARM. The compiler backend has a beautiful abstracted interface and everything clearly is divided to separate modules, but still, it's a lot of work. I have other projects and other work in life. norayr

1 0

Stand-alone version of the OP2 compiler and a Multiboot version of the Oberon System 3
by Rochus Keller 06 Mar '26

06 Mar '26

Hello everyone In case anyone is interested, I implemented a stand-alone version of the OP2 compiler included with the Oberon System 3 v2.3.7 which only depends on the C99 standard library and the Boehm GC and thus runs on virtually every platform. See here for more information: https://github.com/rochus-keller/op2/ There is also an Oberon IDE with syntax coloring and semantic navigation, a tool to create and populate AosFs volumes and a C version of the bootlinker with some additional features. With this tools I was able to implement a modified system/Kernel which can directly parse the Multiboot info and thus no longer depends on the complex Oberon Boot Loader (OBL, written in assembler) and the difficult procedure to create a compatible MBR bootable drive to install the system. All ~ 350 modules were compiled with the mentioned OP2 version on my Linux machine which took less than a minute including the drive and file system setup. See here for more information: https://github.com/rochus-keller/OberonSystem3Native There are also precompiled versions of the tools and the QEMU image directly available for download. Best regards Rochus Keller

1 0