Skip to content
This repository has been archived by the owner on Feb 26, 2024. It is now read-only.

Cannot add compilation to ProjectDecoder instance #5602

Closed
cliffoo opened this issue Oct 6, 2022 · 4 comments
Closed

Cannot add compilation to ProjectDecoder instance #5602

cliffoo opened this issue Oct 6, 2022 · 4 comments

Comments

@cliffoo
Copy link
Contributor

cliffoo commented Oct 6, 2022

Current workaround is to re-instantiate when new compilations come. It would be nice if I can keep feeding that one instance.

truffle -v
5.6.0
@haltman-at
Copy link
Contributor

Question, which of the three decoder classes is this referring to? Just the ProjectDecoder? All of them?

@cliffoo cliffoo changed the title Cannot add compilation to decoder instance Cannot add compilation to ProjectDecoder instance Oct 14, 2022
@cliffoo
Copy link
Contributor Author

cliffoo commented Oct 14, 2022

Yea only ProjectDecoder for this one. I don't know if the same need will arise for contract and contract instance decoders; if they do I guess I'll open issues separately.

@haltman-at
Copy link
Contributor

OK cool, if it's just ProjectDecoder I don't think this should be too hard.

cliffoo pushed a commit that referenced this issue Oct 15, 2022
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.
cliffoo pushed a commit that referenced this issue Oct 16, 2022
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.
 * Edit: Instead of the decoder staying in state, keep it in a ref. Let something else
   trigger rerender.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.
cliffoo pushed a commit that referenced this issue Oct 28, 2022
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.
 * Edit: Instead of the decoder staying in state, keep it in a ref. Let something else
   trigger rerender.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.
cliffoo pushed a commit that referenced this issue Nov 15, 2022
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.
 * Edit: Instead of the decoder staying in state, keep it in a ref. Let something else
   trigger rerender.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.
@dongmingh
Copy link
Contributor

Close the issue since this is fixed in Truffle v5.6.6.

cliffoo pushed a commit that referenced this issue Nov 17, 2022
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.
 * Edit: Instead of the decoder staying in state, keep it in a ref. Let something else
   trigger rerender.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.
cliffoo added a commit that referenced this issue Nov 18, 2022
* bus-client: Connect before publish

The client instance in events/defaultSubscribers/dashboard
isn't actually firing anything at the moment. This is fix.

* dashboard: WorkflowCompileResult message
- Create message
- Fire it from events and catch it in subscriber in frontend

* dashboard: Add @truffle/decoder dep

* dashboard: Add @truffle/codec dep

* dashboard: Add object-inspect deps

* dashboard: Fix bad `tsx` file extension

* dashboard: Add @truffle/compile-common dep

* dashboard: Fix naming mistake

* dashboard: Update @truffle/ deps

* dashboard: Add object-hash deps

* dashboard: Add idb dep

* dashboard: Simplify bus client init logic

* dashboard: State improvements
- Better name for message bus client.
- Remove host and port info.

* dashboard: Extract bus client init logic into its own function

* dashboard: IndexedDB setup
Init with schema and keep in state

* dashboard: Migrate from react-scripts to webpack + babel
Moving away from react-scripts@5 is necessary for decoder integration

* dashboard: Add to and organize existing dev server scripts
For some reason webpack cli cannot `webpack serve` even though webpack-dev-server
is installed. The workaround is to serve programmatically.

* dashboard: Webpack build directly into destination during `build` command
No need to copy

* dashboard: Remove cpy-cli devDep

* dashboard: Add polyfills necessary for web3

* dashboard: Add eslint devDep

* dashboard: Add eslint-webpack-plugin devDep

* dashboard: Configure eslint webpack plugin

* dashboard: Upgrade truffle namespace deps to latest

* dashboard: Remove unnecessary nested build directory level

* dashboard: Some webpack config for niceness

* dashboard: Decoder setup
Init with persisted compilations and keep in state

* dashboard: Upgrade concurrently devDep

* dashboard: Use concurrently programmatically to start dev servers

* dashboard: Webpack log progress

* dashboard: Use only message lifecycle to handle message
No need to pass provider around

* dashboard: Handle WorkflowCompileResultMessage (partial impl.)
Keep track of compilations
 - Best effort: Check uniqueness using sha1; I haven't verified that it always works.
Re-init decoder when new compilations come
 - This will change when #5602 is resolved,
   so decoder is only initialized once. Warning: That way we are mutating state, which is
   forbidden, but it saves memory. I will experiment, my hope is that since it doesn't
   directly touch the dom it's OK.
 * Edit: Instead of the decoder staying in state, keep it in a ref. Let something else
   trigger rerender.

This is partial because nothing makes it to db yet.

Also slightly reworked how reducer returns new state when handling bus messages. It's easier to follow now.

* dashboard: Init decoder before bus client
It'd be bad if WorkflowCompileResultMessage comes in before decoder is initialized

* dashboard: Decode and render in `<RPC />`

* dashboard: Remove decoding from `<RPC />` state
There is no reference to it. This will be added back when codec components come.

* dashboard: Fix initDecoder bad logic
Should set at index, not push to compilations array

* dashboard: Handle WorkflowCompileResultMessage (finished impl.)
Persist to and prune compilations from db.

* dashboard: Remove unnecessary label

* dashboard: Move log and debug message handling outside of reducer

* dashboard: Tighten SetDecoderAction data property type

* dashboard: Add terser-webpack-plugin devDep

* dashboard: Properly mute console via webpack
Remove ce6265f hack

* dashboard: Update comment on batch insert optimization
With batch insert, the write to idb is a larger transaction and has more gotchas.
A large atomic transaction means it'd be bad if one small thing goes wrong and
the rest of the write fails with it.

It gets more complicated when dashboard runs in multiple contexts (e.g. >1 tabs).
You'd want to pick one context to do the work. This picking process involves using
BroadcastChannel to determine which context.

I think this should stay simple.

* dashboard: Wrap db insert in try-catch

* dashboard: Webpack only minimize for build
Dev server recompile cannot afford to minimize, takes too long.

* dashboard: Add warning sign when decoding fails.

* dashboard: Change labels

* dashboard: Move eth_signTransaction to array of unsupported methods
eth_signTransaction isn't supported by MetaMask

* dashboard: Only try to decode for eth_sendTransaction

* dashboard: Better `<RPC />` decoding-related logic and display

* dashboard: Use icon when showing decode fail

* dashboard: Notification when transaction decoding fails / recovers

* dashboard: Fix idb import

* dashboard: Decoder use `window.ethereum`

* dashboard: Confirm provider messages using `window.ethereum`

* dashboard: Remove unused provider from state and remove references to it

* dashboard: Remove unnecessary async/await

* dashboard: Remove unnecessary @ts-ignore comment

* dashboard: Prevent prism from crashing when decoding isn't ready

* dashboard: Support decoding personal_sign requests
Also extract decoding logic and notifications into utils.

* dashboard: Remove unnecessary variable to indicate `<Details />` view

* dashboard: Tighten prop type for inspected decoding

* dashboard: Change code highlight language depending on request method
Also extract:
- `<DecodedParams />` and `<RawParams />` out of `<Expanded />`
- Some prism styles into `<Global />`

* dashboard: Nest some styles in `<Global />`

* dashboard: Change some variable / type names from upper to camel / pascal case

* dashboard: Minor fix mute error regex pattern

* dashboard: Add missing Buffer import

* dashboard: Support decoding eth_signTypedData_v3 + eth_signTypedData_v4
Organized notifications

* dashboard: Fix code highlight for decoded typed data

* dashboard: Use latest @truffle deps

* dashboard: Stdin accept ^C to stop dev servers

* dashboard: Hide decode notification in effect clean-up

* dashboard: Move hide notification logic into its own effect
Otherwise when the decoder recovers, the success notification won't show

* dashboard: Add missing dependency in `<RPC />` effects

* workflow-compile: Wait for "compile:succeed" event handlers

* dashboard: Webpack config use `nosources-source-map`
Align with truffle build source map config

* dashboard: Switch babel-loader out for ts-loader

* dashboard: Remove unused babel deps and config
The remaining @babel/* deps are required by eslint-config-react-app

* dashboard: Generalize WorkflowCompileResultMessage to be CliEventMessage

* bus-common: Remove package.json empty dependencies field

* dashboard: Remove \.jsx? check in webpack config

* dashboard: Update some deps

* dashboard: Change @truffle/compile-common to be devDep

* dashboard: Pass around decoding object
Instead of the resulting string from inspect

* bus-common: Improve CliEventMessage type
Default to unknown payload data type

* dashboard: Update to latest @truffle deps

* dashboard: Create and use Decoding type

* dashboard: Extract getHighlightLanguageForRpcMethod

* bus-common: Add generic to isCliEventMessage

* bus-common: Remove CliEventMessage default generic param
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants