December 2023 - 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

Re: [Oberon] Removing WITH
by pfoten.falken0p＠icloud.com 31 Dec '23

31 Dec '23

Hello Peter Easthope, actually this makes a lot of sense. (How would the compiler know how to generate the code, if the dynamic type isn’t properly established.) I guess I’d be rather use a temporary variable than repeating the guard, but this is a matter of personal preference. Thank you for your patience. Sven

1 0

Re (2): Removing WITH
by peter＠easthope.ca 31 Dec '23

31 Dec '23

Pfoten & all, From: pfoten.falken0p(a)icloud.com Date: Sun, 31 Dec 2023 15:39:04 +0100 I guess I’d be rather use a temporary variable than repeating the guard, ... Yes, for most, this may be preferable. PROCEDURE Seek(R: ListRiders.Rider; key: SIGNED32); VAR r: Rider; BEGIN r := R(Rider); r.key := key; r.pos := 0; r.sortPos := 0; WHILE (r.pos < noMsgs) & (msgs[r.pos].pos # key) DO INC(r.pos) END; IF r.pos >= noMsgs THEN r.key := -1; r.pos := -1; r.sortPos := -1; r.eol := TRUE ELSE IF r.sort # NIL THEN WHILE msgs[r.sort[r.sortPos]].pos # key DO INC(r.sortPos) END END; r.d(ListRiders.Int).i := r.pos END END Seek; Thx, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Re: [Oberon] Removing WITH
by peter＠easthope.ca 31 Dec '23

31 Dec '23

Hello Sven, From: Sven Mertens <smertens(a)icloud.com> Date: Sun, 31 Dec 2023 07:55:26 +0100 > Consequently all operations of the dynamic type are legal without > adding a typeguard operand. If the typeguard is omitted, the FOX compiler in A2 complains. "undeclared identifier (selector).pos := R.(*!*) ..." Thanks, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Removing WITH.
by peter＠easthope.ca 31 Dec '23

31 Dec '23

Hi, This is from Oberon.Mail.Mod in A2. PROCEDURE Seek(R: ListRiders.Rider; key: SIGNED32); BEGIN WITH R: Rider DO R.key := key; R.pos := 0; R.sortPos := 0; WHILE (R.pos < noMsgs) & (msgs[R.pos].pos # key) DO INC(R.pos) END; IF R.pos >= noMsgs THEN R.key := -1; R.pos := -1; R.sortPos := -1; R.eol := TRUE; RETURN END; IF R.sort # NIL THEN WHILE msgs[R.sort[R.sortPos]].pos # key DO INC(R.sortPos) END END; R.d(ListRiders.Int).i := R.pos END END Seek; PROCEDURE Seek(R: ListRiders.Rider; key: SIGNED32); BEGIN R(Rider).key := key; R(Rider).pos := 0; R(Rider).sortPos := 0; WHILE (R(Rider).pos < noMsgs) & (msgs[R(Rider).pos].pos # key) DO INC(R(Rider).pos) END; IF R(Rider).pos >= noMsgs THEN R(Rider).key := -1; R(Rider).pos := -1; R(Rider).sortPos := -1; R(Rider).eol := TRUE ELSE IF R(Rider).sort # NIL THEN WHILE msgs[R(Rider).sort[R(Rider).sortPos]].pos # key DO INC(R(Rider).sortPos) END END; R(Rider).d(ListRiders.Int).i := R(Rider).pos END END Seek; Also took the opportunity to remove the non-terminal RETURN. Is there a better alternative to remove WITH? Thx, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Project Oberon 2013 compiler does not like large heap objects (but does not complain either)
by Michael Schierl 29 Dec '23

29 Dec '23

Hello, Today I spent about half the day debugging an issue with large heap objects. Consider this example: MODULE X; TYPE PD = POINTER TO D; D = RECORD large: ARRAY 512 * 1024 OF BYTE; here: ARRAY 5 OF INTEGER; END; VAR d: PD; PROCEDURE Go*; BEGIN NEW(d); d.here[2] := 42; END Go; END X. In particular, the size of D is more than half a megabyte. (In practice it was a bunch of nested RECORDs so its size was not that obvious). This results in the displacement to the LDR instruction becoming negative. If the system has more than 1 MiB of memory, it does not wrap back to the same location but instead corrupt some other memory 1MB before the location to be written. Tested the official compiler and also Andreas' Extended Oberon compiler. Would have been nice to show a compile time error in such a situation so that the user knows they have to refactor and not silently corrupt some memory. Regards, Michael

2 2

Unneeded restrictions on local procedures
by August Karlstrom 22 Dec '23

22 Dec '23

In two recent threads we have discussed scopes and local procedures in Oberon-07. One thing that I have been thinking about is that since the change was made to prevent access to intermediate scopes the restriction that a local procedure cannot be assigned to a procedure variable or passed as a procedure parameter no longer makes any sense. The sentence "P must not be declared local to another procedure, and neither can it be a standard procedure." in section 6.5 should be replaced with "P cannot be a standard procedure." and "If a formal parameter specifies a procedure type, then the corresponding actual parameter must be either a procedure declared globally, or a variable (or parameter) of that procedure type." in section 10.1 should be replaced with "If a formal parameter specifies a procedure type, then the corresponding actual parameter must be either a procedure, or a variable (or parameter) of that procedure type." What do you think? Regards, August

5 12

Re: [Oberon] Generality of notation for a number.
by peter＠easthope.ca 21 Dec '23

21 Dec '23

P.s. I know 0FFFFFFFFH works in the IA-32 based systems but wonder whether a more general notation is appropriate for an expanded target "audience". Thanks, ... P. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Generality of notation for a number.
by peter＠easthope.ca 21 Dec '23

21 Dec '23

Hi, Oberon.Mail.Mod has Files.WriteLInt(r, SIGNED32(0FFFFFFFFH) and d # 0FFFFFFFFH. Is the notation OK for 32 and 64 bit machines? Is there a better notation? Thx, ... P.L. -- VoIP: +1 604 670 0140 work: https://en.wikibooks.org/wiki/User:PeterEasthope

1 0

Unneeded restrictions on local procedures
by Andreas Pirklbauer 21 Dec '23

21 Dec '23

> Exactly! However, if the language allows you to assign that local procedure > to a global procedure variable the reader can no longer depend on that > being true. > > Regards, > Chris Burrows > CFB Software Except if one allows assigning a local procedure to a *local* procedure variable, or passing them as a parameter to a *local* procedure. That’s the one restriction that could (perhaps?) be lifted. MODULE M; TYPE Proc = PROCEDURE(i: INTEGER); PROCEDURE P; VAR p: Proc; PROCEDURE Q(i: INTEGER); END Q; PROCEDURE R(p: Proc); END R; BEGIN p := Q; (*should this be allowed?*) R(Q); (*should this be allowed?*) END P; END M.

1 0