sneak, 2026-10-16, in chat: sfdupes scan often prints nothing for a long while and appears frozen, yet when the display does update it reports more than 1,000 files a second. That should not happen.
Done when: while any phase runs, the display redraws at a steady interval (at most about a second apart) whatever the walk, hashing or database writes are doing, so it never looks frozen while work goes on; the rate shown covers the time since the last redraw, not a burst; if the work itself is stuck (waiting on a lock, a slow disk or the database), the display says what it waits for; a test drives a phase whose producer stalls and checks the display keeps redrawing. First check whether the progress changes already on next (issues 112-114) cure it, and say on this issue which build shows it.
Model: opus-5-5
sneak, 2026-10-16, in chat: `sfdupes scan` often prints nothing for a long while and appears frozen, yet when the display does update it reports more than 1,000 files a second. That should not happen.
**Done when:** while any phase runs, the display redraws at a steady interval (at most about a second apart) whatever the walk, hashing or database writes are doing, so it never looks frozen while work goes on; the rate shown covers the time since the last redraw, not a burst; if the work itself is stuck (waiting on a lock, a slow disk or the database), the display says what it waits for; a test drives a phase whose producer stalls and checks the display keeps redrawing. First check whether the progress changes already on `next` (issues 112-114) cure it, and say on this issue which build shows it.
Model: opus-5-5
Which build shows it: v0.0.2 (what @latest installs today) and next alike, in part.
On v0.0.2, a phase with a total (hash, update, the content reads) redraws on a terminal only when a file finishes, and off a terminal a line is printed only when a file finishes. A stretch with no finished file, such as one large file being read or a slow disk, prints nothing. When something finishes, the rate shown is the phase's average since it started, so after a stall it can still read over 1,000 files/s.
next (#112) already redraws every 100 ms on a terminal and prints a line every 5 seconds off one, whatever the work is doing, so it no longer looks frozen. But its rate is still the phase's average, and a stalled phase does not say what it is waiting for, apart from the database waits.
Plan for the implementer (one PR on next, package main):
Rate. The rate shown is the items finished over the last 5 seconds: since the last line off a terminal, and over the last 5 seconds on one. A stall shows the rate falling to 0, and a burst after one does not read as a steady rate. The ETA keeps coming from the phase's average rate, so it does not swing with each burst.
Stall. When no item has finished for 10 seconds, the line says so and what the phase is doing, for example no file finished for 42s, reading files. Each phase gives one short phrase where it is defined: listing directories, reading files, writing to the database, reading the database, searching the database, writing the report. The phrase sits with the kept parts of the line, so it is not dropped on a narrow terminal before the rate.
Tests with a settable clock and interval, under a second each: a producer that stalls, with the display going on redrawing, the rate reaching 0 and the stall line appearing; a burst after a stall, with the rate covering only the last 5 seconds.
README "Progress" says what the rate covers and when the stall line appears.
Model: opus-5-5
Which build shows it: `v0.0.2` (what `@latest` installs today) and `next` alike, in part.
- On `v0.0.2`, a phase with a total (`hash`, `update`, the content reads) redraws on a terminal only when a file finishes, and off a terminal a line is printed only when a file finishes. A stretch with no finished file, such as one large file being read or a slow disk, prints nothing. When something finishes, the rate shown is the phase's average since it started, so after a stall it can still read over 1,000 files/s.
- `next` (https://git.eeqj.de/sneak/sfdupes/issues/112) already redraws every 100 ms on a terminal and prints a line every 5 seconds off one, whatever the work is doing, so it no longer looks frozen. But its rate is still the phase's average, and a stalled phase does not say what it is waiting for, apart from the database waits.
Plan for the implementer (one PR on `next`, package `main`):
- **Rate.** The rate shown is the items finished over the last 5 seconds: since the last line off a terminal, and over the last 5 seconds on one. A stall shows the rate falling to 0, and a burst after one does not read as a steady rate. The ETA keeps coming from the phase's average rate, so it does not swing with each burst.
- **Stall.** When no item has finished for 10 seconds, the line says so and what the phase is doing, for example `no file finished for 42s, reading files`. Each phase gives one short phrase where it is defined: `listing directories`, `reading files`, `writing to the database`, `reading the database`, `searching the database`, `writing the report`. The phrase sits with the kept parts of the line, so it is not dropped on a narrow terminal before the rate.
- **Tests** with a settable clock and interval, under a second each: a producer that stalls, with the display going on redrawing, the rate reaching 0 and the stall line appearing; a burst after a stall, with the rate covering only the last 5 seconds.
- README "Progress" says what the rate covers and when the stall line appears.
Model: opus-5-5
clawbot
added this to the 1.0.0 milestone 2026-10-16 22:40:52 +02:00
Built as planned above in #126. The PR body names its two judgement calls, and notes that on an 80-column terminal the words about nothing finishing rarely fit and are left out.
Model: opus-5-5
Built as planned above in https://git.eeqj.de/sneak/sfdupes/pulls/126. The PR body names its two judgement calls, and notes that on an 80-column terminal the words about nothing finishing rarely fit and are left out.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
sneak, 2026-10-16, in chat:
sfdupes scanoften prints nothing for a long while and appears frozen, yet when the display does update it reports more than 1,000 files a second. That should not happen.Done when: while any phase runs, the display redraws at a steady interval (at most about a second apart) whatever the walk, hashing or database writes are doing, so it never looks frozen while work goes on; the rate shown covers the time since the last redraw, not a burst; if the work itself is stuck (waiting on a lock, a slow disk or the database), the display says what it waits for; a test drives a phase whose producer stalls and checks the display keeps redrawing. First check whether the progress changes already on
next(issues 112-114) cure it, and say on this issue which build shows it.Model: opus-5-5
Which build shows it:
v0.0.2(what@latestinstalls today) andnextalike, in part.v0.0.2, a phase with a total (hash,update, the content reads) redraws on a terminal only when a file finishes, and off a terminal a line is printed only when a file finishes. A stretch with no finished file, such as one large file being read or a slow disk, prints nothing. When something finishes, the rate shown is the phase's average since it started, so after a stall it can still read over 1,000 files/s.next(#112) already redraws every 100 ms on a terminal and prints a line every 5 seconds off one, whatever the work is doing, so it no longer looks frozen. But its rate is still the phase's average, and a stalled phase does not say what it is waiting for, apart from the database waits.Plan for the implementer (one PR on
next, packagemain):no file finished for 42s, reading files. Each phase gives one short phrase where it is defined:listing directories,reading files,writing to the database,reading the database,searching the database,writing the report. The phrase sits with the kept parts of the line, so it is not dropped on a narrow terminal before the rate.Model: opus-5-5
Built as planned above in #126. The PR body names its two judgement calls, and notes that on an 80-column terminal the words about nothing finishing rarely fit and are left out.
Model: opus-5-5