Re: A beginner's question

[Rudolf Schubert]

Hi Benjamin,

thank you for this 'super quick' answer!

Yes, I'm aware that the 'ISO-parts' in GPM and GM2 are different.
I could easily handle these differences, so my code can now be compiled on
both GPM and GM2 with one subtle exception which kind of amused me a bit:

In the DateTime RECORD there is one BOOLEAN member called summerTimeFlag
in GM2 and SummerTimeFlag in GPM. I needed a few seconds before I
realized that the capitalization of the starting 's' is different!

My 'real' problems go a bit 'deeper' but before I wanted to go in too
much detail I first wanted to make sure I'm really using the latest
version of GM2. I don't want to bore peeple with old stuff which is
not relevant any more;-)

But in short: it is the run time behaviour which is different without my
workarounds which I now have put in place.


1.      With WriteString from TextIO I can use this 'construct' with GPM

WriteString(cid, 15C+12C);

With GM2 compilation goes fine but when run I get:

RTExceptions.mod:648:35: In invalidloc
RTExceptions.mod:648:35:invalid address referenced

I did not dig too deep into this, perhaps the construct '15C+12C' here
is not quite 'legal'? But instead I now use this little helper and
everything is fine:

PROCEDURE WriteLnCrLf(cid: ChanId);
  VAR
    schnur2:                    ARRAY[0..1] OF CHAR;

  BEGIN                         (* PROCEDURE WriteLnCrLf *)
    schnur2:='  ';
    schnur2[0]:=15C;            (* CR *)
    schnur2[1]:=12C;            (* LF *)
    WriteString(cid, schnur2);
  END WriteLnCrLf;

You might ask why not using WriteLn from TextIO instead? I found that
I do need CR and LF in my output and WriteLn produced either only
CR (on Linux) or CR and LF on Windoze. So WriteLnCrLf was my quick
answer to the small problem.


2.      I do some 'recursive' string manipulation like this:

(I'm handling a simple linked list and I hope the short code snipped will be
clear even without TYPE declarations or explaining things in more detail.
But quickly: a (potentially) big input string 'schnur' should be transformed
into a linked list of smaller strings of length mittellen. Don't ask why I
used this method. I had many smaller strings but some very big ones and I
wanted to store them all in some array but did not want to use the biggest
possible string even for the small ones...)


PROCEDURE PutGPMString(schnur: ARRAY OF CHAR; index: INTEGER);
  VAR
    len:                        INTEGER;

  PROCEDURE GibRestFrei(VAR str_rec_typ_ptr: str_rec_typ_ptr_typ);
    BEGIN                       (* PROCEDURE GibRestFrei *)
      IF str_rec_typ_ptr<>NIL THEN
        GibRestFrei(str_rec_typ_ptr^.str_rec_typ_ptr);
        DISPOSE(str_rec_typ_ptr);
      END;                      (* IF str_rec_typ_ptr<>NIL *)
    END GibRestFrei;

  PROCEDURE LegRestAb(VAR str_rec_typ_ptr: str_rec_typ_ptr_typ);
    VAR
      schnur2:                  String_mittel;

    BEGIN                       (* PROCEDURE LegRestAb *)
      (* +++
      IF Length(schnur)>0 THEN
      *)
      IF len>0 THEN
        NEW(str_rec_typ_ptr);
        Extract(schnur, 0, mittellen, schnur2);
        Delete(schnur, 0, mittellen);
        len:=len-mittellen;
        IF len<0 THEN len:=0 END;
        Assign(schnur2, str_rec_typ_ptr^.value_strr);
        str_rec_typ_ptr^.str_rec_typ_ptr:=NIL;
        LegRestAb(str_rec_typ_ptr^.str_rec_typ_ptr);
      END;                      (* IF Length(schnur)>0 *)
    END LegRestAb;

  BEGIN                         (* PROCEDURE PutGPMString *)
    len:=Length(schnur);
    WITH input[index] DO
      GibRestFrei(str_rec_typ_ptr);
      LegRestAb(str_rec_typ_ptr);
    END;                        (* WITH input[index] *)
  END PutGPMString;


With GM2 I had to introduce the INTEGER len in order to correctly
trace the length of the ARRAY OF CHAR 'schnur' which is passed as a
parameter to PutGPMString. Actually with Extract the current length
of schnur should decrease each time Extract is invoked but GM2
constantly showed me the inital value of the length of 'schnur'.


3.      Then I had some very strange error when reading from a (text) file.
I did not yet try to see if I could produce a small example program for
this because, as mentioned I first wanted to make sure I'm using the
latest version of GM2. But in short again:

Line 33 and 34 of my (text) file (I guess 33 and 34 now are very important
information in this context;-)) look like this:

# spieler:
(frei)

At some point in the program my 'read pointer' was positioned at the
beginning of line 33 (# spieler:). This line serves me as a comment line
so I use a

SkipLine

to get to the start of line 34 ((frei))

With the next

ReadString

I then expected to read the string '(frei)' but what I saw was, that
the first character from the string was missing. So instead of '(frei)'
I only got 'frei)'. I then randomly played a bit and inserted another
'dummy' ReadString before the SkipLine and voila I suddenly did NOT
lose any characters!


4.      Perhaps a problem which might be related to 3. was the following:

Again when reading from my (text) file I used ReadInt from WholeIO.
But again this showed very strange results. I then replaced ReadInt
with a sequence of

ReadToken
StrToInt

and the problems were gone! Doesn't this sound strange?


Maybe two final remarks: if I try to generate a static binary this
fails with several messages that some references in RealMath.o are
undefined like this:

/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/12/m2/m2iso/libm2iso.a(RealMath.o): 
in function `RealMath_sqrt':
/build/gcc-12-bTRWOB/gcc-12-12.2.0/build/x86_64-linux-gnu/libgm2/libm2iso/../../../../src/libgm2/libm2iso/../../gcc/m2/gm2-libs-iso/RealMath.mod:35:
 undefined reference to `sqrt'

In fact I'm using RealMath only once in the program to calculate a square root.
If I dont do this and do NOT import RealMath I can get a static binary!


My last remark is the following: my program serves as a cgi on my web page.
I notice a remarkable difference in speed, i.e. how quick the browser does
show the next page. With GPM this is in an instant but with GM2 I notice
a clear delay. In my program I do read and write data from the above
mentioned (text) file which is my data base. When using strace I can see
that with GPM writing to my (text) file is done with very few writes.
With GM2 I literally see thousands of writes with 1 or 2 bytes. Would I
have a possibility to change this?

BTW, if someone likes to see 'my old program' in action this is simply
on my page:

https://www.dose.muc.de/squash1gd.cgi

The reason for doing the port is the Y2038 problem with the 32 bit
program. I think we agree that there are no more than a couple of weeks
till we arrive there and then no more registrations would be possible.
This is to be avoided!


BR

Rudolf


--
Rudolf Schubert                 \
Kirchstr. 18a                    \  mailto:rudolf@muc.de
82054 Sauerlach                   > http://www.dose.muc.de
Deutschland                      /
Tel. 08104/908311               /


On Fri, 7 Apr 2023, Benjamin Kowarsch wrote:

> Hi
> 
> On Fri, 7 Apr 2023 at 18:53, Rudolf Schubert <rudolf@muc.de> wrote:
> 
>               I'm about porting an old Programm developped with Gardens Point 
> Modula-2
>               (GPM) and facing a few problems.
> 
>  
> [snip]
>  
>              The modifications I made were to work around errors I suspect
>               might be caused by GM2. When using GPM, however I do not need
>               to use these workarounds!
> 
> 
> Without knowing what these errors are it is difficult to say, but it sounds 
> as if these errors are the
> result of the incompatibility between GPM and GM2 considering that GPM was 
> developed while ISO
> standardisation was still work in progress. John Gough and his team started 
> out with a PIM compiler and
> modified it as work on the ISO standard was under way and things were still 
> changing all the time. And some
> point they moved on to implementing a new compiler for a dialect of Oberon 
> called Component Pascal and GPM
> became orphaned. The final ISO specification was never fully implemented in 
> GPM.
> 
> This could easily be the reason why GM2 throws errors when trying to compile 
> the unmodified GPM code.
> 
> regards
> benjamin
> 
>