October 2022 - Oberon - mailman3.inf.ethz.ch

SYSTEM.PTR vs SYSTEM.ADDRESS
by Deadmarshal 01 Nov '22

01 Nov '22

Hi, What is the difference between SYSTEM.PTR and SYSTEM.ADDRESS? As far as I've read they both seem to be void pointers? How does one cast a void pointer in Oberon? for example in C we have: void *ptr; casting and dereferencing: *(int*)ptr; Do you also have a small example of how to use SYSTEM.Get() and SYSTEM.Put() functions? regards

5 4

Realloc function and simulating continue and break in Oberon-07 loops
by Deadmarshal 24 Oct '22

24 Oct '22

Hi, I was wondering how one can break and continue loops in Oberon-07? In Oberon-2 there is a LOOP keyword which has EXIT to break the loop, but it is removed from Oberon-07, and the EXIT keyword can't be used in FOR or WHILE loops. I was also wondering if a realloc() function similar to C can be made in Oberon? Because it can be used to create dynamic arrays much like the CPP's std::vector. I am well aware that I could use a linked list for that purpose, but I'm curious about dynamic arrays. Regards

11 35

B2 Framework
by Andreas Pirklbauer 24 Oct '22

24 Oct '22

> But you promised to keep it frozen while you keep working on your mainline compiler… > which has many safety enhancements. It will feel safer to follow your mainline. Yes I did promise that, but I recently couldn’t resist and decided to add some new features indeed, for example to allow importing modules in any order. However, all compilers of the repository - including said retro-compiler - are *always* automatically kept in sync with the mainline compiler ;-)

1 0

B2 Framework
by Andreas Pirklbauer 24 Oct '22

24 Oct '22

> Being a user, I would welcome closer collaboration. Adding a "retro" flag to the compiler would help Wojtek, just as a reminder: The retro-compiler under Extended Oberon is available at http://github.com/andreaspirklbauer/Oberon-retro-compiler This is your retro flag. It runs as is. Andreas

2 1

Naming; was, Re (3): Multiple RETURN in a procedure
by peter＠easthope.ca 24 Oct '22

24 Oct '22

Throughout the wikibook I've preserved original content and format as closely as possible. That includes names. In case a page is revised, earlier versions are available via history. From: peter(a)easthope.ca Date: Mon, 24 Oct 2022 06:24:04 -0700 > ... André's tutorials. Also in the wikibook is the ETH bibliography. https://en.wikibooks.org/wiki/Oberon/books The name "books" was on the ETH server. Therefore propagated here. Strictly, a misnomer. The majority of the documents are not books. The title of the page is "Oberon Bibliography". For consistency, I'd prefer this URL. https://en.wikibooks.org/wiki/Oberon/Bibliography The move can be a link allowing access vi both names. https://en.wikibooks.org/wiki/Oberon/Bibliography links to https://en.wikibooks.org/wiki/Oberon/books Or https://en.wikibooks.org/wiki/Oberon/books links to https://en.wikibooks.org/wiki/Oberon/Bibliography Will anyone view the change as disrespectful? Thanks, ... P.L. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re (2): Multiple RETURN in a procedure
by peter＠easthope.ca 24 Oct '22

24 Oct '22

From: Chris Burrows <cfbsoftware(a)gmail.com> Date: Mon, 24 Oct 2022 19:39:21 +1030 > If you are considering bidding for this work ... I suggested bounties for revised procedures or Modules. Bidding for a work is a completely different model; in my view inappropriate for the objective. In any case, I'm still busy with details in André's tutorials. > 18,800 Lines of code > 37 Modules > > Before: 181 RETURNs > After: 126 RETURNs > > The edit and compilation exercise took a total of 3 hours and I had the > added satisfaction of being able to eliminate a LOOP in the process :) Thanks for the stats. Wojciech mentioned 3 k lines. According to your results all his revisions should be completed in a few hours. =8~) > Most of the changes were mechanical but there are a few which will > require more than a smoke test. Inevitably, revision and testing reveals further possible improvements. Elusive bugs bite. (The devil is in the details.) Meanwhile other things need attention. A few days soon pass. Time flies when having fun. Regards, ... P.L. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re: [Oberon] Multiple RETURN in a procedure
by peter＠easthope.ca 24 Oct '22

24 Oct '22

Wojciech, From: "Skulski, Wojciech" <skulski(a)pas.rochester.edu> Date: Sun, 23 Oct 2022 04:04:36 +0000 > But I am now facing three thousand lines of my Oberon-2 library. Roughly 50 pages. Someone moderately skilled in the language might spend a few hours revising a page? Pessimistically say four hours/page? For 50 pages, roughly 200 hours or a month. Understandable that you can't spare that time without significant neglect of existing responsibilities. =8~/ The world has millions of young whippersnapper programmers well skilled to make such revisions but lacking direction. With a bit of incentive, the challenge to revise a procedure or module would intrigue some. =8~) Offer a bounty. Thirty dollars per module for example. It's a token. The real incentive is the challenge to collect it. A similar concept was famously successful for Donald Knuth. https://en.wikipedia.org/wiki/Donald_Knuth#Humor Obviously, rules are necessary. * Verifiable identification of respondent. * Code compiles in the target system without error. * Test commands execute without error. * Revision accepted by judges? * Secure means to pay bounty. PayPal? WorldRemit? Wiki software could help with administration. Regards, ... P.L. mobile: +1 778 951 5147 VoIP: +1 604 670 0140 https://en.wikibooks.org/wiki/User:PeterEasthope

2 1

Multiple RETURN in a procedure
by Andreas Pirklbauer 24 Oct '22

24 Oct '22

> I was actually looking at source code downloaded from ETH. This > source code is dated 1994 and is accompanied by the note: > > "This directory contains the sources of the Oberon System > version 4 for Ceres-2 Workstations. They replace the earlier > version 1 sources described in the book "Project Oberon” Correct, so N. Wirth started from the original version 1 sources when creating Project Oberon 2013. As a side comment, with respect to the LOOP statement - same problem with its multiple EXITs - when porting the compiler itself, he noted in http://people.inf.ethz.ch/wirth/Oberon/PortingOberon.pdf "There were only 4 loop statements in the compiler – a sign of good programming :-) ... In my experience, a careful search for a new formulation is worth while. In all cases, the new solution turned out to be more satisfactory.” So he clearly wanted to promote the new programming style (and actually enforced it by not allowing the old constructs). Personally, I would have considered adding a “retro" option to the compiler, such that it also accepts old language constructs. But N. Wirth never did that in any of his compilers (if I am not mistaken) since the 1960s. He may have felt that then people will just leave the old code and one ends up with a mix of old and new language constructs. But the market / software industry would not accept that.

1 0

Multiple RETURN in a procedure
by Andreas Pirklbauer 24 Oct '22

24 Oct '22

> Wirth apparently believed the improvement to the language outweighed > the effort of having to rework it for project Oberon 2013 - and he had a. > choice I thank him for having the courage of his convictions. For TextFrames the effort was rather small though. The only place with multiple returns was a single procedure (procedure Min(i,j) incidentally.). There were a few LOOP statements with multiple EXITs though (same problem), e.g. in LocateString, LocateChar, FlipSelecton. But I totally agree with: > I think that the underlying issue is: How do you write substantial > pieces of software based on a changing language? The fact that backward compatibility in language design was never taken seriously in the Pascal - Modula - Oberon line of languages created a lot of legacy code that periodically needed rework and very likely contributed to the more limited adoption of Oberon (as compared to Pascal). In industry, a language that is not backward compatible with itself is bound to face adoption issues.

2 1

Two positions open at SkuTek Instrumentation
by Skulski, Wojciech 18 Oct '22

18 Oct '22

Hello: If you know someone who wants to work with us, and the candidate is either a US citizen and permanent resident, then please forward this e-mail to such a person. Position #1 is exclusively Linux... There may be some Oberon in Position #2. Thank you! We have two openings at SkuTek, both related to Nuclear Physics. The positions are funded by the Department of Energy Office of Science (Nuclear Physics) under Small Business Innovation Research (SBIR). Please forward this info to interested parties. SkuTek Instrumentation is a small high tech company located close to the University of Rochester, Rochester, NY, USA. We are especially proud of developing and delivering the Digital Data Acquisition for LUX-Zeplin detector (digitizers and logic modules, ~1500 digital channels in total). Full descriptions and how to apply: SkuTek.com --> click on "Job openings" at the upper-right of the page. 1) Software Engineer (Full or Part-Time). SkuTek Instrumentation has an opening for a Software Engineer to help develop 100+ Gbps data acquisition and data management systems for experimental physics, astronomy, astrophysics, and related fields. The data will come from research instruments such as Nuclear Physics detectors, astronomical telescopes, radio telescopes,etc. This will involve reading out from front end electronics, online processing and caching of data, and then transferring it over ESNet, or other scientific networks. Necessary skills include Linux and Windows system administration, networking, and low-level computer science. Experience with NERSC, ESNet, or other experimental facilities will be a plus. There will be opportunities to work on other company projects such as digitizer development or instrument control. The position is appropriate for a computer-savvy physicist, astronomer, electrical engineer, or computer scientist. Work will involve partnership with research community at National Labs and universities. 2) Electrical Engineer: FPGA and Embedded Development SkuTek Instrumentation has an opening for an Research Engineer to help develop instruments for scientific research and education. The instruments consist of analog-to-digital converters (ADC), field programmable gate arrays (FPGA), and embedded processors. The position is appropriate for an engineer with experience with VHDL, Verilog, FPGA architecture, and low level embedded programming. We will also consider a physicist with hands on experience with a variety of detectors and nuclear electronics, both digital and analog. The physicist must be highly motivated to quickly learn essential FPGA techniques. Experience with board design (both schematic and layout), soldering, and troubleshooting will be a plus. Work will involve partnership with research community at National Labs and universities. -- Wojtek Skulski wojtek(a)skutek.com

1 0