[Oberon] OLR and data storage.
Peter Matthias
PeterMatthias at web.de
Sat Oct 17 10:37:42 CEST 2015
Am 13.10.2015 um 21:44 schrieb Jan de Kruyf:
> Hallo,
>
> Stock Debian on a stock Dell E6430.
>
> jan at janDell:~$ uname -a
> Linux janDell 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt11-1 (2015-05-24)
> x86_64 GNU/Linux
> jan at janDell:~$
I meant the oberon system. But that question is answered below.
> Peter, I agree with your statement. But I do get the right results.
> But I get problems when compiling and testing.
To be clear: You get the right result with the code snipped I sent and
repeat below?
mask:="*.Mod"
name:="ABCD.Mod"
name:="123";
IF Match(mask, name) THEN ...
> It is Possible that my problems are caused by the trap I set, I do not
> know.
I can't remember that traps on X86 caused problems somewhen.
> It manifests itself by corrupting the display windows. Or likely the
> underlying Texts since also the
> Oberon 'middleclick for command' does not function right anymore after
> the corruption.
I trust the output of the Trap (besides the number, I fixed it, but trap
numbering still needs some cleanup).
> Here is the trap Procedure:
> --------------------------------------------
> (* Trap generator
> *)
> PROCEDURE Trap ();
> VAR
> m : INTEGER;
> BEGIN
> m := 0;
> m := 3 DIV m;
> END Trap;
> -----------------------------------
>
> And here is the resulting trap after I call the trap routine somewhere:
>
> --------------------------------
> TRAP 0 HALT statement (Linux X86 2015-07-18)
> ImportGraph.Trap PC = 244
> m = 0
> ImportGraph.ExtractSub PC = 2472
> ds = 00000000H
> dst = 00000000H
> i = -1
> j = 10
> k = 0
> len = 15
> m = 0
> modf = ".Mod"
> name = "ImportGraph.Mod"
> subs = ""
> ts = ""
> ImportGraph.Compile PC = 5826
> S = 00000024H
> T = 00000000H
> beg = 0
> dotfile = 00000000H
> dottext = 00000000H
> end = 0
> m = 00000000H
> name = "ImportGraph.Mod"
> reduced = TRUE
> time = 0
> tmp = 00000000H
> v = 00000000H
> Oberon.Call PC = 4860
> -----------------------------------------------
>
> note these lines:
>
> ImportGraph.Compile PC = 5826
> S = 00000024H
> T = 00000000H
>
> I know for sure that S and T are valid pointers: they are the Texts.Text
> and the Texts.Scanner used for
> scanning the command line. And that works I do get the name of the file
> to compile into a graph
> "ImportGraph.Mod"
S and T seem to be not opened, closed or overwritten. The later seem to
be unlikely to me.
> But in the section with the Oberon.Call procedure the pointers display
> more or less normally.
> Could you maybe put this trap routine somewhere in a test program and
> see what values you get for the pointers,
> If they are valid values or not?
...
> ------------------------------------------
> At the same time I do not know what your memory map looks like, so I
> may be up the wrong path here.
Don't know exactly what you mean. There is a stack and a heap.
> But it is true that software that does run here does not run on your
> machine and that I do get strange corruption of my text buffer.
I suppose the best way would be to send me the source to reproduce the
text corruption fault. You also can use ARM and MIPS targets via qemu to
check the behaviour.
Regards,
Peter
> On Tue, Oct 13, 2015 at 8:35 PM, Peter Matthias <PeterMatthias at web.de
> <mailto:PeterMatthias at web.de>> wrote:
>
> 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>
> <mailto: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>
> <mailto: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>
> <mailto: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>>
> <mailto: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>
>
>
> <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>>
> <mailto: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>
> <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>
> <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