Jean-Pierre MartineauandClaude Opus 5
bdc16fc448
Three things were true of the log at once: it was JSON Lines, it never rotated, and it almost never recorded a failure. Of the last twenty thousand records in a real one, nine were warnings and three were errors. It faithfully kept the boring parts and missed the interesting ones, which is exactly backwards for the only job it has. It is plain text now, `~/.meshterm/meshterm.log`, one line per record with the traceback indented under the line that raised it. JSON Lines was there in case something replayed it; nothing ever did, and the actual reader is a person who has hit a problem and is about to paste the last twenty lines into an issue. That reader has a text editor. It rotates, at 2MB across three files. The old handler grew without limit and a real one reached 11MB over ten weeks — a lot of disk on a handheld, and an unreasonable thing to ask someone to attach. How much it keeps is a preference, `log_level` under a new Diagnostics group, defaulting to WARNING. That is what makes the file useful rather than large: it holds the problems, and turning it up to DEBUG for one run is how you chase something. Loaded before logging is configured, since it decides how logging is configured, and handed to the context afterwards so the file is not read twice. And failures are written down at last. Every unhandled error reaches the log with its traceback and the terminal says where to find it; expected errors — an ambiguous device, a bad preference — go in as warnings, because a log that only holds crashes cannot answer "what happened just before". The bug form now asks for the file, which it had no reason to before. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
184 lines
5.4 KiB
YAML
184 lines
5.4 KiB
YAML
name: Bug report
|
|
description: Report a problem with MeshTerm
|
|
labels: [bug]
|
|
body:
|
|
- type: markdown
|
|
attributes:
|
|
value: |
|
|
Hopefully you never need this form.
|
|
|
|
If you do: how much of this you fill in really does decide what happens next. A
|
|
report I can act on gets worked on. A vague one usually doesn't, because I can't
|
|
do anything with it. If it isn't worth describing properly, it's probably not
|
|
worth fixing.
|
|
|
|
Most of these take ten seconds each.
|
|
|
|
- type: textarea
|
|
id: problem
|
|
attributes:
|
|
label: What's the problem
|
|
description: What happens, and what you expected to happen instead.
|
|
validations:
|
|
required: true
|
|
|
|
- type: dropdown
|
|
id: how-often
|
|
attributes:
|
|
label: How often does it happen
|
|
options:
|
|
- Every single time
|
|
- Often, but not always
|
|
- Now and then, no pattern I can see
|
|
- Once, and I haven't seen it since
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: repro
|
|
attributes:
|
|
label: How do I make it happen
|
|
description: >
|
|
The steps, in order, starting from launching MeshTerm. Screens and keys beat
|
|
descriptions — "Contacts, Enter on a node, Routes tab, Enter on the second route"
|
|
is worth more than "open a trace".
|
|
placeholder: |
|
|
1.
|
|
2.
|
|
3.
|
|
validations:
|
|
required: true
|
|
|
|
- type: textarea
|
|
id: workaround
|
|
attributes:
|
|
label: Is there a way around it
|
|
description: Anything that avoids it, or gets you unstuck. Say so even if it's ugly.
|
|
|
|
- type: input
|
|
id: version
|
|
attributes:
|
|
label: MeshTerm version
|
|
description: It's on the splash screen when you start, and on the About page.
|
|
placeholder: "0.2.0"
|
|
validations:
|
|
required: true
|
|
|
|
- type: input
|
|
id: hardware
|
|
attributes:
|
|
label: What are you running MeshTerm on
|
|
description: >
|
|
Desktop, laptop, Mac, or a handheld — and if it's a handheld, which one.
|
|
placeholder: "ClockworkPi uConsole (CM4), or: desktop PC"
|
|
validations:
|
|
required: true
|
|
|
|
- type: input
|
|
id: os
|
|
attributes:
|
|
label: Which OS, exact version
|
|
placeholder: "Windows 11 24H2 / macOS 15.3 / Debian 12"
|
|
validations:
|
|
required: true
|
|
|
|
- type: input
|
|
id: terminal
|
|
attributes:
|
|
label: Which terminal, and how big
|
|
description: >
|
|
PowerShell, Windows Terminal, iTerm2, the PicoCalc console, ssh from something.
|
|
Size in columns x rows if you know it — a lot of layout bugs are really terminal
|
|
bugs.
|
|
placeholder: "Windows Terminal, 120x40"
|
|
validations:
|
|
required: true
|
|
|
|
- type: input
|
|
id: companion
|
|
attributes:
|
|
label: Which companion device
|
|
description: >
|
|
Be precise. There are a lot of these and they don't behave the same. "A Xiao"
|
|
doesn't narrow it down — "Seeed XIAO nRF52840 + Wio-SX1262" does. Leave blank if
|
|
no radio was involved.
|
|
placeholder: "Heltec V3 / RAK4631 / XIAO nRF52840 + Wio-SX1262"
|
|
|
|
- type: input
|
|
id: firmware
|
|
attributes:
|
|
label: Which firmware version is on it
|
|
placeholder: "MeshCore 1.15.0"
|
|
|
|
- type: dropdown
|
|
id: transport
|
|
attributes:
|
|
label: How is it connected
|
|
options:
|
|
- USB / serial
|
|
- Bluetooth
|
|
- TCP
|
|
- SPI-to-TCP bridge
|
|
- Something else (say so below)
|
|
- No radio — simulator / --mock
|
|
validations:
|
|
required: true
|
|
|
|
- type: dropdown
|
|
id: flavour
|
|
attributes:
|
|
label: Regular or PicoCalc
|
|
description: >
|
|
MeshTerm draws itself differently on a PicoCalc — narrower, fewer colours, a
|
|
different font. A bug in one often doesn't exist in the other, so this saves a
|
|
round of guessing.
|
|
options:
|
|
- Regular (desktop, laptop, ssh)
|
|
- PicoCalc handheld
|
|
- Not sure
|
|
validations:
|
|
required: true
|
|
|
|
- type: dropdown
|
|
id: mock
|
|
attributes:
|
|
label: Does it still happen with `meshterm --mock`
|
|
description: >
|
|
`--mock` runs the whole app against a fake radio. If the bug survives that, it's
|
|
in MeshTerm and I can chase it without hardware. If it doesn't, it's in the link
|
|
or the radio, which is a different hunt. Skip it if the bug is about connecting
|
|
in the first place.
|
|
options:
|
|
- "Yes, still happens with --mock"
|
|
- "No, --mock is fine"
|
|
- "Haven't tried"
|
|
- "Doesn't apply"
|
|
|
|
- type: textarea
|
|
id: error
|
|
attributes:
|
|
label: The exact error, if there was one
|
|
description: >
|
|
Copy it as text rather than photographing the screen — text can be searched, and
|
|
a photo of a terminal is hard to read. Paste the whole traceback if it crashed.
|
|
render: text
|
|
|
|
- type: textarea
|
|
id: log
|
|
attributes:
|
|
label: The log file
|
|
description: >
|
|
MeshTerm keeps one at `~/.meshterm/meshterm.log` (or wherever `MESHTERM_HOME`
|
|
points). Attach it, or paste the last twenty lines. If the problem is hard to
|
|
catch, set **Log detail** to `DEBUG` on the Preferences page, do it once more,
|
|
and send that instead — it records a great deal more.
|
|
render: text
|
|
|
|
- type: textarea
|
|
id: extra
|
|
attributes:
|
|
label: Anything else
|
|
description: >
|
|
Did it used to work? Did it start after an update? Screenshots of a wrong-looking
|
|
screen are genuinely useful here, even though text is better for errors.
|