question on progress reporting during long lfs.dir

Solar2D General Questions/Discussion
#1

Hi,

I’m currently searching my Android’s directory (starting at root, /) via lfs.dir().

It works (with some caveats to avoid loops in special system directories), but …

it takes quite some time (10 to 30 seconds?).

I can’t report progress during the search (because I’m never “exiting” back to the Corona SDK main loop).

Is the only way to report progress during things like this something like:

   Make my recursive directory walker un-recursive, so that

   whenever I would have wanted to recurse, I instead save the current lfs.dir object in a stack.

   (and when I hit the end of the current object, I “pop” the stack and resume with the prior 

   directory object).

   For any given directory object, I’d iterate through it (presumably doing something

   interesting), and every 1/3 second (or so), I’d update my progress indicator,

   and then schedule a resume of the walk of the 

   current directory object for a millisecond or two from now,

   and then “exit”.  That “exit” gives the Corona main loop a chance to run, updating the display.

?

I had thought “hey, maybe native.new<mumble> calls might actually change the screen immediately”,

but, no, they don’t.

I had also looked around for any ability to do direct (raw) screen access, but couldn’t find anything like that

(that would have let me do a recursive task, and update the screen myself :slight_smile:

thanks,

Stan

#2

Your options are as you’ve described, though how you implement them gives you a few choices.

You can cooperatively iterate, by return from the iterator function, which then gets called again at a later time, say on enterFrame or timer, and reports its results via a status table.

You can somewhat forcibly iterate, using coroutines, where your iteration function still updates a status table, but rather than exiting it yields control back to the main program which will resume it at a later time, also likely on enterFrame or timer:

http://lua-users.org/wiki/CoroutinesTutorial

With both options you can simply record the system time on entry and exit after x milliseconds - or just process a limited number of results before returning/yielding.

#3

@horacebury … I did a brief experimentation with coroutines, but kept getting hit by “attempt to yield across metamethod/C-call boundary”

errors.  IIRC, it was any time I tried to coroutine.yield after I’d called lfs.dir().  (The coroutine.create / resume worked, and the

first yield (just before the call to lfs.dir) worked ok.)  That’s when I decided to do the stack-based replacement for recursion :slight_smile:

But, I may do more experimentation in that area.

thanks,

Stan

#4

Your options are as you’ve described, though how you implement them gives you a few choices.

You can cooperatively iterate, by return from the iterator function, which then gets called again at a later time, say on enterFrame or timer, and reports its results via a status table.

You can somewhat forcibly iterate, using coroutines, where your iteration function still updates a status table, but rather than exiting it yields control back to the main program which will resume it at a later time, also likely on enterFrame or timer:

http://lua-users.org/wiki/CoroutinesTutorial

With both options you can simply record the system time on entry and exit after x milliseconds - or just process a limited number of results before returning/yielding.

#5

@horacebury … I did a brief experimentation with coroutines, but kept getting hit by “attempt to yield across metamethod/C-call boundary”

errors.  IIRC, it was any time I tried to coroutine.yield after I’d called lfs.dir().  (The coroutine.create / resume worked, and the

first yield (just before the call to lfs.dir) worked ok.)  That’s when I decided to do the stack-based replacement for recursion :slight_smile:

But, I may do more experimentation in that area.

thanks,

Stan