BBRUNER PatrickFix scan-token race and screen-size-dependent layout test
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
review comments | 10 个月前 | |
Add configurable log overview marker bar (#27) | 21 天前 | |
Strengthen marker DPI tests and type columnizer snapshots | 21 天前 | |
update interfaces and a few more smaller fixes | 6 个月前 | |
Support cancellable folder drops with file selection (#107) | 22 天前 | |
refactor: split ILogWindow into role interfaces Candidate 3 of the 2026-07-26 architecture review. ColumnizerCallback and FilterPipe took the whole ILogWindow for a fraction of it, so Core fakes had to implement the full interface. Carve role interfaces sized to each Core consumer: - ILogLineSource (LineCount, GetLineMemory, GetCurrentFileName) — the columnizer callbacks and, as the Core face of the paint context, the UI's ILogPaintContextUI. The empty ILogPaintContext marker is deleted and IFileViewContext.LogPaintContext retyped to it. - ILineSelectable (SelectLine) — FilterPipe.OriginWindow (was LogWindow). - ISessionSnapshotSource (GatherSessionSnapshot) — FilterPipe.ResultWindow (was OwnLogWindow). ILogWindow survives as the empty composition of the three, kept only for identity holders (the filter-list / highlight-group changed event args). Six members that had no interface-typed caller were dropped from it; the dead GetLogLineMemoryWithWait was removed from LogWindow. New ColumnizerCallbackTests pin both callbacks against a hand-rolled three-member ILogLineSource fake — no Log Window, no Logfile Reader. CONTEXT.md gains the Log Window roles section. | 2 个月前 | |
Fix scan-token race and screen-size-dependent layout test LineVisibilityTracker read the scan's cancellation token inside the queued task; disposing or restarting before the task started faulted it with ObjectDisposedException. Read the token under the lock instead. HighlightDialogLayoutTests assumed the scaled minimum size fits the screen; Windows caps forms at the screen size, so 1.5x/2x failed on the 1024x768 CI runner. Treat that case as inconclusive. Name groupBoxSelection so overlap messages identify it. | 4 天前 | |
Add command-line navigation to a log line (#58) | 22 天前 | |
fix: resolve legacy code-page encodings without opening Preferences first .NET does not ship the legacy Windows code pages; Encoding.GetEncoding throws for them until CodePagesEncodingProvider is registered. Registration lived only in the SettingsDialog constructor, and every site that resolves an encoding *name* swallows the ArgumentException and falls back to Encoding.Default. So a user who picked Windows-1252 in Preferences had that choice silently discarded on every restart in which they did not reopen Preferences. Same for a code page persisted per file in a .lxp, and for the settings JSON. Add EncodingRegistry (LogExpert.Core/Helpers) and route all four resolve sites through it: FileOperationService.FillDefaultEncodingFromSettings, EncodingJsonConverter.ReadJson, PersisterXML.ReadEncoding and the Preferences dropdown. Every method registers the provider before it resolves, so correctness does not depend on one entry point having run first — Program.cs is untouched. Registration uses Lazy with ExecutionAndPublication because files load under Task.Run: the flag must not be observable before registration has completed, or a concurrent first resolve hits the original bug. Also add Windows-1250 to the Preferences encoding dropdown, and extract SettingsDialog.GetAvailableEncodings so the offered set is assertable without building the dialog. DetermineEncoding is deliberately unchanged. The precedence chain (explicit encoding, then BOM, then Preferences default, then machine default) is the intended behaviour; it gains regression tests, not edits. PositionAwareReader is not touched. Delete the memory-mapped read path ---------------------------------- MemoryMappedFileReader and LineOffsetIndex were unreachable. LogfileReader sets IsMultiFile = multiFile || fileNames.Length == 1, so a single file makes IsMultiFile true and the `if (!IsMultiFile && ...)` guard never fires; the multi-file ctor passes multiFile: true. _mmfReader was always null, so BuildIndex, ExtendIndex, GetLine and the fast path in GetLogLineMemoryInternal never ran. Deleting them changes no reachable behaviour. It also could not simply be switched on. MemoryMappedFile.CreateFromFile opens with FileShare.Read, so while a view is mapped the process producing the log cannot append — a test appending to a mapped file fails with IOException even when the writer requests FileShare.ReadWrite. A read path that locks out the writer is incompatible with tail mode, so fixing IsMultiFile would not have produced a working memory-mapped reader but a regression. Same rationale as ADR 0006: the reader folder holds only code something can reach. IsMultiFile itself is left exactly as it is; changing it moves every single-file open onto a different name-resolution path and belongs in its own change. Tests: the four resolve sites are pinned at the site, not just on the helper (FileOperationServiceTests, EncodingJsonConverterTests, PersisterXmlEncodingTests, SettingsDialogEncodingListTests), plus the full DetermineEncoding precedence chain in LogfileReaderEncodingTests. Supersedes #673 and #671. | 2 个月前 | |
Merge pull request #697 from Pr0metheus2/fix/MultiFile-support-for-mid-filename-index-tags-(app.1.log) Fix/MultiFile pattern (Issue #696) | 16 天前 | |
Strengthen marker DPI tests and type columnizer snapshots | 21 天前 | |
fix: recover Session file list from the tab layout XML (#694) v1.42.0 saved Sessions (.lxj) with an empty FileNames list: the save path enumerated DockPanelSuite's DisplayingContents with LINQ/foreach, whose enumerator walks an empty backing list (only Count and the indexer expose the displayed tabs). Loading such a Session failed with 'None of the files in this session could be found'. The enumeration itself is already fixed on Development (5c3d5c90), so newly saved Sessions are correct again. This makes the Sessions written by v1.42.0 loadable: the DockPanel layout XML in them still names every log window (PersistString="LogWindow#<path>"), so when a loaded Session has no file list, recover the paths from the layout before resolving and validating. | 1 个月前 | |
feat: add LogSearcher - pure Log Search module in Core (ticket 1) Extracts the Log Window search loop semantics into a table-tested module per docs/specs/log-search-extraction.md: direction resolution (forward/find-next/Shift+F3), wrap-around-once, regex/ordinal matching over ILogfileReader, progress + wrap events via IProgress, cancellation via CancellationToken. Regex compiles once per search and a bad pattern returns InvalidPattern before any line is read; Find operates on a snapshot so mutating the shared SearchParams cannot affect a run. Lands unused; call-site migration is ticket 2. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> | 2 个月前 | |
refactor: apply tail-follow review findings Inlines the one-line StopLogEventWorkerThread wrapper (banned name per the new CONTEXT.md entry, pure middle man), removes the stale worker field comment, and documents the engine ctor and Dispose, including why the Log Window deliberately calls only Stop() at close. | 2 个月前 | |
fix: FindLine returned a negated miss to callers that expect the nearest line Manual smoke on the Timestamp Locator extraction found "Scroll all tabs to current timestamp" and cross-window time-sync doing nothing at all. Root cause: a sign error in the port. The original FindTimestampLine ended with `return -foundLine` — the internal binary search reports a miss as the negated near-miss line, and the public method flipped it BACK to a positive, scrollable line number. The port misread that as "the negation is the public contract" and passed the negative through, so ScrollToTimestampWorker's `foundLine >= 0` check skipped scrolling on every inexact timestamp. Cross-window sync compares timestamps at millisecond precision (roundToSeconds: false), so an exact hit in a different file essentially never happens — every sync path was a no-op. FindLine now flips a miss to the positive converged line, matching the original exactly. FindNearestLine (used by TimeSpreadCalculator, which flips the sign itself) keeps the raw negated convention. The two mis-pinned tests now encode scroll-to-nearest with exact expected lines traced from the original algorithm, and CONTEXT.md's "Negated near-miss" entry now states which method carries which convention. | 2 个月前 | |
update interfaces and a few more smaller fixes | 6 个月前 | |
optimizations | 10 个月前 | |
fixes for no longer imported settings | 10 个月前 | |
fixing csv problem... and a few others... | 6 个月前 | |
optimizations for debugging | 1 年前 | |
bugfixes and updates to unit tests | 3 个月前 | |
file namespace | 1 年前 | |
optimisations | 5 个月前 |