Comments (5)
There is an assumption in this OP, and that is that having the information on where the event was called is useful information to begin with. I tend to disagree. If in the event we have information on where an event was emitted, then a consumer of the event will use this information to discriminate between different events.
Personally, I actually think we should remove more functionality from the current event implementation; ie. the Func
field, for the same reason I described. A consumer of the event should not have this information, as it can be used to conditionally handle an event, where really only the event pkgpath, type and attributes should be used to make that work. If I'm reorganizing my realm's code and decide to move a function with a different name, or to also emit the event somewhere else, the consumer application should not break because of this.
In light of this, here's what I think:
- In the short term, to support the feature in Gnoscan, what do you think about having a field like
Line
in the event, which contains a line/column spec likegno.land/r/demo/emitter/package/pkg.gno:89:3
? This way you can point to where the event emission happens in Gnoscan, while having the event data be more obviously debugging information rather than information which should be depended upn. - In the long term, what if it was a feature of the indexer / a specialised sentry node? Especially if we have stacktracing (#2145) available, it is possible for a GnoVM instance executing the transaction to capture the entire call stack of the event, including all parameters to all functions, and create rich information on Gnoscan. I don't think this should be a chain feature; or something that should be stored in the event data (and thus occupy storage bytes)
- Note that if we manage to do this before mainnet, this would likely mean removing the above
Line
field.
- Note that if we manage to do this before mainnet, this would likely mean removing the above
Does this sound like something which could fit your use case?
from gno.
If I understand your proposal correctly @notJoon,
- Have internal data (ie. of an event emission) stored as a log
- Have it available as data if requested through a "getlog" rpc call
- ie. not have it on-chain, but can be communicated to the indexer
This sounds OK to me, but also like a functionality that maybe should be disabled on a node by default.
I'm summoning @zivkovicmilos for a second opinion.
from gno.
I agree with that we shouldn't include too much information in std.Emit
like @thehowl suggested. However, there's also a need for detailed information to advancing the Gnoscan. But, using the line numbers seems impractical as it wouldn't provide enough context and would require complex tasks like drawing call graphs. Also, we cannot retreive enough state/data from a given blocks.
So instead of showing metadata like previous function or realm through the Emit
, what if create a new function like Ethereum's getLog
function to send only logging information via RPC, allowing data exchange with tools like tx-indexer?
In this case, I think we can use Emit
purely for messages, which allows to remove unneccesary metadata while still being able to utilize this information throught the log
. What do you think?
cc @dongwon8247 @jinoosss @r3v4s
from gno.
@zivkovicmilos @thehowl Can you take a look, please?
from gno.
This sounds OK to me, but also like a functionality that maybe should be disabled on a node by default.
I'm summoning @zivkovicmilos for a second opinion.
Yes, you're right. I'll start working on it later based on the results. thank you
from gno.
Related Issues (20)
- uassert/urequire: Wrong message when strings are not the same. HOT 1
- uassert/urequire: Messages from PanicsWithMessage method are inverted HOT 2
- [examples] Improve AVL interface to take in any type of ID HOT 3
- PR Review throttling HOT 1
- [govdao] Make `r/gov/dao` proposals fee-based for non-members
- [chain] Add a more robust e2e node / cluster testing framework
- CI should detect problems in PRs, not after merging HOT 1
- CI: detect outdated docs' examples
- gnofaucet should have docker images/binaries HOT 1
- "Go version autonomy" for important packages used by the keeper, like go/types and go/format
- [ops] Add release flow for `gnofaucet`
- feature request: Ledger hardware wallet support for validator addresses
- Move GnoVM testing logic within pkg/gnolang; separate from `gno test` logic
- [GnoVM] Better error message with `MsgRun` HOT 1
- javascript: getElementById("source") not always available
- change default genesis package creator, and add way to configure it HOT 1
- Validator resolves old IP address after sentry IP change when using FQDN HOT 1
- p/demo/mux: support query strings HOT 1
- integrate p/demo/avl/pager with existing examples
- Discord roles HOT 2
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 gno.