ethereum

ethereum

Member Since 8 years ago

Experience Points
0
follower
Lessons Completed
0
follow
Best Reply Awards
270
repos
Activity
May
20
1 day ago
pull request

cameel merge to ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

open pull request

cameel wants to merge ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

cameel
cameel

I think this wording might be a little clearer to users:

* TypeChecker: Support using library constants in initializers of other constants.
Activity icon
delete
deleted time in 4 hours ago
push

carver push ethereum/ethereum-python-project-template

carver
carver

Show full explanation for pydocstyle failures

carver
carver

Merge pull request #59 from ethereum/pydocstyle-explain

Show full explanation for pydocstyle failures

commit sha: c4f23a432693120df631ec2571dea5b71b9526cc

push time in 4 hours ago
pull request

carver pull request ethereum/ethereum-python-project-template

carver
carver

Show full explanation for pydocstyle failures

Cute Animal Picture

put a cute animal picture link inside the parentheses

Activity icon
issue

carver issue comment ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

Obviously, after the build errors are fixed 😆

Activity icon
issue

carver issue comment ethereum/ethereum-python-project-template

carver
carver

Exclude huge and unnecessary venv*/ from dist

See an example issue here: https://github.com/ethereum/eth-account/issues/150

Cute Animal Picture

put a cute animal picture link inside the parentheses

carver
carver

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

Activity icon
issue

carver issue comment ethereum/ethereum-python-project-template

carver
carver

Exclude huge and unnecessary venv*/ from dist

See an example issue here: https://github.com/ethereum/eth-account/issues/150

Cute Animal Picture

put a cute animal picture link inside the parentheses

carver
carver

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.

open pull request

carver wants to merge ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

Maybe mention the command name here:

Add trin-cli subcommand ``encode-key`` for encoding content keys
open pull request

carver wants to merge ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

Any idea the history here of why it used to be -p trin?

pull request

carver merge to ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

Yup, all looks reasonably to me!

open pull request

carver wants to merge ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

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.

pull request

carver merge to ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

Yup, all looks reasonably to me!

open pull request

cameel wants to merge ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

cameel
cameel

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.

pull request

cameel merge to ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

Activity icon
fork

dev-matthew forked ethereum/ethereum-org-website

⚡ Ethereum.org is a primary online resource for the Ethereum community.
dev-matthew MIT License Updated
fork time in 4 hours ago
open pull request

cameel wants to merge ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

pull request

cameel merge to ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

open pull request

cameel wants to merge ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

cameel
cameel

Can you add the one with libraries too?

pull request

cameel merge to ethereum/solidity

cameel
cameel

Propagate purity information for member access to foreign pure variables

Fixes #12927.

Activity icon
issue

carver issue comment ethereum/trin

carver
carver

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 StructOpt into two commands:
    • json-rpc initiates JSON-RPC requests
    • encode-key encodes content keys
  • Move help descriptions from attributes to doc comments.
  • Define encode-key subcommand 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
carver

@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!

Activity icon
issue

MicahZoltu issue comment ethereum/EIPs

MicahZoltu
MicahZoltu

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.

MicahZoltu
MicahZoltu

Since you are one of the authors, it should auto merge once CI passes. If it doesn't, feel free to mention me.

started
started time in 4 hours ago
Activity icon
issue

Daniel-K-Ivanov issue comment ethereum/EIPs

Daniel-K-Ivanov
Daniel-K-Ivanov

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.

Daniel-K-Ivanov
Daniel-K-Ivanov

@SamWilsn would you auto-merge this PR, thank you 🙏

started
started time in 4 hours ago
push

djrtwo push ethereum/consensus-specs

djrtwo
djrtwo

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 ago
pull request

djrtwo pull request ethereum/consensus-specs

djrtwo
djrtwo

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.

pull request

djrtwo merge to ethereum/consensus-specs

djrtwo
djrtwo

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.