[Oberon] OLR and data storage.

Peter Matthias PeterMatthias at web.de
Tue Oct 13 20:35:19 CEST 2015


Hi Jan,

which exact system are you using?

As long as a direct call of this kind:

mask:="*.Mod"
name:="ABCD.Mod"
name:="123";
IF Match(mask, name) THEN ...

leads to wrong results, the matching problem is clearly caused by the 
algorithm. I don't have other systems, but I am sure, other systems will 
give same wrong result. The algorithm worked at conditions which can not 
be taken as guaranteed.

Regards,
	Peter

Am 12.10.2015 um 14:08 schrieb Jan de Kruyf:
> Hallo,
> further to the  report about my tests:
>
> Unfortunately I have to report that also on my system strange things happen.
> While doing some edit-compile-trap cycles to debug the dotty diagram
> software
> I notice strange things happening in my Edit viewer. Text goes missing
> at random and
> Oberon.Par.text and Oberon.Par.pos stop working as advertised.
> Also copying from the Oberon.Log misbehaved once.
>
> While I do this I keep a fresh copy open in Emacs that I update as and
> when required.
> So fortunately I can always reload the module text, and my disk file
> does not get corrupted.
>
> However, I suggest that we have a memory leak somewhere, in light of the
> various unexplained
> happenings.
>
> Cheers,
>
> j.
>
>
>
> On Sat, Oct 10, 2015 at 4:32 PM, Jan de Kruyf <jan.de.kruyf at gmail.com
> <mailto:jan.de.kruyf at gmail.com>> wrote:
>
>     PeterE,
>
>     Here is the results of my tests.
>     Setup:
>     I copied PeterM's mod to the Enumerate procedure so I now also have
>     sub directory listings, like you.
>
>     It is very nifty in fact, Thank you Peter!.
>
>     I left my Match procedure in place for the time being. Although PM's
>     works, that is no issue.
>
>     So this is what I put in the beginning of my Match procedure:
>     -------------------------
>     PROCEDURE Match(VAR mask, name: ARRAY OF CHAR): BOOLEAN;
>     VAR m,n, om, on: LONGINT;
>     f: BOOLEAN;
>     BEGIN
>         (* test *)
>         n := 0; m := 0;
>         WHILE (name[n] # 0X) DO INC(n) END;
>         name [n + 1] := 055X;
>         WHILE mask [m] # 0X DO INC (m) END;
>         mask [m + 1] := 055X;
>         Kernel.WriteString (name); (*======================*)
>         Kernel.WriteLn;
>         Kernel.WriteMemory (SYSTEM.ADR (name), 32);
>         Kernel.WriteLn;
>         (* end test *)
>     m := 0; n := 0; om := -1;
>     ..
>     ..
>     ----------------------------------------------------
>     So when I open Kernel.Log either on the Linux side or in Oberon I
>     see the name string and what comes after it.
>
>     Without the 2 WHILE loops I had multiple 0X's after the name string
>     With those loops there is 0X, 055X as programmed for.
>
>     In both instances I get a perfectly normal directory or subdirectory
>     listing.
>     QED.
>
>     So at this moment with the information I have I will say that there
>     is a serious issue with the OLR setup.
>
>     You dont just get rubbish out of a piece of code that has worked for
>     years and can be proven to be correct, no doubt.
>
>     The next step would be that Peter Matthias gives us some information
>     on how the Linux kernel interface works in OLR.
>     I seem to have issues recognizing the assembly code (that says a lot
>     about me of course :)
>     But as a general rule I do know my way around in the kernel and how
>     to talk to it.
>
>     And could you send me perhaps the outcome of this incantation in a
>     terminal on your machine:
>
>     uname -a
>
>     so we compare.
>
>     cheers,
>
>     j.
>
>
>
>
>
>
>
>     On Thu, Oct 8, 2015 at 10:37 PM, Jan de Kruyf
>     <jan.de.kruyf at gmail.com <mailto:jan.de.kruyf at gmail.com>> wrote:
>
>         I dont see it, but I will argue it tomorrow. This is getting
>         like Emacs lisp programming :)
>
>         And I will need to get the Kernel log going here to print a few
>         things.
>         Or maybe just set a trap, aha, that might work.
>
>         Cheers,
>
>         j.
>
>
>         On Thu, Oct 8, 2015 at 9:59 PM, Peter Matthias
>         <PeterMatthias at web.de <mailto:PeterMatthias at web.de>> wrote:
>
>             Hello Jan,
>
>             your Match procedure needs the filename to end with 0X, 0X
>             (two times 0X). If the filesystem does that, it works. If
>             not, not.
>
>             Adding
>             n:=0;
>             WHILE name[n]#0 DO INC(n) END;
>             name[n+1]:=0X;
>             at the beginning of your Match procedure obviously fixes the
>             problem.
>
>             You can also call Match directly to see the bug:
>             mask:="*.Mod"
>             name:="ABCD.Mod"
>             name:="123";
>             IF Match(mask, name) THEN ...
>
>             Regards,
>                      Peter
>
>
>             Am 07.10.2015 um 17:51 schrieb Jan de Kruyf:
>
>                 Hallo Peter,
>
>                 Could you send me your test cases please.
>                 I would like to duplicate your findings and see where I
>                 went wrong.
>
>                 Cheers,
>
>                 j.
>
>
>                 On Tue, Oct 6, 2015 at 10:21 PM, Peter Matthias
>                 <PeterMatthias at web.de <mailto:PeterMatthias at web.de>
>                 <mailto:PeterMatthias at web.de
>                 <mailto:PeterMatthias at web.de>>> wrote:
>
>                      Am 23.09.2015 um 17:26 schrieb Peter Easthope:
>
>                          Hello,
>
>                          In OLR, has anyone found a way to store user
>                 data separately
>                          from OLR system data?  As a specific example,
>                 OLR is installed
>                          in /home/peter/olr on the HDD.  User data is in
>                 a SDHC card.
>                          The SDHC can be mounted at /home/peter/olr/SDHC.
>
>                          ls /home/peter/olr/SDHC/* shows the contents of
>                 the SDHC.
>                          System.Directory ./SDHC/* ~ shows nothing.
>
>                          Does anyone have a clever solution?
>
>
>                      Hi Peter,
>
>                      I updated OLR.FileDir.Mod . File is here:
>                 oberon.wdfiles.com/local--files/start/OLR.FileDir.Mod
>                 <http://oberon.wdfiles.com/local--files/start/OLR.FileDir.Mod>
>
>                 <http://oberon.wdfiles.com/local--files/start/OLR.FileDir.Mod>
>                      (and at http://oberon.wikidot.com/start in "Get
>                 OLR" section)
>                      download, store in olr directory and compile the
>                 module.
>
>                      I did not update to Jan's matching procedure
>                 because I also get
>                      wrong matches there.
>
>                      Regards,
>                               Peter
>
>                      --
>                 Oberon at lists.inf.ethz.ch
>                 <mailto:Oberon at lists.inf.ethz.ch>
>                 <mailto:Oberon at lists.inf.ethz.ch
>                 <mailto:Oberon at lists.inf.ethz.ch>> mailing
>                      list for ETH Oberon and related systems
>                 https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
>
>                 --
>                 Oberon at lists.inf.ethz.ch
>                 <mailto:Oberon at lists.inf.ethz.ch> mailing list for ETH
>                 Oberon and related systems
>                 https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>             --
>             Oberon at lists.inf.ethz.ch <mailto:Oberon at lists.inf.ethz.ch>
>             mailing list for ETH Oberon and related systems
>             https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
>
>
>
>
>
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>


More information about the Oberon mailing list