You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Turned out to be slower than allowing browser to handle it.
Just rendering the whole SVG now.
UPD: re-calculation of old events with novel cr been costly,
implemented in-view events render.
Perhaps old events can be simply memoized.
But then they also add overhead of tracing whether they’re inspected.
Overall, it becomes more efficient to render only in-view ones.
profile code
Added application-level profiling & viz.
issuing invites on infini-events slows down a ton
Switched to issuing in batches, outside render fn.
re-rendering refs is meh
Switched to rendering in-view events and ones directly atop and below (for refs).
re-rendering all other stuff is meh
Switched to rendering in-view events and ones directly atop and below (for refs).
perhaps increase efficiency of event->learned-events
As this logic is reused for cr witnesses, voting witnesses, whether received event, middle learned events. (last two use the same mem)
can we use shared data source between Workers and main thread?
how to memoize from a worker?
see how cljs-thread can be used
run core logic in parallel
run core logic out of the main thread
perhaps performance drops as lookups from mem get ever more costly
These lookups are mostly within the cr context, so we can try doing lookups within cr context.
solution: do hierarchical lookup, where cr is first
con: will slow down overall performance due to hierarchical lookup everywhere
con: will slow down as more cr come
solution: bind mem for cr in code, have all fns store their mems under it.
cr -> fn-name -> fn-args -> vals
inspector got slow on trace display
perhaps do not trace from mem resolution
perhaps do not render inputs and args if they don’t even fit
perhaps don’t render traces that are < 1 pixel wide
Or don’t collect traces that are instanteneous.
Although both of that hinders insight.
Rendering them is alright, thei’r inputs and args display are costly.
input and result is not that valuable to display ALL THE TIME
Make their display a result of user’s intent.
E.g., on hover.
inspector can scale via css, avoiding costly tree recompute
Use a class to scale, like .scale-2x on root flame trace.
inspector to scroll viz to peeked events
perhaps Browser’s search can be used to go through matched results
inspector to show seq’s lazily
As there can be > 1k elements, showing them eagerly is not needed and damm not performant.
only useful for dev build with a ton of traces or memos
so won’t be of that much use if dev version is not deployed
fix inspector
pass top evt and not witness
fix stuck on 3rd round
add mod keys to inspector
shift to peek on hover
shift to inspect on click
expand on plain click
add flip as right-click option
make it easier to uninspect
show stake-map as of prev cr
IDEA trace as meta on returned values
cons: primitive values won’t be traced
solution: wrap returned values in trace object
cons: on error won’t see trace
solution: errors as data
alternatively: store trace into inspector’s log, use it as mem as well
add ns as table key, add #1 #2 entities in table view
dense table rows on multiple events inspection
pretty table highlight on peek/inspected
CANCELLED maybe show stake as member’s shirt
Shown intersity of background color instead
make it inspectable
ready viz by 18th February, deploy and get feedback
perhaps layout viz horizontaly on wide displays
horizontal view
select view mode based on screen resolution
controls to switch between horizontal/vertical mode
animate received events
add explanation on first appearance of novel algorithm behaviour
playback controls
sync with scroll
playback one event
rewind back on scroll up
freeze to not rewind on scroll
CANCELLED starting position to issue one event
Starting position is an intro section, event’s are issued as user scrolls to the viz section.
pretty design
perhaps intro section
layout
background
buffer more events ahead-of-time on idle, so it’s snappier to viz them
test on Firefox
test on Safari
test on mobile
test on high res
fix received events popping
perhaps untie transitions from rendered events
Now transition’s engine is calculating all transitions, react components subscribe to the view-state they’re interested in.
fix stuck round
That’s perhaps due to dirty mem lookup.
better peek viz
pretty scale
fix dimming of votes
instead of opacity use lightened color for stake map
more animation
witness
round
stake map
votes
cleanup html
CANCELLED received events may have the same x y, not desired
No more a problem, since received events form a blockchain viz now.
hardly reachable members may issue it’s stale event, which will make refs look not pretty
maybe lookup from mem as goog.object will be faster than (transient (hash-map))
It’s about the same speed, be it js-obj is a bit faster
maybe switch mem to js-obj by args hash
switch mem warmup to loop with recur
make inspector to fit the layout
It has 1/3 of a dimension.
PROBLEM showing nested data structures in-line makes for a fast out-of-layout size
show type tables, populated with data of corresponding type
Following types are in use:
event
tx
round
vote
concluded-voting
concluded-round
plain
compactness can be further enhanced by extracting ns of keys to a table type
PROBLEM having fixed inspector breaks the scroll illusion
Ok for now. No good solutions found.
SOLUTION make inspected positioned relative to scroll
PROBLEM out-of-scroll inspected affect viz
SOLUTION make only in-view inspected affect viz
SOLUTION flush out-of-view inspected
PROBLEM implicit behaviour, user won’t expect it
PROBLEM where to add inspectable?
SOLUTION to an on-screen inspected table type, or a new one
PROBLEM rather complex UX (and to dev)
PROBLEM having fixed type tables user may add too many items, making them out-of-bound
SOLUTION add scroll inside tables
PROBLEM when no more table scroll is availabel - it’ll affect the viz scroll
SOLUTION catch scroll events, stop propagation
make algorithm understandable
capture in data the reason round increases
capture in data the reason of becoming a witness
what goes on the home section?
option1
problem definition - conflicting transactions
solution - total order, async byzantine
method - hashgraph
method - virtual voting
links to resources
see for yourself ->
total
Making a distributed ledger,
having total order of transactions,
powered by an
asynchronous byzantine-fault tolerant
virtual voting
atop a
HASHGRAPH
of gossip.
It’s all there’s to it, see for yourself ->
FIXES
“This event’s transaction, issued by BLANK”
tutors get cut height-wise
not inspected on click on “seen Charlie’s event”
>| does not scroll to next
Still reproduces?
>>| does nothing
|<< transitions are slowpoke
arrow on home may not be an intuitive action to scroll
Ctrl+hover may not be intuitive
may not be intuitive to hover over text
stake change fromto may not be intuitive
fix damm slow custom transitions on mobile
Somewhat fixed.
fix highlight of contained in inspected tutor inspectables
Maybe derive flat representation only for view, and keep originally inspected data as is.
ensure tutors are on-screen in horizontal mode
Can be done by deriving on-screen-y position on tutor mount, adjusting it to be in-view + showing a notch to point to the on-event position.
Problem: user may inspect some stuff and move on
Leaving the viz dimmed.
Solution: perhaps dim only on peek & highlight on inspect
Problem: dragging scrollbar results in jittery scroll
Solution: Perhaps just switch to a custom/third-party scroll/scrollbar implementation.
Also will be easier to solve to auto-playback stop by detecting custom scroll from the user-issued one.
More
introduce members
perhaps show db
perhaps make it more insteresting than increment a counter
mobile-friendly
Made somewhat mobile-friendly.
maybe add link to github repo
reword round tutor “received” is weird, it’s already there!
Better more like “order determined”.
reword “the hashgraph below”
It refers to all the hashgraphs in viz.
Whereas we need to clarify that it’s done based on the hashgraph a member has.
explain order of received events / middle learned events
see path to highlight only the path, and don’t pollute inspector with path events
explain no leaders
explain spin up private
explain or use public Heder, Consensus as a Sevrice
dynamic poor connectivity
perhaps Shift+click to add to inspected, plain click to set inspected
stop auto-scroll on manual scroll
objectives
understand the algo to see how it can be applied in NG
to make algorithm understandable
things to explain:
members
members connectivity
member’s stake
events
event tx
share stake txshow how without stake it’s possible to overwhelm with puppet-socks membersshow how stake-map affects: round, witness, votes.register on-the-repo txi.e., smart contract / FSM transitiontrigger registered on-the-repo txarbitrary determenistic txin IPVMas SPARQL with oxigraph
event other-parent
event self-parent
forksseesstrongly seesroundwitnessesvotesconcludes votinginfamous witnessfamous witnessunique famous witnessround concludedevent round receivedevent received timelearners eventstheir median onesmedian creation timeevent order by round received + received timecustom CRSevent order by round received + custom CRSby round received + received timeby round received + custom CRSreceives votes
possible further work
switch to garden color data model
add color viz to inspector
make algorithm viz mesmerizing
make interactive learning
in form of a saper game
with progress saved
gets more difficult as you go
leaderboard
in form of achivements
found all data types
found all vote types
shared stake
issued custom tx
played 1000 events
left a comment
discovered all explanations
in form of a MCQ
resistance to inactive members
e.g., remove their stake from acceptance threshold