Log directory creation and log saving#6
Merged
5133n merged 2 commits intofrstrtr:origin/sharechain/async_threadfrom Apr 26, 2021
Merged
Log directory creation and log saving#65133n merged 2 commits intofrstrtr:origin/sharechain/async_threadfrom
5133n merged 2 commits intofrstrtr:origin/sharechain/async_threadfrom
Conversation
frstrtr
added a commit
that referenced
this pull request
Apr 20, 2026
Three-phase animation state machine (spec §6, dashboard.html:4866-
5400). This commit ships the core — timing math, stagger schedules,
position interpolation for dying/wave/born tracks, and the
controller (start/tick/queueNext/reset). Scale, colour-lerp,
particle dissolution and card overlays land in subsequent commits;
each is a clearly isolable addition that the pure-function structure
accommodates without redesign.
Phase timing (verbatim from dashboard.html:4977-4982):
phase1Dur = 3000 DYING
phase2Dur = fast ? 2000 : 4000 WAVE (spec §6 text has typo,
code is authoritative)
phase2Start = phase1Dur
phase3Start = phase2Start + phase2Dur * 0.7 (overlap)
phase3Dur = 3000 BORN
duration = phase3Start + phase3Dur
Stagger schedules (all preserved verbatim from dashboard.html):
DYING — last dying share first, 150 ms per share. Newer end of
the window dies visibly before older shares (mirrors the
natural tail-eviction order).
WAVE — tail-first per dashboard.html:5146-5151:
distFromTail = (N-1) - newIndex
fraction = distFromTail / (N-1)
shareStart = fraction * phase2Dur * 0.7
shareT = clamp01((p2elapsed - shareStart) / 600)
ease = 1 - (1-shareT)^3 (easeOut-cubic)
Tail starts first, head last; each share animates over a
600 ms window regardless of phase2Dur.
BORN — newest share first, 150 ms per share, full phase3Dur
window per share.
Input / output:
AnimationInput {
oldShares, newShares, addedHashes, evictedHashes,
oldLayout, newLayout, userContext, palette,
hashOf, fast?
}
AnimationPlan {
tEnd, phase1Start/Dur, phase2Start/Dur, phase3Start/Dur,
frameAt(t): FrameSpec
}
FrameSpec {
cells: CellFrame[], // per-share {x,y,size,color,alpha,track}
backgroundColor,
layout // post-merge layout
}
Controller:
createAnimationController() → {
isRunning(), start(plan, now), tick(now), queueNext(plan), reset()
}
- tick() returns the frame to paint, or null when idle.
- queueNext() during running: queued plan starts automatically on
next tick after current tEnd (§6 threshold rule #2, _animDeferred).
- queueNext() while idle: queued plan starts on the next tick.
- reset() drops current + queued.
Also exposed:
SKIP_ANIMATION_NEW_COUNT_THRESHOLD = 100 (§6 rule #1, callers
skip build/start when
newCount >= 100)
Helpers: clamp01, lerp, easeInOut, computePhaseTiming(fast?)
Plugin: explorer.animator.three-phase (provides 'animator.grid')
Tests (19): phase-timing constants for slow + fast; clamp/lerp/ease
sanity; empty input edge; fast vs slow tEnd; wave position
interpolation at t=0 and t=tEnd; wave stagger (tail moves before
head at early phase2 tick); dying staggered alpha decay; dying at
phase1 end alpha ~= 0; born spawns below grid and lands at (0,0);
born alpha fade-in over first 30%; controller idle tick; controller
start+tick+finish becomes idle; controller queueNext during running;
controller queueNext on idle starts next tick; controller reset
drops both.
Status
- 132/132 tests pass in 2.2s (113 prior + 19 new)
- Typecheck clean
- Bundles: shared-core 25.1 KB / 40, sharechain-explorer 33.9 KB /
120 — both under budget
- Pipeline green end-to-end via npm run verify
Next commits layered onto this core:
Phase B #5 scale effects (lift-slide-land wave scale, dying-rise
scale, born shrink from bornScale→1x). Requires no new
types — just richer CellFrame.size interpolation and
paint-program extension for centred-scale fillRect.
Phase B #6 colour lerp — dying lerps toward palette.dead across
its stagger window; born coalesces from unverified to
coin colour.
Phase B #7 particle effects (ash dissolution, birth coalescence)
and card overlays (miner addr + PPLNS % text during
hold frames). Largest increment — may split again.
Phase B #8 wire mergeDelta + animator + gridRenderer into a
RealTime plugin (SSE subscription + delta application
+ animation trigger). Unlocks the demo against a live
c2pool server.
frstrtr
added a commit
that referenced
this pull request
Apr 24, 2026
…-MEMPOOL step 2
Adds the feerate-sorted index that Phase C-TEMPLATE's block-template
builder needs to do "highest-feerate first" tx selection for GBT-
equivalent output. Plus a recompute pass that runs after each block-
connect to re-attempt fee computation for entries whose inputs were
previously outside our UTXO window.
src/impl/dash/coin/mempool.hpp:
+ std::multimap<double, uint256, std::greater<double>>
m_feerate_index — best-first iteration via begin() (matches
LTC mempool's pattern at line 720)
+ Maintained on add (insert when fee_known), on remove (search
by feerate equal_range + erase), on recompute_unknown_fees
(insert when newly-resolved). On clear, drop everything.
+ recompute_unknown_fees(utxo) → int — re-tries compute_fee_locked()
for all fee_known=false entries. Returns count of newly-resolved.
Logs "[MEMPOOL] fee revalidation: resolved=R still_unknown=U
resolved_fees=F sat pool_size=N". Called from on_full_block
after remove_for_block — block's outputs are now in UTXO and
may resolve previously-unknown inputs from CPFP chains.
+ get_sorted_txs_with_fees(max_bytes) →
pair<vector<SelectedTx>, total_fees> — Phase C-TEMPLATE
consumer. Iterates m_feerate_index best-first, includes each tx
until max_bytes exhausted. Excludes fee_known=false entries
(don't poison coinbasevalue with fee=0). Stale-input guard
re-checks each candidate's inputs against live UTXO + parent-
mempool chain (catches the brief window between tip-change and
full_block arrival where remove_for_block hasn't yet evicted
now-double-spent txs).
src/impl/dash/main_dash.cpp:
- on_full_block extension: alongside remove_for_block, also call
dash_mempool->recompute_unknown_fees(utxo). Comment block updated
to explain the parent-in-this-block → child-fee-now-resolvable
rationale.
Live smoke 2026-04-24 (5 min window):
- 5 mempool adds (the throttle hides #6+ until #100)
- One add had UTXO-resolvable fee (3740 sat)
- 3 blocks landed; remove_for_block silent (none of our 5 txs
happened to be in those blocks — normal for a small mempool
sample on a busy chain)
- No errors, no crashes
Known limitation surfaced (relevant for step 3):
Dash dashd doesn't honor BIP 35 `mempool` requests by default
(no NODE_BLOOM service flag) — see p2p_node.hpp:364 comment.
Mempool accumulates only via naturally-relayed inv messages,
so cold start has a slow ramp-up (~minutes to populate). For
Phase C-TEMPLATE this means initial templates may have fewer
fees than dashd's GBT until the mempool warms; not a correctness
bug but visible in shadow-mode comparison.
Step 3 (BIP 35 drain consumer) is essentially DONE automatically
— our handle_msg(message_inv) path already requests MSG_TX inv
items via getdata, and handle_msg(message_tx) routes through the
new_tx event → Mempool::add_tx pipeline this commit completes.
The wire is in place; the actual fill rate is gated by what peers
relay.
Next steps:
- Phase C-MEMPOOL step 3 (alternative): consider adding our own
mempool-warm path via repeated getmempool against dashd-RPC if
--dashd-rpc set. Honors "RPC stays optional" pattern.
- Phase C-TEMPLATE: actual block-template builder (subsidy + MN
payment split + coinbase payload + merkle root + header packing
+ target). Consumes get_sorted_txs_with_fees() + Phase C-PAY's
GetMNPayee().
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.