The Directory Walker revisited

wouter wouter.abraham at pi.be
Thu Sep 4 03:10:00 EDT 2003


On donderdag, sep 4, 2003, at 00:55 Europe/Brussels, 
use-revolution-request at lists.runrev.com wrote:

> Message: 2
> Date: Wed, 3 Sep 2003 16:19:16 -0600
> Subject: Re: The Directory Walker revisited
> From: Dar Scott <dsc at swcp.com>
> To: use-revolution at lists.runrev.com
> Reply-To: use-revolution at lists.runrev.com
>
>
> On Wednesday, September 3, 2003, at 03:52 PM, wouter wrote:
>
>>>   repeat with x =  2 to the number of lines of tDirList
>>>     directoryWalk (whatFolder & "/" & (line x of tDirList))
>>>   end repeat
> ...
>> I am very sorry to inform you that this one you adapted from David
>> Vaughn, is also bumping into the recursionLimit.
>
> Very strange.  I assume you don't have folders nested 700 deep.  Maybe
> something in the script increases the stack frame size.

:^)) You keep persitent on the deepness of the directory.
I used my root Library folder on a Mac OS X volume to run tests
  and the deepest folder is 18 levels deep.
The recursiveLimit has only to do by how many times the handler
calls itself from within itself without ending itself (nested calls) 
before
its starts running itself again  (kind of an egocentric handler)
That's why if you do the "send ...  to me in <xx> time" it will allow 
the handler
to go to the "end directoryWalk" before starting itself again.
Comment out the "in <xx> time" and you will bump into the 
recursionLimit.
Btw I pushed the experiment a little further and can run it safely with
the "send to me time" set to 0.0001 millisecs.
May be tweaking this for each platform is necessary.
And not blocking the rest of the application is a real benefit.


>> So as everybody is really liking recursive handlers I cooked something
>> up which you could call a recursive handler (as it is calling itself).
>> And which will NOT run into the recursionLimit by allowing it to end
>> itself before starting a new instance of itself.
>
> Cool!
>
> Dar Scott

Good Morning,
WA




More information about the use-livecode mailing list