Tinderbox Forum

Stamps: when invoked, do they go on the "pending tasks" stack and wait their turn?

I’ve noticed that with small (as in not many notes, rules, edicts, etc.) files, stamps process pretty much straight away, but with larger, more complex files there can be a bit of a lag. I’m assuming that being based on action code, they dutifully wait their turn until firing. Is this correct?

Thanks in advance!

Essentially. In outline, the stamped selections selection outline redraws an empty box when the stamp has finished acting on every selection in term.

1 Like

Yes, stamp actions go into the pending tasks queue.

My experience has been that it’s actually quite rare for this queue to be so full that there is typically any appreciable delay — even in larger documents. It’s certainly possible — Mark Anderson was chronically in this regime in his data analysis document during his doctoral research — but I know of only one or two other cases.

Additionally, stamps might not refresh the user interface as soon as they run, especially if they don’t see a need. That’s fairly common; to check, select another note or press the currently selected tab.

I’m finding that in some of my files it can take as long as 5~10 minutes to process a stamp. But, to be clear, this a bigish files with a lot of links and prototypes.

Five minutes? That’s nuts! (I doubt the number of links or prototypes is a factor). If you can share that somehow, I’d love to know what’s going on.

To clarify, my work was in a doc with 000s of notes and each was doing a complex query across the document. I deliberately used a stamp as I knew the process would take longer than usual to run, so this gave me a chance to control the running of code in small sections.

So I was never waiting minutes, albeit because I chose to only run selections of about 50 at a time which also allowed me to check and confirm things as I went. Had I simply put the code in an Edict or rule, i suspect I’d had had to have waited a full cycle to complete. The moral being, if you know you have a complex task to run it is worth considering using more manual control. Also in this scenario I was only ever running one large file in the app at the time, again to avoid different docs fighting for the same finite resource. I wouldn’t wish to confuse those making less heavy use of the app into thinking stamp code is any slower than the same code in rules. It is simply in rare cases the user’s choice of the complexity and breadth of use of the code pushes the app hard.

I can contribute little in the context of running several complex documents at once but common sense says that one doc or 4 together all have the same finite amount of resource to run.

If you are encountering delays, look to re-factor your code. Do you need code in rules that could be in edicts. Do you need so many agents and all running at normal speed? And so on. It’s nice to feel the app should respond to any amount of work, but there have been very few cases in my files, or helping with others’ files that some revision of code won’t resolve.

1 Like