Comments (14)
Time to write our own graph layout library? ;)
from plutus.
I generally agree and I think that for contracts the actual value of an output is maybe not important enough to justify the screen space that we are currently using to display it. My favoured visualisation at the moment looks like the graphs in #428 which make it easy to track what is happening at specific addresses.
Not sure if we can - our transaction model doesn't support that kind of metadata.
We could change the emulator to return printf output for successful transactions as well, not just for failed ones. Then we could use the traces to change the graph, for example only showing outputs that contain a keyword, or give a group of outputs a special colour.
from plutus.
The graphs in #428 make sense, but I think, the first step would be a description of how we would layout an arbitrary UTxO graph, to see how complicated it will be to implement a layout algorithm for it. Could you have a go at that @j-mueller?
from plutus.
@j-mueller wrote,
We could change the emulator to return printf output for successful transactions as well, not just for failed ones. Then we could use the traces to change the graph, for example only showing outputs that contain a keyword, or give a group of outputs a special colour.
Yes, I definitely like that idea.
from plutus.
Could you have a go at that @j-mueller?
Yes I'll think about it
from plutus.
to see how complicated it will be to implement a layout algorithm for it
Have you seen this: https://charticulator.com/? They use a constraint solver (Z3) to render the layouts.
I was playing around with rendering bar charts etc. using Z3 over Christmas and it works quite well. The nice thing about this is that you don't need a new layout algorithm for a new type of chart. You just say "the distance between these two things should be the greater than X" and so on.
I think we could use that approach as well, there is a Z3 binary available in webassembly. We only need to worry about specific algorithms if it turns out to be too slow.
from plutus.
Huh, I've wrestled with graph layouts before, but this is the first time I've seen the constraint-solver approach!
Worth noting as well that we're laying out a DAG, not a general graph. And we also potentially want to try and line up transactions in the same slot.
from plutus.
And we might be able to get away with doing most of the layout on the server, in which case we don't need Z3 on the client.
from plutus.
Yeah I never thought of it before reading the Charticulator paper but it's a really great idea. You can align things in the constraint solver easily by using the same variable in different places.
I'll work out an example for the UTXO graph later when I'm done with the tutorial. But the data structure I used looked like this:
data Glyph a =
Rectangle { x :: a, y :: a, width :: a, height :: a }
| Line { from :: (a, a), to :: (a, a) }
-- | etc.
data Region a = Region { left :: a, right :: a, top :: a, bottom :: a }
render :: MyData -> Region Z3Var -> ([Z3Constraint], [Glyph Z3Var])
then you render
all the items, collect the constraints, solve them, and run something like lookup :: Z3Model -> Z3Var -> Maybe Double
on all the coordinates. Then you just need to render the Glyph Double
s into the DOM.
You can divide the layout into smaller pieces with
-- split a region horizontally (creating two columns)
splitH :: Region Z3Var -> ([Z3Constraint], (Region Z3Var, Region Z3Var))
and so forth.
from plutus.
https://hackage.haskell.org/package/lp-diagrams
from plutus.
@j-mueller Have you had a look at it? Is it any good?
from plutus.
And we might be able to get away with doing most of the layout on the server, in which case we don't need Z3 on the client.
Well, there is a trade off here. On the one hand, doing the layout on the server keeps the complexity in the backend code. On the other hand, layout is sensitive to the available view area. In other words, we could do a better job with the layout if it was adapting to the size and shape of the browser window — that's what a nice UI would do.
from plutus.
@krisajenkins What are we going to do with this ticket? We decided to do some work on the visualisation by the summit, and then, revisit after the Summit. I think, we did everything for the former. Should we have a new ticket for the latter?
from plutus.
It is much better now! Let's use new tickets for more stuff.
from plutus.
Related Issues (20)
- Translation relation and decision procedure for UPLC CaseReduce
- Translation relation and decision procedure for UPLC CSE
- Translation relation and decision procedure for UPLC FloatDelay
- Translation relation and decision procedure for UPLC Inline
- Add budget for steppable-cek conformance
- Improve the documentation of Agda files involving Algorithmic part 1
- Agda Translation Relation and Decision Procedure for UPLC ForceDelay phase
- [Epic] Generate `Arbitrary` `BuiltinMeaning`s
- How should we prioritize what to work on? HOT 5
- Exponentiation primop HOT 1
- Optimize division-related Integer operations HOT 1
- Implementation of RIPEMD-160 for Plutus Core
- Add `ripemd_160` to the Plutus Core specification
- Reduce duplication in PlutusLedgerApi
- Propagate semantics variants into Plinth builtins HOT 2
- Fix metatheory/test2 HOT 2
- Suggestion for ScriptContext changes in PlutusV4 HOT 3
- TrackCosts are retained more than expected for Darwin-x86-64 HOT 1
- Support accessing fields by index from BI.BuiltinList
- Minting with PlutusV3 seems to be broken
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from plutus.