The Directory Walker revisited

Wouter wouter.abraham at pi.be
Fri Sep 5 14:21:01 EDT 2003


Hi,

As I already unintentionally treaded some toes in this thread, please 
put on the metal tipped safety shoes for the following, because now I 
am puzzled...

On Friday, Sep 5, 2003, at 08:48 Europe/Brussels, 
use-revolution-request at lists.runrev.com wrote:

> Message: 9
> Date: Thu, 4 Sep 2003 23:15:53 -0700
> Subject: Re: The Directory Walker revisited
> From: Geoff Canyon <gcanyon at inspiredlogic.com>
> To: use-revolution at lists.runrev.com
> Reply-To: use-revolution at lists.runrev.com
>
> On Tuesday, September 2, 2003, at 01:59  AM, wouter wrote:
>
>> That is true but the amount of recursion is not  equal to the depth of
>> the directories.
>> It is equal to the total amount of directories. And this number can
>> easily surpass 1000.
>
> Again, sorry for the delayed response, but I just realized that the
> recursive code behind this conversation is mine, and I feel the need to
> defend my code ;-)
Please do :-)
>
> The above isn't correct;

Following are the puzzling lines:

> the recursion involved only reaches the depth
> of the directory structure. So if your folders are nested twenty deep,
> the greatest recursion depth will be twenty as well. It doesn't matter
> how "wide" the directory structure is, just how deep.

I hope this is your code (anyway the recursive ones kind of all boil 
down to this):

on directoryWalk whatFolder
   set the defaultFolder to whatFolder
   put the files into temp
   repeat for each line x in temp
     put whatFolder & "/" & x & return after gHierList
   end repeat
#### here it gets a list of directories in the whatFolder directory
  put the folders into tDirList
#### and here it starts recursing for each line in the tDirlist
#### and does the same for each recursion
   repeat with x =  2 to the number of lines of tDirList
     directoryWalk (whatFolder & "/" & (line x of tDirList))
   end repeat
end directoryWalk

So can you enlighten me on the following;

> So if your folders are nested twenty deep, the greatest recursion 
> depth will be twenty as well.

I can see that the "depth" attained will be equal to twenty in this 
case.

> It doesn't matter how "wide" the directory structure is, just how deep.

But as far as I can see the total amount of recursions to attain this 
depth will be far greater than 20, because it recurses on every folder 
it encounters on its quest to the deepsest level. To me this means that 
wideness in this handler does matter.
May be the problem is only in the terminology.

.
.

snip

> The problem here isn't with recursion. The setting/getting of
> directories, or maybe the overall data size, is involved as well.

It seems kind of a weird to me to take the problem off the recursion as 
it is exactly the use of recursive handlers that bumps into this 
problem.
That  "The setting/getting of directories, or maybe the overall data 
size, is involved as well" would be a limiting factor is not certain, 
because of  2 different tests that showed me the contrary.
The first test was running the directoryWalker with a counter. The 
other test was only recursing with a counter and nothing else. The only 
data moved around here was the counter itself. The recursive 
directoryWalker bumped into the recursionLimit at count 1355 and the 
simple pure recursing one at count 578 (and I repeated this tests 
several times with the same outcome. But I realize that mileage 
can/will differ on other computers/platforms as your tests showed a 
different result) On my computer this tests indicated that the 
manipulation of more data and directory settings/gettings actually 
augmented the count.

>  I ran a test without using actual directories, instead just 
> generating fake
> ones. I've run tests that went as deep as 131 levels of recursion, 8308
> directory and file entries, and an output of 1,243,170 bytes, without a
> problem.
>
> In a pure recursive method I went to a depth of 600 without problem.

I only wanted to point out that recursive handlers can bump into the 
recursionLimit (and they do in certain cases) and thereby are not fit 
for certain jobs. But the entanglement with the folders/directories 
handlers complicated the problem proposed (and for sure also the fact 
that I am not a professional programmer and as such mostly don't wield 
the correct terminology. And  I am not the only one (comforting 
thought))

> regards,
>
> Geoff Canyon
> gcanyon at inspiredlogic.com

Hoping not to have mashed toes, greetings and thanx to all that 
participated in this thread,
Yours puzzling,
WA




More information about the use-livecode mailing list