- Oberon - mailman3.inf.ethz.ch

None
by None 19 Oct '26

19 Oct '26

The listing of available versions of Oberon links to various versions without a great deal of explanation as to why a new user should want one versus the other is confusing. The linking to Native seems inappropriate considering that Native is relatively obsolete. Not that Native/Beta is up-to-date but it would seem a better choice for those who intend to install a loopback (all in one FAT file) Oberon. When reading the documentation pages online each part begins to explain some portion of Oberon then gets sidetracked with exclusions for various versions. New users don't know or care about other versions and certainly don't need to be distracted by exclusions while trying to learn about their version of Oberon. It seems there was no desire to write separate up-to-date documentation for each version so that all versions are crammed together into a confusion of exceptions. Considering the diversity of file formats, and changes of command names I think it would be wise to have separate documentation and leave out all the exclusions? Difficult enough to become comfortable with the use of a two button mouse on a three button OS without being constantly reminded that whatever version you use others probably are using a different version with a different file system and different command modules. I could critique these pages line by line but I think anyone who looks at what is there objectively as a new user they would see what I see? Charles.Angelich DOS the Ghost in the Machine! Family And Friends wepages - Multimedia orginal stories with animation and sound, poetry, music, and photography: http://www.undercoverdesign.com/dosghost/faf Tech pages for DOS and W31 at: http://www.undercoverdesign.com/dosghost

1 0

None
by None 19 Oct '26

19 Oct '26

clear, important and appropriate to this discussion. Based on the work that I did in making the ISO_9660 compatible file system, I envision that a change to the file name scanner to include the "/" character in a file name would allow the command in the example to execute, and to give the results described, on a "flat" file system. Moreover, it would give additional power. I have some objections to this solution. You may also object to this solution. Can you explain why? From: "Ghost in the Machine" <cangelich(a)famvid.com> | > Let me explore the following user interface scenario. | > | > 1. A command of the nature | > System.Directories eMail/Y02/July/* | > produces list of file names that the user named and saved from email | > received in July 2002. | > | > Is this the sort of thing you are missing? | | Don't be patronizing. | | I want to be able to separate sets of files into subdirectories | not clump them all together in one huge directory. MSDOS | v2.1 had subdirectories - did you notice that? | |

1 0

None
by None 19 Oct '26

19 Oct '26

Philosophical Foundation 1. I want to make money and Oberon has a mix of novelty and completeness that may work. 2. I like Oberon and want to grow the user base to make its existance more assured. 3. I think society would be safer if software were based on well engineered open sourced systems. An open source, high quality, reliable operating system based on modules that is supported "commercially", and a sound educational program reinforce this foundation. | Aubrey, | | mcintosh(a)vima.austin.tx.us wrote: | .... | I believe a gentle and firm coordination of what already exists | can lead to a low overhead, low maintanence system that is useful | to a large number of individuals. I wish to avoid the opacity of | Microsofts Window's and its bloat. Openness is key. A small organization | lowers its operating expenses and keeps the cost to the consumer down. | ... > where the young become exposed to ... I remember the day I asked the old men how long it took them to get used to bi-focals, and *I really cared* what their answer was.

1 0

None
by None 19 Oct '26

19 Oct '26

1. The CD boot code. 2. A common network card driver. 3. A basic VGA driver, and advanced installer support. 4. Some type of file storage ability, whether RAMdisk, floppy, or perhaps FAT support. Diskless would probably be advantageous. 5. Attention to the sections of ECMA-119 and related documents that speak to multi-hardware boot environment support in CD-ROMs. All of these additional components other than 5 seem to be available in the Oberon community today, principally in the S3/ETH/Native/Bluebottle setting. Why V4 and not Bluebottle? 1. I have produced an entire doctoral dissertation using V4 for the entire production environment: data analysis, and document processing. I can speak with confidence and authority that it is stable and suitable. I have not heard a similar application claim from the S3 side (listening ...) 2. Bluebottle, on the face of it, it is not "bulletproof." Interesting, yes. Important, yes. Receiving much of my time, yes. Attractive because of color and motion, yes. Bootable from CD-ROM as is, yes. Suitable for mass distribution? What else is nice, given that a bootable system is demonstrated? 1. I am convinced that a 50 Mb download is a very large "activation barrier" that prevents more experimental use of Oberon I would make the boot core of the system contain a "net files" module. This 80-100 Kb core could be downloaded in a very short time, and pull in additional modules to local storage on an as needed basis. Subsequent boots would find an increasing inventory of relevant files on local storage. Individual files instead of a single image would be on well known distribution servers. With clever design, version updates would be painless using this incremental, intelligent transfer. 2. Micro-notary of files using PGP and the web of trust would mitigate against viruses. 3. CD-ROM archival is nice. I would like to explore an architecture that allows a first or new track to be written to the CD-ROM from the local storage at any moment in time. Mark the files on local storage for deletion on demand.

1 0

Potential New Approach to Implement Instance-Centered OOP in Oberon-07
by Andreas Pirklbauer 15 Oct '26

15 Oct '26

The Oberon-2 programming language offers a convenient notation for object-oriented programming (OOP), namely that of type-bound procedures. It is valuable in education. However, Oberon-2 uses a class-centered view rather than an instance-centered view, meaning that Oberon-2-style type-bound procedures (methods) can essentially be viewed as constants: the same procedure is bound to all instances of a type. This reflects the reality that, in most typical applications, the same procedure (handler) is indeed bound to all instances of a class. One advantage of this approach is that a programmer cannot accidentally forget to initialize the method bindings. A disadvantage is that the bindings are fixed at the type level. This makes a new feature necessary, namely method overriding. This in turn complicates the language and the compiler and, in fact, the conceptual model. See an earlier discussion of this topic, “Class Methods vs. Procedure Variables in Records,” on this mailing list in 2017. The Graphics module provides an example where the alternative view, namely the instance-centered view, is implemented “manually”. This is done by declaring a method record and initializing its method fields manually in the module initialization body. This is somewhat cumbersome and requires some discipline from the programmer. This raises the question whether one could combine the two approaches with the following new construct: Part A: Replace ObjectDesc and MethodDesc ------- Instead of the following declaration (see Graphics.Mod) TYPE ObjectDesc* = RECORD x*, y*, w*, h*: INTEGER; col*: BYTE; selected*, marked*: BOOLEAN; do*: Method; (*<---*) next: Object END ; MethodDesc* = RECORD new: Modules.Command; (*<---*) copy: PROCEDURE (from, to: Object); draw: PROCEDURE (obj: Object; VAR msg: Msg); change: PROCEDURE (obj: Object; VAR msg: Msg); selectable: PROCEDURE (obj: Object; x, y: INTEGER): BOOLEAN; ... END ; use: TYPE ObjectDesc* = RECORD (*<-- no more “do” field*) x*, y*, w*, h*: INTEGER; col*: BYTE; selected*, marked*: BOOLEAN; next: Object BEGIN (*signatures*) copy: PROCEDURE (from, to: Object); draw: PROCEDURE (obj: Object; VAR msg: Msg); change: PROCEDURE (obj: Object; VAR msg: Msg); selectable: PROCEDURE (obj: Object; x, y: INTEGER): BOOLEAN; ... END; The BEGIN section declares the operations supported by the record type, including their signatures. These are not ordinary record fields; they define the dispatch interface of the type. They effectively are forward declarations (a small drawback, as the compiler now has to check the equality of the signatures) Part B: Extend the intrinsic procedure NEW such that it essentially becomes a constructor ------- NEW(obj, copy, CopyLine, draw, DrawLine, change, ChangeLine, selectable, LineSelectable, …); The compiler would require NEW to provide an implementation for every operation declared in the BEGIN section. We use the keyword BEGIN deliberately to suggest that, very much like the BEGIN section of a module, it is used to initialize the various fields of an instance. In this case, the initialization is performed by NEW, and it is enforced by the compiler. This approach would essentially implement the same functionality as the original Graphics module—i.e. an instance-centered view—but without much of its boilerplate code and without the risk of accidentally forgetting to initialize the various method fields. Since the bindings are instance-specific, no overriding mechanism is necessary. It seems that this could provide an elegant way of implementing OOP without introducing any new language keywords. The implementation would of course be much simpler than type-bound procedures. Has anyone seen or done experiments in this direction?

5 12

[EXT] Re: Potential New Approach to Implement Instance-Centered OOP in Oberon-07
by Andras Pahi 11 Oct '26

11 Oct '26

> On the other hand, in section 26.1 of "An Oberon Compiler for the ARM > Processor" Niklaus Wirth says > > "Again, the rules of Oberon help with an abbreviation. It is, for > example, possible to specify, using P0 instead of R0 > > TYPE P0 = POINTER TO RECORD a, b: INTEGER END > TYPE P1 = POINTER TO RECORD (P0) c, d: INTEGER END > " > https://people.inf.ethz.ch/wirth/Oberon/Oberon.ARM.Compiler.pdf > > /August Done. It just took a few lines in ORP.Mod. The example above works as expected. Andras Pahi

1 0

Bye!
by peter.froehlich＠mailbox.org 10 Oct '26

10 Oct '26

Seeing as the "AI rot" has also taken this last refuge of Wirthian spirit I shall remove myself from the mailing list after what, 20+ years? Enjoy!

1 0

None
by None 02 Oct '26

02 Oct '26

of characters enclosed in quote marks (")." In contrast to an Oberon string, this string can contain quote marks. One quote mark in the target string is represented by two quote marks in this notation, as in APL. This is an ugly example as Chris might mind. The name of the service is Gulf"@"Net. The user is the 7 characters !@# $%^. The password is &*()_+. NetSystem.SetUser1 "pap" "Gulf""@""Net" "!@# $%^" "&*()_+" ~ So how is this? Can anyone imagine a case where it fails? es> ... implements ... Certainly willing to try. Might need help. es> I still hope that WebDAV can help here. Interesting. I am only beginning to learn about WebDAV. Regards, Peter E. http://carnot.pathology.ubc.ca/

1 0

None
by None 02 Oct '26

02 Oct '26

satisfying their timing requirememts must be a top consideration. Once you go out of your box, you have to face these unpleasant realities. eg. CPU > ser-port > modem > telco-line > ISP > ... To talk of 'throttling back until it flies'; instead of making the timing specs comply, sounds bad ? 1. Some years ago a version of n-o stand Alone often failed to dial the modem, yet DOS and linux always dialed. 2. Here in s.africa it is know that many modems need an extra string to 'get dial-tone'. Apparently there must be a specified time between when the machine 'looks' and when dial-tone is detected. Perhaps n-o should wait ? 3. n-o V2.3.2 standalone Mail.Panel failed to connect, yet V 2.3.6 DOSbased connected. I don't know of any software update and must assume a critical timing cause. 4. I'm still trying to find out why sometimes when I get an abnormal ppp disconnect; further retries fail unless I reboot or Ctrl-Break a few times immediately after Dialer.Dial PPP Device0 ~ The need to try a few times indicates a randomness - 'the roulette ball to fall in' while the "Dialer.Dial PPP Device0" task is still busy ? By monitoring with a second n-o box, I confirm that the strings sent to the modem are OK (except that V24.Panel does not show CR nor LF - which are important). Line and modem Status-register values for good and bad conditions, are different - for latter analysis. Perhaps these differences will points to hardware handshake problems ? If none of you have these problems or even believe them, it's because you all use M$ outspOOk ! Chris Glur. -- PS. I'm using 486 40 Mhz machines.

1 0

None
by None 02 Oct '26

02 Oct '26

> ....Sending [ATM1] > Waiting 60s for [CONNECT] {|ATD 3407501|ATM1||CONNECT} > Calling [PPPMain.StartInst PPP 2nm4nx6x@za] > ---- up to here is OK, then the following 2 lines do not occur: > End of script > IPCP is finally ready. Device opened. by software forcing a 'fail' (eg. a time out waiting for KeyBrdIn) at the various 'states' in the failure range, as indicated in the above trace; and confirming that NetSystem.SetUser <args> can/cannot re-run, will locate the problem. Ie. at which state(s) does a failure not reset/initialise, hence not allowing a new NetSystem.SetUser <args> ? Personally I don't favour this empirical method, and prefer a well understood/documented theoretical model which can be analysed. > Chris, before collecting the log you might > compile in my modification which numbers > frames. This will allow any discussion, between > you and Edgar for example, to refer to "frame n". > That should be easier than saying "Look at the > frame containing this hex string '...'". > I don't remember which module but it is > described in my PPPnotes Web page. Hacking down at the low level, without the supporting overview understanding is not recommended. I first need to get an overview. PS. this tread now deal with 3 related topics: 1. V24.Panel can't run after NetSystem.SetUser <args> runs, because of initialisation problems. 2. NetSystem.SetUser <args> can't re-run, when it fails at certain state(s) (as must be allowed for) because of initialisation problems ? 3. Maintainers/contributors need documentation re. multi-tasking for S3. -- Chris Glur. PS. Edgar uses the term "interrupt", where I say "failure". Ie. when the (serial port, modem) ppp-connection fails. Even for ones which are rare, such 'failures' must be catered for. That's the main design philosophy of the internet.

1 0