In the attached TBX document, there are two agents, each updating the text of a different respective notes, adding a timestamp line to each note on each agent update cycle.
I have two questions about this:
One of the agents has $AgentPriority set to highest (0), and the other has $AgentPriority set to lowest (10). But as you can see, the agents are adding lines to their respective notes at the same rate. It seems to me that the high-priority agent should be adding lines at a much faster rate than the low-priority agent.
The agents are printing the current time with a call to `date(today).format(âh:mm:sâ). Does anyone know why the number of seconds printed is always zero?
You donât see a difference as youâre using a minimal test set. Download the aTbRef source TBX and looks at the number of agents therein (c.100 IIRC) and re-run your experiment. The latter scenario is the sort of thing agent priority is designed to address, as well as a scenario where there are a lot of agents that query other agents and so thereâs a lot of agent activity.
The agent priority allows you to dial the frequency of re-querying up or down - see here. What I should add to the latter article is than unless an agent is âoffâ an agent is always on first creation of the agent and whenever you commit an edit to the query. IOW, when you edit the query in Get Info or the Action Inspector - the query runs when you press Return. Indeed in a very complex doc, e.g. not a new starterâs simple 50 note doc, it can be useful to disable a priority when working on a query. That avoids running an incomplete/wrong-syntax query by mistake.
I do stress for later readers that what Iâm describing in the paragraph above is more expert-user issue. Agents arenât hard to use and in small docs they run essentially instantaneously.
Iâll address the time issue in a separate reply as this is long enough already.
Edit: sidenote - you can think of Edicts as low-priority Rules.
It is true that Tinderbox uses a date-time format for Date-type data. Tech folk will be familiar with the concept of a date-time in milliseconds based off a reference time. Of course the latter is stored under the hood - or computed internally with the app showing date and time in more human-friendly form.
Over itâs 17-odd year life Tinderbox has varied in its acknowledgement of a second-level time granularity. Some operators seem to use it, others donât and elide the seconds giving a return like the one you note. although Iâve seen the odd mention of second-scope issues I think as a result itâs lightly tested as thereâs no real use case - as yet. There are actions like seconds() for which Iâm probably to blame - they were added in a completist way rather than because anyone asked deliberately for such an operator.
Are you asking about this and agent priorities simply by way of explanation or is there a real-world problem youâre trying to test?
The seconds question is mostly curiosity. I often find myself grinding up against Tinderboxâs rough edges, like this one, and I want to know if itâs a limit in Tinderbox or in my understanding.
Iâm very glad that Tinderbox supports finer-than-minute granularity generally, since I use timestamps, obtained from $Created, as UUIDs in some of my Tinderbox documents, and I often create more than one note per minute. (Given that Tinderbox does support fine time granularity, it strikes me as strange that today would be rounded to the minute, since this seems like it would require more work rather than less, but anywayâŚ)
The agent-priority question does have a real-world problem behind it: I often find that for debugging itâs useful to have an action that only runs manually. This is especially true for multi-stage agent cascades, where one agent narrows the query results of another. I typically hack it by turning an agent on and off, using boolean guards, or use an edict for this. I was kind of hoping for low-priority agents to act like edicts, with update cycles so infrequent that for debugging purposes you can consider them to be manually run, so I was surprised to see the low-priority agent updating regularly.
Would you see any use for an agent priority level that means âmanual-update onlyâ? This strikes me as useful.
The way I do that is via a Stamp. It essentially is a manual-update-only agent. Ie:
You create and name a Stamp via the Cmd-1 inspector process. You have the action for the stamp be whatever the agentâs action would be;
Once youâve saved it, you can call it up just with two or three keystrokes â Cmd-1, and then clicking on the relevant stamp from the menu;
The main difference is that stamps apply to selected notes onlyâwhich can be an advantage, in letting you limit or precisely specify the scope of what you want it to work on, or a minor disadvantage, in requiring you to do a Cmd-A âselect allâ step before running the stamp.
Main point is: thereâs already the functional equivalent of a manual-update-only agent, just by a different name. At least that is my amateur understanding of the way stamps work â and the way I use them.
One bit of missing functionality here is if you use agents just to group things or provide views on the data. Then youâre only relying on the query, not the action, which stamps canât replicate.
Edit: Actually, stamps can replicated them, by storing the results of a find query in a list, as @mwra points out below.
I think others have covered this pretty well. I endorse both suggestions. Besides colour, I also sometimes use flag badges (sadly thereâs no green flag so I use blue instead). Itâs a matter of personal taste, but sometimes I find badges can be less visually intrusive.
Often overlooked is that (except in map view) the agent icon shows the on off state. When off, the thick bar at the bottom of the icon is hollow; for all âonâ priorities is it filled (i.e. the normal rendering).
There is no run-once agent. You can disable automatic agent updates (File menu)which essentially sets all agents to zero priority. The file menu option to update agents works whether auto updates are one and off, but is generally meant for the off state, it then runs every agent (that is not locally set to off) once. In the this manual mode, if using cascades of agents that look at other agents you may thus need to run the once-only command several times for the cascade to fully update. IOW is agent A looks at agent B which looks at agent C, then you would need to use âupdate nowâ 3 times in order for C to reflect changes in A.
Otherwise there is no run-once agent state. As pointed out a Stamp acts like an once-only agent action - or rule - but the user must set the selection; i.e. there is not query.
However, you could make a stamp that uses a find(query) to populate a List-type attribute, use List.each() to apply an action and then reset the list to normal (i.e. no value).
Yes, for the debugging use case, turning off Update Agents Automatically gives me the behavior Iâm looking for. Between that and the other suggestions, I think I have by bases covered.
