[Oberon] OLR and data storage.
Jan de Kruyf
jan.de.kruyf at gmail.com
Tue Oct 13 21:44:29 CEST 2015
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:~$
Peter, I agree with your statement. But I do get the right results.
But I get problems when compiling and testing.
It is Possible that my problems are caused by the trap I set, I do not
know.
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.
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"
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?
--------------------------------
Oberon.Call PC = 4860
Mod = 09607020H
P = ImportGraph.Compile PC = 5594
i = 12
j = 19
name = "Compile"
new = FALSE
par = 09606EC0H
res = 1
TextFrames.CallCmd PC = 11642
F = 0966DD20H
cmd = "ImportGraph.Compile"
new = FALSE
par = 09606EC0H
pos = 19238
res = 1
TextFrames.Call PC = 12531
F = 0966DD20H
S = 00000048H
h = 0
hint = ""
i = 0
new = FALSE
pos = 19219
TextFrames.Edit PC = 19635
F = 0966DD20H
Keys = {1}
M = 00000060H
R = 0000004CH
X = 69
Y = 629
beg = 0
buf = 00000000H
ch = 00000000X
end = 0
keysum = {1}
pos = 19219
text = 00000000H
time = 0
TextFrames.Handle PC = 20720
F = 0966DD20H
F1 = 00000000H
M = 00000030H
MenuViewers.Handle PC = 4365
M = 00000028H
Main = 0966DD20H
Menu = 095FA4E0H
V = 0966DDC0H
V1 = 00000000H
Oberon.Loop PC = 8557
M = 00000010H
N = 0000000CH
V = 0966DDC0H
X = 69
Y = 629
ch = 0000007FX
keys = {1}
oldshift = {}
shift = {}
System.Init PC = 18847
F = 09630A60H
S = 0000003CH
T = 096308C0H
Wt = 00000048H
f = 00000000H
ok = FALSE
------------------------------------------
At the same time I do not know what your memory map looks like, so I may
be up the wrong path here.
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.
cheers,
j.
On Tue, Oct 13, 2015 at 8:35 PM, Peter Matthias <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>> 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
>>
>> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151013/8990cb72/attachment.html>
More information about the Oberon
mailing list