Re: Recursively getting a list of all files executed using dofile

[marbux <marbux@...>]

On Sat, May 14, 2011 at 8:24 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> On Sat, May 14, 2011 at 5:10 PM, Benoit Germain <bnt.germain@gmail.com> wrote:
>> Since 'dofile' is a global identifier, any code that references it
>> should call yours instead.
>
> Yes, the good old monkey-patching trick. But I get the impression that
> 'do-node' is under your direct control.

Yes. More specifically, it is a program API whose notation is:

Nc_Script_Execute(int nScriptDocID, string strNoteID)

which executes the code embedded in the node specified by the parameters.

 So it is a classic problem of
> finding all the dependencies that a particular node depends on, and
> squishing these together.

Close. The squishing part isn't a merge. The program has two relevant
modes, Tree Mode (nodes arranged hierarchically, the format stored on
disk) and List Mode (arbitrary groups of nodes displayed temporarily
as a flat list view which can be manipulated as a group, e.g., sorted
or otherwise reordered, exported, copied to the clipboard, stored in a
variable, etc.).

The "squishing" part in this use case would be to list the relevant
nodes (make them the arbitrary group of nodes displayed in List Mode)
so that the listed modes can be exported as a document or be stored as
a variable, then inserted in a different document.

 For instance, if the nodes were all little
> files, then one could build a file which is a Lua table, where the
> keys are the UIDs and the values are the contents of the files, and so
> forth.
>
> What is your granularity of re-use? A single function exported per node?

The only bottom limit is a single line of executable code, although I
struggle unsuccessfully to imagine a practical use case for a chunk
that small.  :-) But this is basically up to the individual user
scripting the app, at least presently beyond our control.

I have thought through a solution in the meantime that shouldn't be
difficult for me to code. I'll sketch it here because I think it could
be translated into the dofile context so might be useful to others.

Just as each dofile code line includes the path of the file to be
executed, each of our do-node lines includes the note ID of the node
to be executed, e.g.:

	-- execute note: Get New UID
	Nc_Script_Execute(nScriptDocID, "6uk0wlac1RY89XjQ33KR5w")

So, in overly broad strokes:

-- clear the document's list display so that no nodes are listed for
that document.

-- list the target script's root node (root in the sense of the node
that begins the script's execution).

-- call a function that recursively processes the listed notes to find
each do-node call line in the listed notes, parsing it to extract the
line's note ID, listing each note thus identified and get the current
count of the nodes in the list.

   -- loop the function until the latest iteration produces a note
count equal to the last iteration's list node count.

Needs some fine-tuning to optimize, but those are the broad strokes.

In the dofile context, I think it would be somewhat different because
I can't imagine a Lua functional equivalent of our
Nc_App_List_GetCount() API, which returns the current count of listed
nodes.

But at the moment I think it feasible to write a script that, when fed
the path for the file that begins execution of the script, assigns its
path to strVar1 and to strVar2, in both cases with a trailing
delimiter.

Then a looping function that reads the contents of the next file
identified in strVar2 and deletes it from that variable, then searches
that file for occurrences of do file lines, parses any responsive
lines found to extract the relevant file paths, and appending each of
those paths to both strVar1 and strVar2 with a trailing delimiter,
then loops to the next file path in strVar2 and repeats the above
steps until strVar2 is an empty string.

At the end of the snippet, strVar1 stores a delimited list of file
paths for all files executed by the script and its various dependent
chunks.

Untested imaginings, of course.

Thank you for taking the time to think about my problem. I'd of course
appreciate in any thoughts you have on the approaches sketched above.

Best regards,

Paul

NoteCase Pro
The Massively Multi-Platform Outliner
<http://notecasepro.com/>