[Oberon] OLR and data storage.
Jan de Kruyf
jan.de.kruyf at gmail.com
Mon Oct 12 14:08:17 CEST 2015
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>
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>
> 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>
>> 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>> 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>
>>>> (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> 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/20151012/3e24bcf1/attachment.html>
More information about the Oberon
mailing list