Activity
cameel wants to merge ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
I think this wording might be a little clearer to users:
* TypeChecker: Support using library constants in initializers of other constants.
carver in ethereum/ethereum-python-project-template delete branch pydocstyle-explain
carver push ethereum/ethereum-python-project-template
Show full explanation for pydocstyle failures
Merge pull request #59 from ethereum/pydocstyle-explain
Show full explanation for pydocstyle failures
commit sha： c4f23a432693120df631ec2571dea5b71b9526cc
push time in 4 hours agocarver pull request ethereum/ethereum-python-project-template
Show full explanation for pydocstyle failures
Cute Animal Picture
carver issue comment ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
Obviously, after the build errors are fixed 😆
carver issue comment ethereum/ethereum-python-project-template
Exclude huge and unnecessary venv*/ from dist
Where is the venv/ that needs to be manually deleted? I would have assumed these lines would take care of everything: https://github.com/ethereum/ethereum-python-project-template/blob/b88fcf3c0b70ea7e4bd0fbc89b546a37877ce50e/Makefile#L19-L22
carver issue comment ethereum/ethereum-python-project-template
Exclude huge and unnecessary venv*/ from dist
Maybe that comment belongs in the
cutting-a-release-document?
Yeah, or maybe we could update the Makefile to be sure that old build files are cleaned before every build? Frankly, I was assuming that was the default already.
carver wants to merge ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
Maybe mention the command name here:
Add trin-cli subcommand ``encode-key`` for encoding content keys
carver wants to merge ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
Any idea the history here of why it used to be -p trin?
carver merge to ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
Yup, all looks reasonably to me!
carver wants to merge ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
I often prefer the long-format flags in documentation for readability. Although help is so universal that this one doesn't really bother me. 👍🏻 to whatever you like.
carver merge to ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
Yup, all looks reasonably to me!
cameel wants to merge ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
I think some of the older code is overusing these shortened names. Personally I'd use full words but fair enough, we do have these shortened names in some places.
cameel merge to ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
dev-matthew forked ethereum/ethereum-org-website
dev-matthew/ethereum-org-website
cameel wants to merge ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
Fair enough.
cameel merge to ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
cameel wants to merge ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
Can you add the one with libraries too?
cameel merge to ethereum/solidity
Propagate purity information for member access to foreign pure variables
Fixes #12927.
carver issue comment ethereum/trin
Add encode-content-key command to trin-cli
What was wrong?
We lack a CLI command to encode content keys, which makes it difficult to interact with the network from the CLI if you want to look up content items.
How was it fixed?
- Split up top-level
StructOptinto two commands:-
json-rpcinitiates JSON-RPC requests -
encode-keyencodes content keys
-
- Move help descriptions from attributes to doc comments.
- Define
encode-keysubcommand to encode content keys.- Support encoding for history content types.
- Each content type is its own subcommand under
encode-key.- There is some repetition here, but I think it makes the interface more intuitive.
- Update getting started docs.
- Update existing JSON-RPC commands.
- Add section for encoding content keys.
To-Do
- Add entry to the release notes (may forgo for trivial changes)
- Clean up commit history
@carver do you want to take a look? Given that you seem to have a use case for this utility, I would like to see how well it meets your needs.
A lot of it was just curiosity, and it ended up being pretty straightforward to just generate in python after a quick spec review. But I'm still happy to take a look!
MicahZoltu issue comment ethereum/EIPs
Update EIP4400 based on community feedback
Signed-off-by: Daniel Ivanov [email protected]
Updating the restriction on changing the address of the consumer after transfer based on the following feedback.
Since you are one of the authors, it should auto merge once CI passes. If it doesn't, feel free to mention me.
pettinarip push ethereum/ethereum-org-website
migrate functions to ts
migrate hooks to ts
commit sha： c1a6af484dddc9881dcbb29041540e51d2bc3f49
push time in 4 hours ago
Daniel-K-Ivanov issue comment ethereum/EIPs
Update EIP4400 based on community feedback
Signed-off-by: Daniel Ivanov [email protected]
Updating the restriction on changing the address of the consumer after transfer based on the following feedback.
@SamWilsn would you auto-merge this PR, thank you 🙏
djrtwo push ethereum/consensus-specs
deprecate BeaconBlocksByRange.step (#2856)
- deprecate
BeaconBlocksByRange.step
The step parameter has not seen much implementation in real life
clients which instead opt to request variations on a few epochs at a
time (instead of interleaving single blocks, entire epochs are
interleaved).
At the same time, supporting step on the server side brings several
complications: more complex bounds checking logic, more complex loading
of blocks from linear storage (which presumably stores all blocks and
not just certain increments).
This PR suggests that we deprecate the whole idea. Backwards
compatibility is kept by simply responding with a single block when
step > 0 - this is allowed by the spec and should thus be handled
gracefully by requesting clients already, should there exist any that
use larger step counts.
Removing step now allows simplifying the EL-CL protocol for serving
execution data from the EL to avoid double storage.
- Update specs/phase0/p2p-interface.md
Co-authored-by: Danny Ryan [email protected]
Co-authored-by: Danny Ryan [email protected]
commit sha： 0e6a7cd39a44ba64897c359e1d62c8b475e5d926
push time in 5 hours agodjrtwo pull request ethereum/consensus-specs
deprecate `BeaconBlocksByRange.step`
The step parameter has not seen much implementation in real life
clients which instead opt to request variations on a few epochs at a
time (instead of interleaving single blocks, entire epochs are
interleaved).
At the same time, supporting step on the server side brings several
complications: more complex bounds checking logic, more complex loading
of blocks from linear storage (which presumably stores all blocks and
not just certain increments).
This PR suggests that we deprecate the whole idea. Backwards
compatibility is kept by simply responding with a single block when
step > 1 - this is allowed by the spec and should thus be handled
gracefully by requesting clients already, should there exist any that
use larger step counts.
Removing step now allows simplifying the EL-CL protocol for serving
execution data from the EL to avoid double storage.
djrtwo merge to ethereum/consensus-specs
deprecate `BeaconBlocksByRange.step`
The step parameter has not seen much implementation in real life
clients which instead opt to request variations on a few epochs at a
time (instead of interleaving single blocks, entire epochs are
interleaved).
At the same time, supporting step on the server side brings several
complications: more complex bounds checking logic, more complex loading
of blocks from linear storage (which presumably stores all blocks and
not just certain increments).
This PR suggests that we deprecate the whole idea. Backwards
compatibility is kept by simply responding with a single block when
step > 1 - this is allowed by the spec and should thus be handled
gracefully by requesting clients already, should there exist any that
use larger step counts.
Removing step now allows simplifying the EL-CL protocol for serving
execution data from the EL to avoid double storage.
Propagate purity information for member access to foreign pure variables
Fixes #12927.