po: complete Brazilian Portuguese translation - #775

…ndex

Adds 55+ merged PRs to the 3.0.0 changelog since the last update
(amule-project#747, 2026-05-27). Narrative additions cover:

- Packaging: expanded the top list to include the macOS per-arch .app
  bundles and the Windows NSIS installer alongside the existing
  AppImage / Flatpak / .dmg / .zip entries. New bullets for amule-project#785
  (alc/alcc/cas/wxcas everywhere + Windows amuleweb), amule-project#794 (.dmg
  amuleweb path), amule-project#789 (<OS>-<arch> artifact naming), amule-project#780 / amule-project#796
  (Windows DPI + comctl32 manifest), amule-project#784 (FHS share/amule paths).

- Bug Fixes & Stability: post-amule-project#744 fixes including EC notification
  leak (amule-project#797), big-library scaling (amule-project#736, amule-project#840 superseding amule-project#728),
  amulegui ghost entries (amule-project#810, amule-project#819, amule-project#841, amule-project#824, amule-project#830, amule-project#760),
  PartFile early hash (amule-project#762), server protocol fixes (amule-project#835, amule-project#788,
  amule-project#721, amule-project#787), crypto stream UB (amule-project#779), UAF prevention (amule-project#756),
  Kad rotation (amule-project#795, amule-project#799/amule-project#805), GTK warning silencing (amule-project#833,
  amule-project#826/amule-project#836), and the clang-tidy worklist (amule-project#770, amule-project#772-amule-project#774).

- Translations: late-cycle wave covering French/Turkish manpages
  (amule-project#753/amule-project#754/amule-project#776), Galician (amule-project#763), Slovenian (amule-project#771), pt-BR
  (amule-project#768/amule-project#775/amule-project#812), French (amule-project#811), plus man-page tooling for
  date+version drift (amule-project#802).

- Contributors: added ngosang for UX feedback on the late-3.0
  cycle (amule-project#817/amule-project#818/amule-project#821/amule-project#828/amule-project#844) and ongoing work on the
  user-facing manual at amule-org.github.io.

- Merged PRs flat index: extended with amule-project#746-amule-project#845 + amule-project#841.

…ndex

Adds 55+ merged PRs to the 3.0.0 changelog since the last update
(amule-project#747, 2026-05-27). Narrative additions cover:

- Packaging: expanded the top list to include the macOS per-arch .app
  bundles and the Windows NSIS installer alongside the existing
  AppImage / Flatpak / .dmg / .zip entries. New bullets for amule-project#785
  (alc/alcc/cas/wxcas everywhere + Windows amuleweb), amule-project#794 (.dmg
  amuleweb path), amule-project#789 (<OS>-<arch> artifact naming), amule-project#780 / amule-project#796
  (Windows DPI + comctl32 manifest), amule-project#784 (FHS share/amule paths).

- Bug Fixes & Stability: post-amule-project#744 fixes including EC notification
  leak (amule-project#797), big-library scaling (amule-project#736, amule-project#840 superseding amule-project#728),
  amulegui ghost entries (amule-project#810, amule-project#819, amule-project#841, amule-project#824, amule-project#830, amule-project#760),
  PartFile early hash (amule-project#762), server protocol fixes (amule-project#835, amule-project#788,
  amule-project#721, amule-project#787), crypto stream UB (amule-project#779), UAF prevention (amule-project#756),
  Kad rotation (amule-project#795, amule-project#799/amule-project#805), GTK warning silencing (amule-project#833,
  amule-project#826/amule-project#836), and the clang-tidy worklist (amule-project#770, amule-project#772-amule-project#774).

- Translations: late-cycle wave covering French/Turkish manpages
  (amule-project#753/amule-project#754/amule-project#776), Galician (amule-project#763), Slovenian (amule-project#771), pt-BR
  (amule-project#768/amule-project#775/amule-project#812), French (amule-project#811), plus man-page tooling for
  date+version drift (amule-project#802).

- Contributors: added ngosang for UX feedback on the late-3.0
  cycle (amule-project#817/amule-project#818/amule-project#821/amule-project#828/amule-project#844) and ongoing work on the
  user-facing manual at amule-org.github.io.

- Merged PRs flat index: extended with amule-project#746-amule-project#845 + amule-project#841.

Adds 55+ merged PRs to the 3.0.0 changelog since the last update
(#747, 2026-05-27). Narrative additions cover:

- Packaging: expanded the top list to include the macOS per-arch .app
  bundles and the Windows NSIS installer alongside the existing
  AppImage / Flatpak / .dmg / .zip entries. New bullets for #785
  (alc/alcc/cas/wxcas everywhere + Windows amuleweb), #794 (.dmg
  amuleweb path), #789 (<OS>-<arch> artifact naming), #780 / #796
  (Windows DPI + comctl32 manifest), #784 (FHS share/amule paths).

- Bug Fixes & Stability: post-#744 fixes including EC notification
  leak (#797), big-library scaling (#736, #840 superseding #728),
  amulegui ghost entries (#810, #819, #841, #824, #830, #760),
  PartFile early hash (#762), server protocol fixes (#835, #788,
  #721, #787), crypto stream UB (#779), UAF prevention (#756),
  Kad rotation (#795, #799/#805), GTK warning silencing (#833,
  #826/#836), and the clang-tidy worklist (#770, #772-#774).

- Translations: late-cycle wave covering French/Turkish manpages
  (#753/#754/#776), Galician (#763), Slovenian (#771), pt-BR
  (#768/#775/#812), French (#811), plus man-page tooling for
  date+version drift (#802).

- Contributors: added ngosang for UX feedback on the late-3.0
  cycle (#817/#818/#821/#828/#844) and ongoing work on the
  user-facing manual at amule-org.github.io.

- Merged PRs flat index: extended with #746-#845 + #841.

…iag branch

Drops the EcSendPath enum, whose Shared and Part bits were defined and never
referenced -- the two amuleweb handlers deliberately kept their own sets, so a
second bit had no writer and the comment described a scheme with two thirds
missing. It is one flag named for the path that uses it, with the reason it is
path-specific stated where the flag lives rather than only in the commit
message.

Also states why comparing epoch stamps is sound: the counter belongs to one
CFileEncoderMap and therefore to one connection, and every UpdateEncoders call
takes a fresh value before stamping. The 64-bit width was the weaker of the
reasons and was the only one written down, which sent a reader looking for a
cross-client collision that cannot exist.

amule-project#775)

Serving one `EC_OP_GET_UPDATE` walked the library three times over, and did so whether or not anything had changed.

`UpdateEncoders` built a std::set of every live ECID, costing a tree insertion per file to fill and a lookup per encoder in the sweep that follows. The response walk built a second set of the same ECIDs purely to diff against the previous cycle for `EC_TAG_FILE_REMOVED`, and that diff did a lookup per file. A third set answered whether the client had already received an ECID's identifying fields, at another lookup per file. None of the three depended on what had changed.

The live-ECID set becomes a monotonic epoch stamped on the encoder: the loops that build the map already hold each encoder, and the sweep takes whatever was left behind. The current-ID list becomes a sorted vector diffed by linear merge, which the walk gets for free because the encoder map is keyed by ECID; a legacy client infers removal from absence and never reads it, so for one of those it is not built at all. The sent-with-detail set becomes a flag on the encoder, which also bounds it -- the set was only ever inserted into, so a long-lived client on a churning library grew it without limit. Two lookups per emitted file also go, the walk having re-found by key an encoder it already held.

Measured on a production daemon with 1205 shared files, comparing runs at similar peer load: `sync` 0.43-0.49 -> 0.26-0.28 ms, `walk` 0.68-0.85 -> 0.31-0.44 ms, `diff` 0.11-0.13 -> 0.00 ms. About 2.2x across the three, and roughly 1.8x on the handler end to end. Load matters for the comparison because those phases iterate files rather than peers but are still sensitive to cache pressure; `rest`, which this does not touch, held flat per-peer across the same runs, which is the check that the rest of the difference is not being claimed here. The instrumentation also reports that about 1% of the library changes per poll, which is the premise the whole change rests on and had not previously been measured.

Confined to the `EC_OP_GET_UPDATE` path, which amulegui and amuleapi poll. The two amuleweb handlers keep their sets deliberately: they iterate a CopyFileList snapshot rather than the encoder map, so it is neither ordered for the merge nor holding the encoder for the flag.

No wire change in either direction. A partial-update client gets the same skips and removal markers; a legacy client gets the same child-less alive marker for every unchanged file and no removal markers at all.

`ComputeRemovedIds` is split out as a pure function so it can be tested without an app, a daemon or a connected client -- worth pinning because both ways of getting it wrong are silent, a missed removal leaving a row in the client's list for the life of the connection and a spurious one deleting a file the user still has. Twelve cases, each checked by mutation. A static_assert ties the ordering guarantee to the container type, and a debug-only precondition checks both inputs are strictly increasing; the latter uses assert() rather than wxASSERT because wx installs its handler from the wxApp constructor and would be a silent no-op in the tests.

The GET_UPDATE walk touches every encoder on every poll and does very
little per entry -- read the file pointer, read two integers, append an
ECID. After amule-project#775 removed the per-file tree lookups, what was left was
dominated by the iteration itself: a std::map walk chases red-black-tree
pointers around the heap, which the prefetcher cannot follow, so the cost
was cache misses rather than work. At 1206 files that phase measured around
0.35 ms with roughly 290 ns per file, for a handful of instructions each.

The encoders now live in a vector kept sorted by ECID. Iteration becomes a
linear scan of contiguous memory, and the walk keeps the ascending order the
removal merge depends on for free, exactly as it did from the map.

Lookup becomes a binary search. That is the right way round now: amule-project#775 left
only the reconcile below and two amuleweb call sites doing lookups, against
a walk that reads every entry once per poll per client.

Structural change is rarer still, so it can afford to be linear. New
encoders are appended to a side vector and merged in one pass rather than
inserted into the middle of the array one at a time, which keeps a first
poll -- where every file is new -- from paying a memmove per file. The merge
runs after the downloads pass as well as at the end, because a partfile
appears in both lists and the shares pass asks, via find(), whether this
reconcile has already reached it; leaving new entries unmerged would hide
them from that lookup and build a second encoder for the same file. Dead
encoders are now compacted out in a single ordered sweep instead of being
collected into a set and erased one lookup at a time.

operator[] no longer inserts on a miss the way std::map's did. That insert
placed a NULL encoder in the map, which the next reconcile would have
dereferenced; returning NULL is what the two call sites already behave as
though it does.

The static_assert that tied ordering to std::map is replaced by a debug-only
check of the invariant at the end of each reconcile, which tests the thing
itself rather than a proxy for it, and rejects duplicate ECIDs as well as
misordering -- a duplicate would mean two encoders for one file.

Exercised against a daemon in a Debug build, so that invariant was live:
shared list served and stable across repeated polls, a file added appeared
and a file removed disappeared with the count exactly right either side, and
a partfile entered the download queue, which is the merge-ordering case
above. No assertion fired.

…omment

`std::is_sorted` requires its comparator to induce a strict weak ordering.
The `<=` used to make it reject equal neighbours as well as out-of-order
ones is not irreflexive, so a hardened standard library is entitled to
abort on the predicate itself -- and libstdc++ under _GLIBCXX_DEBUG does.
That would fire on a debug build, which is precisely the build these checks
exist to serve: a release build compiles them out, so the debug run is the
only thing covering ordering here.

`std::adjacent_find` with a plain binary predicate has no ordering contract
and says the same thing -- find the first neighbouring pair that is not
strictly increasing -- at the same cost. Applied to both the encoder map's
invariant and to ComputeRemovedIds, which carried the same construct from
amule-project#775, so the two do not diverge.

Re-verified by feeding ComputeRemovedIds unsorted and duplicated input:
both still abort, naming the file and line.

Also drops an epoch comment that appeared twice, verbatim, inside the class
body -- a leftover from rewriting the class around it. Nothing catches that:
it survived clang-format and both clang-tidy tiers.

And states the contract at the two operator[] call sites. The documented
NULL return is dereferenced unchecked at both, which is a crash rather than
a graceful path; UpdateEncoders has already run against the same snapshot,
so the real contract is that it never misses, and a wxASSERT says so instead
of leaving it implied. wxASSERT is the right macro here, unlike in
ECIdDiff.h: these are daemon paths, where a wxApp exists to install the
handler.

amule-project#776)

CFileEncoderMap becomes a std::vector kept sorted by ECID instead of a std::map. Lookup becomes a binary search, iteration a linear scan, and structural change a merge or a compaction rather than a per-node insert or erase.

The hypothesis was that the GET_UPDATE walk was dominated by chasing red-black-tree pointers. That was wrong. Measured on a production daemon with 1206 shared files, over 66 windows against 22 in a matched band of 26-38 peers: `sync` 0.260 -> 0.190 ms (-27%), `walk` 0.340 -> 0.350 ms (+3%), and `rest` -- untouched, the control -- 0.600 -> 0.495 ms. The walk did not improve, and since the control moved 17% in the same window the two runs are not on equal footing even at matched peer count.

The walk turns out to track peer count despite iterating a fixed 1206 files (0.15 ms at 5-15 peers rising to 0.44 ms at 39-47). It is memory-bound, but the misses are on the encoder and CKnownFile objects, whose cache residency the per-peer tag building destroys between polls -- not on the container. Making the spine contiguous does not help when each entry immediately dereferences two unrelated heap addresses. Moving the CKnownFile pointer and the sent-with-detail flag into the vector entry would be the direct attack, as a follow-up.

What it does buy is `sync` at 27% cheaper on every poll for every connected client, from the reconcile's per-file find() calls, and that saving grows with the library rather than staying flat.

Three correctness items travel with it. operator[] no longer inserts on a miss, where std::map's did, leaving a NULL encoder for the next reconcile to dereference; both call sites now assert the contract they already relied on. The removal sweep loses a set, compacting dead encoders out in one ordered pass instead of collecting them and erasing one lookup at a time. And the ordering checks become conformant: std::is_sorted requires a strict weak ordering and the `<=` used to reject equal neighbours is not irreflexive, so libstdc++ under _GLIBCXX_DEBUG aborts on the predicate itself -- on a debug build, which is the only build these checks run in. Both sites now use std::adjacent_find, which also fixes ECIdDiff.h carrying the same construct from amule-project#775.

The merge runs after the downloads pass as well as at the end: a partfile appears in both lists, and the shares pass uses find() to ask whether the reconcile already reached it, so leaving new entries unmerged would build a second encoder for the same file.

Exercised against a daemon in a Debug build with the ordering invariant live: shared list stable across repeated polls, a file added appeared and one removed disappeared with counts exact either side, and a partfile entered the download queue. The ComputeRemovedIds preconditions are mutation-proven. The encoder map's own invariant assert is not -- removing the sort on a small test config still produced ordered input, so that mutation was inconclusive.