po: in-place rename Petar Maymounkov's email + paper URL in all catalogs (post #851) - #853

…rent

The About box and three kademlia source-file copyright headers carried
the 2002-era post.harvard.edu email and the long-defunct
http://kademlia.scs.cs.nyu.edu page. Petar Maymounkov confirmed his
current address and a durable canonical URL for the paper on #838:

  email: [email protected]  -> [email protected]
  url:   http://kademlia.scs.cs.nyu.edu
         -> https://pdos.csail.mit.edu/~petar/papers/maymounkov-kademlia-lncs.pdf

Updated in five spots:
  - src/amuleDlg.cpp:533-534   (user-visible About box text)
  - src/kademlia/routing/Contact.cpp:24-25
  - src/kademlia/routing/RoutingBin.cpp:24-25
  - src/kademlia/routing/RoutingZone.cpp:25-26

Closes #838.

…ule-project#912)

Extends existing categories (preferring extensions over new lines):
- Performance/Upload: amule-project#898 SlotAllocation default raised.
- Networking & Discovery: wire-parser hardening list extended with
  amule-project#879/amule-project#882/amule-project#890/amule-project#886; new amuleweb security hardening bullet
  consolidating ngosang's amule-project#869-amule-project#874 triage (all landed in amule-project#875);
  amulegui list extended with amule-project#857; shared-folder watcher extended
  with amule-project#858.
- Packaging: Windows installer i18n line extended with amule-project#899.
- Internals & Refactoring: new docs-polish + code-quality bullets
  covering amule-project#851/amule-project#855/amule-project#862/amule-project#888/amule-project#900/amule-project#866/amule-project#867/amule-project#895 and amule-project#909/amule-project#910/amule-project#912.
- Translations: new pre-release final-wave bullet covering amule-project#847/amule-project#856/
  amule-project#891/amule-project#908/amule-project#860/amule-project#904/amule-project#859/amule-project#863/amule-project#861/amule-project#880/amule-project#911/amule-project#901/amule-project#902/amule-project#889/amule-project#868/amule-project#853.
- Bug Fixes & Stability: amule-project#850/amule-project#854/amule-project#878/amule-project#906.
- CI: ccache wiring (amule-project#892, amule-project#903) + CodeQL binutils-dev (amule-project#907).

Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif
(both first-time contributors).

PR index extended through amule-project#912.

Extends existing categories (preferring extensions over new lines):
- Performance/Upload: #898 SlotAllocation default raised.
- Networking & Discovery: wire-parser hardening list extended with
  #879/#882/#890/#886; new amuleweb security hardening bullet
  consolidating ngosang's #869-#874 triage (all landed in #875);
  amulegui list extended with #857; shared-folder watcher extended
  with #858.
- Packaging: Windows installer i18n line extended with #899.
- Internals & Refactoring: new docs-polish + code-quality bullets
  covering #851/#855/#862/#888/#900/#866/#867/#895 and #909/#910/#912.
- Translations: new pre-release final-wave bullet covering #847/#856/
  #891/#908/#860/#904/#859/#863/#861/#880/#911/#901/#902/#889/#868/#853.
- Bug Fixes & Stability: #850/#854/#878/#906.
- CI: ccache wiring (#892, #903) + CodeQL binutils-dev (#907).

Contributors footer gains mifritscher and nguyenhoangminhhieu2004-gif
(both first-time contributors).

PR index extended through #912.

The splash stayed up until the startup hash queue drained, because
FinishStartupSplash() both ended the list batches and showed the window, and it
only ran once CThreadScheduler reported nothing left to hash. A share with many
new files therefore left the application unreachable for as long as hashing
took -- half an hour in issue amule-project#853 -- and Preferences was among the things out
of reach, so a user could not stop aMule hashing a folder they no longer wanted
to share.

The justification for waiting does not hold. It reasoned that each completion's
main-thread work would leave the UI unusable, but that is only true once the
batch is over: while it is open, BeginBatchUpdate() makes ShowFile() an O(1)
append instead of a sorted insert that rebuilds the row index. The freeze it
was avoiding came from ending the batch, which the same function did a few
lines earlier.

So the two are separated. When the scan ends the download list closes its batch
as before, the shared list sorts what the scan found and thaws while its batch
stays open, and the window goes up. Rows from the drain then arrive as appends,
and the poll tick sorts them into place -- but only when one actually arrived.
Hashing cost tracks bytes, so a large file is minutes of nothing followed by a
single append; sorting per tick regardless would run a full std::sort, a
row-index rebuild and a model reset once a second for no reordering at all. The
tick also reports what is left on the shared-files label, so the count is
visible in the window rather than on a splash nobody can see past.

Hashing gets the whole of the bar's last band back as a result: it had
kScanBandEnd = 99 and its own band from there, so the longest phase of a first
run advanced the bar by one point and read as a hang.

CSplashScreen::SetLoopRunning() went with it. It existed so updates would stop
pumping the loop once the splash outlived OnInit, which it no longer does, and
without it m_pumpsLoop could never be false -- leaving an unreachable branch in
SetProgress().

The splash stayed up until the startup hash queue drained, because
FinishStartupSplash() both ended the list batches and showed the window, and it
only ran once CThreadScheduler reported nothing left to hash. A share with many
new files therefore left the application unreachable for as long as hashing
took -- half an hour in issue amule-project#853 -- and Preferences was among the things out
of reach, so a user could not stop aMule hashing a folder they no longer wanted
to share.

The justification for waiting does not hold. It reasoned that each completion's
main-thread work would leave the UI unusable, but that is only true once the
batch is over: while it is open, BeginBatchUpdate() makes ShowFile() an O(1)
append instead of a sorted insert that rebuilds the row index. The freeze it
was avoiding came from ending the batch, which the same function did a few
lines earlier.

So the two are separated. When the scan ends the download list closes its batch
as before, the shared list sorts what the scan found and thaws while its batch
stays open, and the window goes up. Rows from the drain then arrive as appends,
and the poll tick sorts them into place -- but only when one actually arrived.
Hashing cost tracks bytes, so a large file is minutes of nothing followed by a
single append; sorting per tick regardless would run a full std::sort, a
row-index rebuild and a model reset once a second for no reordering at all. The
tick also reports what is left on the shared-files label, so the count is
visible in the window rather than on a splash nobody can see past.

Hashing gets the whole of the bar's last band back as a result: it had
kScanBandEnd = 99 and its own band from there, so the longest phase of a first
run advanced the bar by one point and read as a hang.

CSplashScreen::SetLoopRunning() went with it. It existed so updates would stop
pumping the loop once the splash outlived OnInit, which it no longer does, and
without it m_pumpsLoop could never be false -- leaving an unreachable branch in
SetProgress().

…oes (amule-project#858)

The splash stayed up until the startup hash queue drained, because
FinishStartupSplash() both ended the list batches and showed the window, and it
only ran once CThreadScheduler reported nothing left to hash. A share with many
new files therefore left the application unreachable for as long as hashing
took -- half an hour in issue amule-project#853 -- and Preferences was among the things out
of reach, so a user could not stop aMule hashing a folder they no longer wanted
to share.

The justification for waiting does not hold. It reasoned that each completion's
main-thread work would leave the UI unusable, but that is only true once the
batch is over: while it is open, BeginBatchUpdate() makes ShowFile() an O(1)
append instead of a sorted insert that rebuilds the row index. The freeze it
was avoiding came from ending the batch, which the same function did a few
lines earlier.

So the two are separated. When the scan ends the download list closes its batch
as before, the shared list sorts what the scan found and thaws while its batch
stays open, and the window goes up. Rows from the drain then arrive as appends,
and the poll tick sorts them into place -- but only when one actually arrived.
Hashing cost tracks bytes, so a large file is minutes of nothing followed by a
single append; sorting per tick regardless would run a full std::sort, a
row-index rebuild and a model reset once a second for no reordering at all. The
tick also reports what is left on the shared-files label, so the count is
visible in the window rather than on a splash nobody can see past.

Hashing gets the whole of the bar's last band back as a result: it had
kScanBandEnd = 99 and its own band from there, so the longest phase of a first
run advanced the bar by one point and read as a hang.

CSplashScreen::SetLoopRunning() went with it. It existed so updates would stop
pumping the loop once the splash outlived OnInit, which it no longer does, and
without it m_pumpsLoop could never be false -- leaving an unreachable branch in
SetProgress().