[Oberon] OLR and data storage.

[Jan de Kruyf]

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/20151010/a70c7ed6/attachment.html>