Controlling scope of an agent with descendedFrom?

Q & A - getting started with Tinderbox
1

Hi,

I’ve come back to an older document and it appears to be having difficulty with an agent search. I think this used to work, but its been a year since I picked it up so I could well be wrong…

I’ve an agent whose scope I want to restrict to other descendants of its parent that have a specific $type (a custom attribute).

My agent search is:

descendedFrom(parent(agent))&$type.contains(“question”)

This isn’t picking up anything, and it should.

Am I missing something obvious?

Regards,

Jim

2

I got this to work. Have you terminated the question with a “;”?

3

Thanks for having a look–but I’m afraid that I have finished with a ‘;’.

You prompted me to try again in a new document, but I’m afraid no joy. I’m on 9.5.2 and wasn’t last time I used this.

It’s sounding like one to send to tech support.

Cheers,

Jim

4

I copied your search criteria into a new agent. This time there was no respons from the agent (just to make clear I have no actions defined for the agent, just the search string).
But, just clicking in the action area of agent popover, the search completed and the expected result was obtained.

5

I’m assuming the curly quotes is the forum software and not you, but if not, the .contains() argument must be in straight double quotes. Further we’re assuming in $type is a String type and not a List or Set. Note too that attribute names are case sensitive (and that general Tinderbox style is to name attributes with Caps or InterCaps. FWIW, I notice ‘type’ colours in the code box as if it is an action code operator so calling an attribute might be a poor choice. Using $Type seems safer than $type in that it avoids a possible parsing error.

Is ‘its parent’ the parent of the note being matched or the parent of the alias? The code sample suggests the latter but the text can be read either way.

When I use parent(agent) I get a fail and I’d guess it is because agent may not evaluate as a nested designator. Anyway, It is quite easy to solve. I made a stamp:

$MyString = $Path(parent);

and stamped the agent. I then made the query:

descendedFrom($MyString(agent)) & $Type.contains("question")

(N.B. revised attribute name). All now works. Here’s my test file: Query-problem.tbx (131.5 KB)

6

The Problem:

The agent finds nothing. It should find lots of notes.

What To Do First:

Exclude simple typographic errors — bad quotes, mismatched parentheses.

Step Two:

Try separate agents with each of the two clauses of the query.

  • descendedFrom(parent(agent))
  • $type.contains(“question”)

This should tell you where the problem arises. Divide and conquer: you can now focus on the part of the expression that’s causing trouble.

Step 3:

Ask the forum. Ideally, upload a small file that demonstrates the problem. That’s bound to solve it!

Ask Me

New in the roadmap: Issue 3991. “descendedFrom(parent(agent)) is reported to fail. Why?”

I can’t imagine why parent(agent) would cause trouble, but now I know precisely where to look.

7

Thanks Mark,

I missed the wrinkle with step 3, of describing the results of the divide and conquer. The search on type works just fine! I can post a demonstration file if that’s helpful, but I think we’re on the same page.

And Mark, your MyString workaround works perfectly for me. Thanks!

Cheers,

Jim

Oh, and I’m reasonable sure this used to work–this is a 10+ year old file that I pick up once or twice a year (last edit was ca. May 2022) so it may have been working in an older version.

8

Follow up question.
Is there an automatic correction when typing a query in the agent pop-over? I can have Tinderbox set to smart quotes and writing in the query field results in normal quotes.
If I write in $Text the smart quotes are there, as expected.

9

Glad the agent’s working again.

You’re very likely right, but things do change: not everything can keep working as it did, not that your code example looks dated! Action/query code has evolved a lot in the last ten years. Because the possible (parsing) outcomes were much fewer in the past, the syntax could be quite permissive in how the user indicated intent. With newer features there is a need to be a bit clearer. Very early code allowed:

Color = blue

whereas, though that might work now, the recommended style is:

$Color = "blue";

I don’t think $Type vs. $type was necessarily part of the problem. But, I’m a pragmatist and if $type was colour-hinted as action code and $Type as recognised attribute, I’d always go with the latter. Not making the parser ‘guess’ more than it has to is enlightened self interest.

I’d add one thing to @eastgate’s rubric above (which described what I’d done to make my earlier answer, and that is consider a test doc. Unless you’re already using a new/small TBX, step back and make a small test doc in which you follow the steps described. Trying to chase a code edge-case in a doc that already contains years of notes with all sorts of customisations and connections only adds to the challenge. Importantly, if the query/action work in the test doc and not in your mature doc, then you’ve further complicating factors you’ve not factored into the test. Note: don’t bulk copy from your big doc to the test, the whole idea is to flush the problem using mimal data/customisation.

Other reasons for getting in the habit of making a small test doc:

  • Over time you’ll find that the mere act of thinking through what’s needed for the test may well indicate the problem without you needing to complete the task.
  • Once the problem is resolved/fixed you can copy any new code you need but otherwise just delete the test doc to avoid cruft building up. If you’re tempted to keep the test doc for re-use, you’re missing the point if making a new doc for testing (don’t import unknowns); you likely aren’t saving future self any time.
1 Like