[Oberon] OLR and data storage.
Jan de Kruyf
jan.de.kruyf at gmail.com
Sun Oct 4 21:49:10 CEST 2015
so that is what I did. Here is the modified module
Nomore matchprefix. New Match and 2 changed lines calling those modules in
Enumerate.
Does anybody feel the need for the '+' globbing char? I am willing to
implement it, but personally I do not remember when I used it last.
----------------------------------------------snip
(* ETH Oberon, Copyright 2001 ETH Zuerich Institut fuer Computersysteme,
ETH Zentrum, CH-8092 Zuerich.
Refer to the "General ETH Oberon System Source License" contract available
at: http://www.oberon.ethz.ch/ *)
MODULE FileDir; (* pjm *)
(* Linux FileDir module not based on OFS
2014-11-25 p.m.: MLO version, not tested
2014-11-28 made Enumerate work with qemu-mips
2015-04-13 added PathChar; made interface compatible to latest alpha
ToDo: test make interface compatible to latest alpha, add OFSenumerate
*)
IMPORT Kernel, Files, SYSTEM;
CONST
EnumSize*=0; EnumTime*=1; EnumRecursive*=2; EnumStop*=15; EnumUserMin*=16;
EnumUserMax*=31;
TYPE
EntryHandler* = PROCEDURE (name: ARRAY OF CHAR; time, date, size: LONGINT;
VAR flags: SET);
FileName* = Files.FileName;
DirEntP= POINTER TO RECORD
dino: LONGINT;
doff: LONGINT;
dreclen: INTEGER;
dname: FileName;
(* pad, type: CHAR; pad, type do it manually manually *)
END;
VAR
PathChar*: CHAR;
PROCEDURE Match(VAR mask, name: ARRAY OF CHAR): BOOLEAN;
VAR m,n, om, on: LONGINT;
f: BOOLEAN;
BEGIN
m := 0; n := 0; om := -1;
f := TRUE;
LOOP
IF (mask[m] = "*") THEN
om := m; INC(m);
WHILE (name[n] # 0X) & (name[n] # mask[m]) DO INC(n) END;
on := n
ELSIF (mask[m] = "?") THEN
INC(m); INC(n)
ELSE
IF (mask[m] # name[n]) THEN
IF (om = -1) THEN f := FALSE; EXIT
ELSE (* try the next position *)
m := om; n := on + 1;
IF (name[n] = 0X) THEN f := FALSE; EXIT END
END
ELSE INC(m); INC(n)
END
END;
IF (mask[m] = 0X) & ((name[n] = 0X) OR (om=-1)) THEN EXIT END
END;
RETURN f & (name[n] = 0X)
END Match;
(** Enumerate files matching the mask. proc is upcalled for every file.
Iff detail is TRUE, the time, date and size parameters will be valid.
Recursive calls to Enumerate are not allocated in proc. *)
PROCEDURE Enumerate*(mask: ARRAY OF CHAR; flags: SET; proc: EntryHandler);
VAR res, time, date, size: LONGINT;
diff, pos: LONGINT;
status: Kernel.Status;
i, j, num, min, dir, rbytes: LONGINT;
buf: ARRAY 128000 OF CHAR;
i1: ARRAY 10000 OF DirEntP;
de: DirEntP;
BEGIN
buf[0]:="."; buf[1]:= 0X;
dir:=Kernel.Open0(SYSTEM.ADR(buf), Kernel.RDonly, 0);
rbytes:= Kernel.GetDents0( dir, SYSTEM.ADR( buf), LEN( buf));
IF rbytes<=0 THEN rbytes:=-rbytes; Kernel.WriteString(" error "); END;
res:=Kernel.Close0( dir);
i:=0; num:=0;
de:=SYSTEM.VAL( DirEntP, SYSTEM.ADR( buf[ i]));
WHILE (i<rbytes) & (num<LEN(i1)) DO
IF Match (mask, de.dname) THEN
i1[ num]:= de;
INC( num);
END;
i:=i+de.dreclen;
de:=SYSTEM.VAL( DirEntP, SYSTEM.ADR( buf[ i]));
END;
IF num>=LEN(i1) THEN num:=0 END;
i1[ num]:=NIL;
(* using cripplesort, might be fast enough*)
i:=0;
WHILE i<num DO
min:=i;
j:=min+1;
WHILE j<num DO
IF (i1[ j].dname<i1[min].dname) THEN
min:=j;
END;
INC( j);
END;
de:=i1[ i];
i1[ i]:= i1[ min];
i1[ min]:= de;
INC( i);
END;
j:=0;
de:= i1[ 0];
WHILE de#NIL DO
IF flags#{} THEN
res:=Kernel.Stat0( SYSTEM.ADR(de.dname[0]), SYSTEM.ADR(status));
size:= status.size;
Kernel.U2OTime( status.mtime, date, time);
ELSE
time:=0; date:=0; size:= MIN( LONGINT);
END;
proc( de.dname, time, date, size, flags);
INC( j);
de:= i1[ j];
END;
END Enumerate;
BEGIN
PathChar := "/"
END FileDir.
(* Local Variables: *)
(* coding: mac-roman *)
(* tab-width: 2 *)
(* End: *)
--------------------------------------------------------snip
j.
On Wed, Sep 30, 2015 at 10:41 PM, Jan de Kruyf <jan.de.kruyf at gmail.com>
wrote:
> There is a "Match" in OFSFATFiles that looks a lot healthier.
>
> So the issue is 'PROCEDURE MatchPrefix'. what on earth is it there for?
>
> Also I have not proven to myself why Modules.Mod is shown
> and OLR.Modules.Mod is not shown.
> And on top of it I do not see that a leading * gobbles any amount of chars
> in the module as it stands, unless I am blind.
>
> j.
>
>
> On Wed, Sep 30, 2015 at 10:04 PM, Jan de Kruyf <jan.de.kruyf at gmail.com>
> wrote:
>
>> Hallo,
>> schoene Misthaufen!
>>
>> I am a bit confused by 'PROCEDURE MatchPrefix'
>> Do we need such a thing here?
>> NW has it in Project Oberon to limit the search to a sub-range.
>>
>> And what do I expect out of the Kernel? regular unix filenames, with
>> Oberon limitations?
>> (I could kprint the buffer of course)
>>
>> Other than that maybe start from fresh according to this plan:
>> ---------
>> ? matches any one character
>> + matches one or more characters
>> * matches zero or more characters
>> ----------
>> and no escape character or regex patterns.
>>
>> Plan:
>> Split the pattern into normal runs and glob characters and do some very
>> simple backtracking algorithm, or maybe not even that. come to think of it.
>>
>> Now on with my emacs lisp, making 2 emacs windows talk to each other via
>> the clipboard. Lots of fun.
>>
>> cheers,
>>
>> j.
>>
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Sep 30, 2015 at 7:38 PM, Peter Matthias <PeterMatthias at web.de>
>> wrote:
>>
>>> Hallo Jan,
>>>
>>>
>>> Am 27.09.2015 um 21:02 schrieb Jan de Kruyf:
>>> > Hallo Peter,
>>> >
>>> > > Also pattern matching algorithm has a bug. E.G. System.Directory
>>> *.Mod~
>>> > > does not show Modules.Mod. If someone has a clever implementation,
>>> > > please let me know. For the Linux kernel side I will implement it.
>>> >
>>> > You mean OLR.Modules.Mod ( and some others).
>>> >
>>> > I was having my sunday afternoon fun :)
>>> >
>>> > Is this bug to be found in (OLR.)Find.Mod ?
>>>
>>> This is in OLR.FileDir.Mod . Procedure Match should be the culprit.
>>> If you have questions about the Linux side, let me know.
>>>
>>> Regards,
>>> Peter
>>>
>>>
>>> > If so, tell me what the filename is supposed to be here:
>>> > --Domain*;(* {filename} ~ *)--
>>> >
>>> > Then I will have a look.
>>> > PROCEDURE BrowseFile(filename: ARRAY OF CHAR);
>>> > does not look like rocket science to me.
>>> >
>>> > Cheers,
>>> >
>>> > j.
>>> >
>>> >
>>> > On Fri, Sep 25, 2015 at 11:24 AM, 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 was out for holidays, so the answer a little bit later:
>>> >
>>> > System.Directory does not show the files in the ./SDHC directory.
>>> Only
>>> > flat files. However, you can open and store the files of that
>>> directory
>>> > using the filename with the directory. E.g. Edit.Open
>>> ./SDHC/Test.Text ~
>>> > as long as filename length is not exceeded. "." and "/" at the
>>> beginning
>>> > work, "~" at the beginning does not work as this is evaluated in
>>> the
>>> > shell and not in the kernel.
>>> >
>>> > Also pattern matching algorithm has a bug. E.G. System.Directory
>>> *.Mod~
>>> > does not show Modules.Mod. If someone has a clever implementation,
>>> > please let me know. For the Linux kernel side I will implement it.
>>> >
>>> > 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/20151004/be3e0f04/attachment.html>
More information about the Oberon
mailing list