How to manage an unstable Tbx document

I have a document which I started in 2008 and has grown over the years. It’s a list of all the books I’ve read and short notes on them, together with my wishlist of books to read in the future, along with some notes to analyse all this.

It has become increasingly unstable/unpredictable, and in particular:

  1. it crashes Tbx regularly – it’s rare for me to get through a session without a crash
  2. the UX for the Key Attributes is broken – if you complete one KA, or try to move between KAs, the focus jumps instead into the Text pane.
  3. Sorting in agents Outline views sometimes stops working (and you can’t “force” it to sort by redrawing the outline etc.)

I don’t think it’s a particularly large Tbx document – 1176 notes, 66k words, 47 agents, 5529 rules, 20 user attributes – or is this pushing the envelope?

Any clues on how I might go about cleaning this up so it becomes usable again? I suppose there’s likely to be old action code that is now deprecated but I wouldn’t know where to start looking for this.

Any thoughts would be appreciated!

Crashes? Definitely send the logs into Eastgate as they may give some clue as to the cause of the crash. Given its age, I suspect the TBX has accumulated some cruft in terms of action code that used to work (laxer syntax) and perhaps now doesn’t. The document doesn’t seem egregiously large.

Nothing leaps off the page. Point #2 is definitely odd.

One thing to try is to turn off all agents and disable rules (if possible) and review (try to remember ) what any code there does. Check the syntax is up to date. It might not fix any/all problems but it definitely helps protect agains new ones.

Your best first step is probably mailing in the crash logs and seeing if any cause comes back to help you zero in on the cause.

What version of Tinderbox are you using?

5,529 rules for 1,176 notes – that’s almost 5 rules per note. Got to be huge amount of processing going on.

In addition to sending the crash logs to @eastgate, I’d suggest taking a sample of Tinderbox using the Activity Monitor app, and sending that report to @eastgate as well.

FWIW, if using prototypes, notes using the prototype inherit the rule so count as a rule although all use the same code. The rules count, even if disabled.

For old docs, especially those that pre-date Edicts, consider if your rules need to be rules, i.e. always running, or might better be an edict. I find in my large docs, I use edicts more that rules.

Paul & Mark, many thanks. I thought going through Support was probably going to be necessary but thought I’d just ask here first in case anyone had seen anything similar. The weird UX effects in KAs in particular seemed worth flagging.

I’ll be in touch with Support once I”m back on my Mac

1 Like

Crashers, especially, are worth a trip striaght to suppot (and like as not gets a faster/better answer) as being fellow users we can’t see inside the app. so we may confirm a crash but can’t necessarily diagnose it further. Good luck. :grinning: