In projects that have lots of text, these agents have a difficult task: each clause might need to search all the text in the document, and each clause needs to build a regular expression matcher. The tagger is more restricted—it searches only for entire words, not for regular expressions—but it is significantly faster and it runs only when the text of the notes changes. In the example above, we could replace the query with the simpler query
query : $NLTags.contains(“Rome”)
and add a single line to the $Text of the /Hints/Taggers/NLTags note:
Now, the agent needs only to examine set $NLTags, which requires far less work than searching all the text of a large document.
So, this implies the tagger runs if/when $Text changes. But, behind the scenes there may be lots of other tasks to do (queries, rules, autofetch, watched folders, etc. Your report of timing would suggest the $Text change adds the note to a queue for the tagger process to action but the that task may have to wait for other processes to run. @eastgate is that a fair analogy?
Thanks. This is also a reason why I created a bare-bones document to test the feature with only one note and the built-in Hints folder.
The fact it took so long to update indicates either extreme low priority e.g. similar to the new lowest setting of the Agents, another queuing process or a trigger I don’t understand (if it is different from changes to $Name or $Text).
Unfortunately, such internal scheduling is hidden for users and not described in release notes, so this may not be the best place to get the answer.
I’d agree thought, that it is useful to have some idea as to why a feature might be running more slowly than expected. As your test doc is small and presumably doesn’t have sensitive content, you could upload it here so others can try to replicate your findings.
Thanks @eastgate - better too conservative rather than running rampant and causing TB documents grinding to a halt.
As an idea why not give users the control on the update frequency in a similar fashion Agent priority which users can set depending on their need e.g. an attribute along the lines of $TaggerPriority ? My experience is that in an editing session of multiple notes in my office (connected to power supply) I would be keen to see quicker updates of certain tags especially when using columns or testing new tags. In other cases I’m more relaxed and happy to let my document flow it’s tagging course.
The original notion for taggers is that they’re slowly mining data and marking down relevant things they discover. I envision them like good research assistants; they may not get things done right away, but eventually they’ll get answers that are interesting and usually useful.
Unfortunately I missed the Zoom session, and the links in the help file for 9.0.0 Highlights aren’t working for me. Would it be possible to have a link to either? These new features look powerful and I’d love to get going with them. Many thanks, Mark @eastgate, for your fine work, (and Mark @mwra, in advance for your Reference File :-))
I’m busy working to get aTbRef9 up, hopefully today. I think there is a glitch in the TB9 Help file as some of the links in the v9 Release Notes pages don’t complete (I’ve reported this).
Doesn’t give any actionable info. What did you do? What did you expect? What did you get?
If not in a rush, give me a few hours to finish aTbRef9 (it’s always far more work than I envisage!) and get it up.