June 2024 - 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

Notes about the A2 Oberon repository at ETHZ.
by peter＠easthope.ca 29 Jun '24

29 Jun '24

Hello All, To be more palatable for a novice external to ETHZ, I've just overhauled the notes between headings https://en.wikibooks.org/wiki/Oberon/A2#The_A2_Repositories and https://en.wikibooks.org/wiki/Oberon/A2#Git_in_a_Unix-like_System . Feedback from anyone who reads the few lines can be helpful. Writing something which baffles a reader is too easy; fresh eyes can help. Thanks! ... P. L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re (2): Reconciling branches in the git repository.
by peter＠easthope.ca 25 Jun '24

25 Jun '24

Michael, From: Michael Schierl <schierlm(a)gmx.de> Date: Mon, 24 Jun 2024 23:42:10 +0200 > "git pull" will pull changes from a branch and ... Thanks for the detailed explanation, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re: [Oberon] Reconciling branches in the git repository.
by Michael Schierl 24 Jun '24

24 Jun '24

Hello, Am 16.06.2024 um 20:36 schrieb peter(a)easthope.ca: > Currently the A2 repository has branches main, bohdan and override. > > main seems a reasonable choice for me. Therefore, to update the local > copy of the repository, did this, > root@imager:/home/root/A2# git pull origin main > with this result. > > hint: Pulling without specifying how to reconcile divergent branches is > hint: discouraged. You can squelch this message by running one of the following > hint: commands sometime before your next pull: > hint: > hint: git config pull.rebase false # merge (the default strategy) > hint: git config pull.rebase true # rebase > hint: git config pull.ff only # fast-forward only > hint: > hint: You can replace "git config" with "git config --global" to set a default > hint: preference for all repositories. You can also pass --rebase, --no-rebase, > hint: or --ff-only on the command line to override the configured default per > hint: invocation. > > If a specific branch is pulled, why is reconciliation necessary? "git pull" will pull changes from a branch and integrate them to your current working copy. If your working copy currently is not at a state that is a previous state of the branch you are pulling (e.g. has local modifications, or was on a different branch altogether), this may result in a merge or rebase. If you do not want that, you can choose the third option. If, on the other hand, your working copy is at a previous state of the working copy you are pulling, the option does not matter and git will always perform a fast forward. In case you want to just switch your working copy to match a branch (discarding the your current working copy commit), you can use "git checkout" instead. "SVN update" is similar to "git pull" with using rebase strategy (second option). Which is (if I recall correctly) the reason why they added this hint message, as git's default action is the first one and it confused people with a SVN background. Regards, Michael

1 0

Reconciling branches in the git repository.
by peter＠easthope.ca 16 Jun '24

16 Jun '24

Currently the A2 repository has branches main, bohdan and override. main seems a reasonable choice for me. Therefore, to update the local copy of the repository, did this, root@imager:/home/root/A2# git pull origin main with this result. hint: Pulling without specifying how to reconcile divergent branches is hint: discouraged. You can squelch this message by running one of the following hint: commands sometime before your next pull: hint: hint: git config pull.rebase false # merge (the default strategy) hint: git config pull.rebase true # rebase hint: git config pull.ff only # fast-forward only hint: hint: You can replace "git config" with "git config --global" to set a default hint: preference for all repositories. You can also pass --rebase, --no-rebase, hint: or --ff-only on the command line to override the configured default per hint: invocation. If a specific branch is pulled, why is reconciliation necessary? Thanks, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

An alternative for the present inaccurate Math.ln(x)
by Hans Klaver 03 Jun '24

03 Jun '24

Hi all, Did anyone notice that the Project Oberon 2013 Math.ln(x) function gives very sloppy results, only the first decimal or first few decimals being correct? While trying to produce a fractal on letter H (a nice programming task when your name is Hans ;-) and getting the result in figure 1, I first blamed my home grown graphics routines, but it soon became clear that Math.ln was the culprit. I use that function in my implementation of Math.power() which I need to calculate a contraction factor for the fractal. To see the inaccuracy just calculate ln(5.0) with a calculator or on www.wolframalpha.com and compare it with the result of Math.ln(5.0): the correct result to 6 decimal places should be 1.609438E+00 but Math.ln gives 1.621313E+00. First I hoped that a typo was the cause: in the PO book (Applications, p. 83) constant q1 = 6.176106560E1, whereas in the source q1 = 6.76106560E1. But changing that value gave little improvement. With the help of two older Oberon implementations I was able to figure out a correct version of Math.ln(x) which also uses the UNPK(x, e) standard procedure, and doesn't need to import SYSTEM. The new correct version turns out to be even simpler than the present one. PROCEDURE ln* (x: REAL): REAL; (* hk 18 May 2024 *) CONST c1 = 0.70710678; (* 1/ sqrt(2) *) c2 = 0.69314718; (* ln(2) *) c3 = 0.89554059; c4 = 1.82984424; c5 = 1.65677798; VAR e: INTEGER; y: REAL; BEGIN ASSERT(x > 0.0); UNPK(x, e); y := x * 0.5; INC(e); IF y < c1 THEN y := 2.0*y; DEC(e) END; y := (y-1.0)/(y+1.0); y := c2*FLT(e) + y*(c3 + c4/(c5 - y*y)) RETURN y END ln; PROCEDURE ln*(x: REAL): REAL; (* INCORRECT version *) CONST c1 = 0.70710680; (* 1/sqrt(2) *) c2 = 0.69314720; (* ln(2) *) p0 = -9.01746917E1; p1 = 9.34639006E1; p2 = -1.83278704E1; q0 = -4.50873458E1; q1 = 6.76106560E1; q2 = -2.07334879E1; VAR e: INTEGER; xx, y: REAL; BEGIN ASSERT(x > 0.0); UNPK(x, e); IF x < c1 THEN x := x*2.0; e := e-1 END ; x := (x-1.0)/(x+1.0); xx := x; y := c2*FLT(e) + x*((p2*xx + p1)*xx + p0) / (((xx + q2)*xx + q1)*xx + q0); RETURN y END ln; The two older versions (one from 1995 by Michael Griebling and another by an unknown author from the 1999 ETH Oberon System 3 release 2.3) give the exact same correct results, but could not use UNPK and therefore are much more and somewhat more convoluted. The procedures UNPK and PACK prove very useful to implement these mathematical functions. In Griebling's version the functionality of UNPK is given by two functions fraction() and exponent() and that of PACK by a function scale(); they need SYSTEM.VAL() and SET. Also in the 1999 ETH version SYSTEM.VAL() and SET is used. You can find them on my GitHub pages, along with a TestMath module. (https://github.com/hansklav/Oberon-07-Math.ln/tree/main) There you can also find the (imho) missing arctan() function. (https://github.com/hansklav/Oberon-07) As far as I could test them the other functions in module Math (sqrt, exp, sin, cos, arctan) are accurate enough. For those who are puzzled by procedures UNPK and PACK it may be informative to know that in most other languages their functionality is given by functions named frexp() and ldexp() or scalbn(). These routines are used to extract the binary fraction and exponent of 2 from a floating-point value, and to synthesize a float from these components. They provide a way to get at the internal representation of a float without doing direct bit manipulation. Wirth only used them in module Math. With the new Math.ln() function the H fractal looks much prettier ;-) Regards, Hans Klaver

5 8