[Oberon] bug in FileDir.Match

[Jan de Kruyf]

Here is the final version (I hope) of the Match routine.
I ran some rough timing tests. Joergs version was a bit (7%) slow. Also the
compiled size was slightly up.
Between Peters version and my new version it is difficult to measure the
difference without a bare-metal system.
(and probably one needs to switch off the gc)

I made a similar Oberon-7 version and used the same style of programming in
the Oberon-2 version, just to get my head around the Dijkstra WHILE in O-7.

It took a bit of head-bending: I now had to decide "what needs doing" in
the loop, in stead of "when to get out". But the result is a cleaner
program, also the O-2 version benefited.

Here is the test module and a patched FileDir module.

Once it is approved, also FATFiles and AOS Strings need to be updated. Does
anyone know who does the maintenance for those?

Joerg: thanks for your test patterns :)  It was most appreciated.
I have added two, since believe it or not, I managed to write a program
that passed all your tests, but not one of those 2.

cheers,

j.





On Sat, Oct 31, 2015 at 9:38 AM, Jan de Kruyf <jan.de.kruyf at gmail.com>
wrote:

> Peter please do not.
>
> Joerg pointed out that it is not complete: It does not do backtracking.
>
> Otherwise: I did the tests, Joerg designed, on your invention and it
> passed all except one where there is a * in the filename.
> This is obviously of no importance in Oberon.
>
> There are 2 designs on the table at the moment. Of which mine is not
> complete yet. Joerg has a complete design that works, but it is a bit
> difficult to follow the program flow. And I still want to do one more test
> on it.
> So I will finish this work first before I commit myself.
>
> cheers,
>
> j.
>
>
>
> On Fri, Oct 30, 2015 at 11:03 PM, Peter Matthias <PeterMatthias at web.de>
> wrote:
>
>> Hi Jan,
>>
>> all tests I did passed. So I will use it for next version.
>>
>> Thanks.
>>         Peter
>>
>>
>> Am 29.10.2015 um 10:22 schrieb Jan de Kruyf:
>>
>>> Good morning all,
>>>
>>> I finally found the time to sort out the misbehaving Match routine:
>>>
>>>  > 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 ...
>>>
>>> You were quite right Peter, I did not. And when I did I saw.
>>>
>>> So now I fixed it, mainly since the same broken routine is used in
>>> FATFiles.Mod and in AOS Strings.Match. So once everybody approves, the
>>> fix should go there also.
>>>
>>> I have attached a test module for the match procedure as such, with
>>> Peters test hard coded.
>>> And I have attached a modified FileDir.Mod that you can compile and test
>>> in your own system.
>>>
>>> Please let me know.
>>>
>>> Then I will now pay attention to the trap problems I saw, or thought I
>>> saw.
>>>
>>> Cheers,
>>>
>>> j.
>>>
>>>
>>>
>>> --
>>> 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/20151102/ef8de71e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OLR.JP.FileDir.Mod
Type: audio/x-mod
Size: 5288 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151102/ef8de71e/attachment.mod>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JansMatchTest.Mod
Type: audio/x-mod
Size: 3802 bytes
Desc: not available
URL: <http://lists.inf.ethz.ch/pipermail/oberon/attachments/20151102/ef8de71e/attachment-0001.mod>