by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jul 07 15:52
    carver commented #1949
  • Jul 07 08:39
    cburgdorf commented #1949
  • Jul 07 08:37
    cburgdorf review_requested #1949
  • Jul 07 08:37
    cburgdorf edited #1949
  • Jul 07 08:37
    cburgdorf edited #1949
  • Jul 07 08:35
    cburgdorf synchronize #1949
  • Jul 07 08:08
    cburgdorf opened #1949
  • Jul 07 08:05

    cburgdorf on master

    Upgrade to latest mypy Tighten type support (compare)

  • Jul 07 08:05
    cburgdorf closed #1948
  • Jul 07 07:59
    cburgdorf synchronize #1948
  • Jul 07 07:45
    cburgdorf synchronize #1948
  • Jul 07 07:35
    cburgdorf synchronize #1948
  • Jul 06 16:25
    cburgdorf review_requested #1948
  • Jul 06 16:24
    cburgdorf edited #1948
  • Jul 06 16:24
    cburgdorf edited #1948
  • Jul 06 16:19
    cburgdorf synchronize #1948
  • Jul 06 15:50
    cburgdorf synchronize #1948
  • Jul 06 15:39
    cburgdorf edited #1948
  • Jul 06 14:21
    cburgdorf edited #1948
  • Jul 06 13:26
    cburgdorf synchronize #1948
Voith Mascarenhas
@voith

I made some bad choices y-day, and ended up with a hangover.

Haha, hope it was good :D

@veox Thank you for your help
I have some free time now and I will dig into the tests just to double check that these tests are in fact incorrect.
irenemae
@irenemae
@cburgdorf hi everyone!!!newbie here:)
Dimitri Saingre
@Prygan
Hi everyone :) does anyone knows here if it is possible to read the leveldb chain data generated by geth from python with py-evm ?
Jason Carver
@carver
I know it's possible to read state data out of the geth leveldb store, but can't natively read out chain data. It would be reasonable to write an adapter, if you're interested in a project :)
Jason Carver
@carver
eth-tester with istanbul support is out: v0.2.0-beta.3 @/all
Noel Maersk
@veox
@voith I'm taking a look at PR #1852, if you don't mind. Not even past the "run successfully locally" step yet: the fixtures take too long, SLOWEST_TESTS is unpopulated with static_Call50000 (and family) for Istanbul, and on some test (don't know the name yet, because I first ran it in tox) it just hangs... Might be GeneralStateTests/stTimeConsuming/CALLBlake2f_MaxRounds.json, will see.
Voith Mascarenhas
@voith
@veox Please feel free to take it over. I won’t be able to look at it before Devcon
Noel Maersk
@veox
(Plus, Python 3.6 (as in PR) is slow IIRC.)
Voith Mascarenhas
@voith
Blake2f implementation in python is not very efficient and its expected to be slow. But need to find out which tests needed to be marked as slow
Noel Maersk
@veox
Yup, that's what I'll be doing first. I'm assuming stTimeConsuming will all be there.
Voith Mascarenhas
@voith
yeah seems reasonable. There’s a test called CALLBlake2f_MaxRounds_d0g0v0_Istanbul which has high possibility of running extremely slow.
Just learnt that the old blake2b library has been replaced by a better performing one:
ethereum/py-evm#1854.
But the tests will still need to be marked slow
Jason Carver
@carver
@veox that faster blake2b implementation is in a newer release of py-evm. I highly recommend upgrading to that as part of the branch
Noel Maersk
@veox
@carver Thanks, didn't notice.
Jason Carver
@carver
:+1:
Noel Maersk
@veox
Test passes, but still takes minutes. Will re-visit SLOWEST_TESTS list later (files have changed names). (94.68s call says CircleCI.)
Voith Mascarenhas
@voith
Yeah, some tests were moved to LegacyTests
Voith Mascarenhas
@voith
@veox Ethereum tests has a new release for istanbul: https://github.com/ethereum/tests/releases/tag/v7.0.0-beta.1
Noel Maersk
@veox
It's the cursed RIPEMD160 precompile again: https://github.com/ethereum/py-evm/issues/1857#issuecomment-538433394
We do try to catch this: https://github.com/ethereum/py-evm/blob/master/eth/vm/forks/spurious_dragon/_utils.py#L46-L50
... but it seems that geth is not as stringent as py-evm on when this should happen. We only do it if computation.is_origin_computation.
Noel Maersk
@veox
Not 100% sure this is the culprit, though - still looking...
Noel Maersk
@veox
Yup, that's it. yield THREE (unconditional) passes the test. So, just need to cherry-pick the conditions, so that other tests don't all fail...
Noel Maersk
@veox

OK, I can't figure out how to do this without a double-pass through the nested computations, or ugly hacks - not today, at least, and got to run anyway.

I liked it more when aleth was filling the tests. :/

Summary of noise: https://github.com/ethereum/py-evm/issues/1857#issuecomment-538460472
Tan
@tanmaster
hi, i kinda feel stupid for asking this, but is there a way to set the code of an address with vm.state.setCode() and then persist it without getting a validation error when mining the block?
Tan
@tanmaster
nevermind, i solved it: i extended the IstanbulVM class and the MiningChain class, overrid mine_block in both and commented out the lines in which the validation happens.
Voith Mascarenhas
@voith
@veox nice work! With my current knowledge it would have taken me ages to figure that out 😅
Noel Maersk
@veox
veox/py-evm@6c6db73 - supposed fix (for 4 of 6 failures).
Noel Maersk
@veox
I'm relatively certain that the branch will now pass all the tests (i.e. fixed the remaining 2).
Noel Maersk
@veox
@voith and all: should I submit the fixes as a PR for PR #1852, or roll a new PR including everything?..
Y'all' be at devcon, so there won't be anyone to review/merge it anyway...
Voith Mascarenhas
@voith
@veox do anything that is convenient for you. I have no problem closing the PR that I've opened.
Jason Carver
@carver
Yeah, I'm not checking github notifications regularly, but if you @ mention me in here, I'll get to it soon-ish @veox
Chris Calderon
@SerpentChris
Tried install py-evm on PPC64 Linux today and it failed :( . One of the dependencies, blake2b-py fails to build because it's dependency, marturin, fails to build because it's rust dependency ring v0.16.9, fails to build.
Chris Calderon
@SerpentChris
Is there some reason blake2b-py is used instead of the blake functions in hashlib? They are standard starting with python version 3.6
Chris Calderon
@SerpentChris
OH, it looks like you switched to this module because it is "560x" faster about 21 days ago.
Chris Calderon
@SerpentChris
For now I think I can just checkout the commit before the merge. Unrelatedly, there is another problem that stops me from being able to easily use py-evm on PPC64 big endian Linux, which is that the pyethash version this depend on seems to have a problem compiling on big endian platforms. This issue was fixed in the pyethash repo but I don't think that fix was put onto pypi, so the version pip tries to install fails.
Chris Calderon
@SerpentChris
I've made an issue with ring, so maybe they can fix the build failure.
Jason Carver
@carver

For now I think I can just checkout the commit before the merge.

Yup, this is a reasonable solution for now. It is possible to make the blake2b-py install optional and maintain the pure python implementation as a backup. It's probably not top priority for us, but if you open an issue or want to work on it yourself I'm happy to guide on the necessary steps.

the pyethash version this depend on seems to have a problem compiling on big endian platforms. This issue was fixed in the pyethash repo but I don't think that fix was put onto pypi, so the version pip tries to install fails.

Can you link to the issue or the fix in the repo? I can push out a release, just want to make sure I understand the change you need so I can verify it's working, before release.

@SerpentChris
Chris Calderon
@SerpentChris
ethereum/ethash@4c0822a
On my big endian system, when I recently tried to install ethash via pip it complained about the issue that was fixed by this commit.
Chris Calderon
@SerpentChris
I think I found the issue? PyPI has an ehtash package and a pyethash package. The ethash package installs fine but py-evm tries to install the pyethash package which is broken.
Honestly I'm a bit confused here. These packages are all on PyPI: ethash, pyethash, and eth-hash.
Bryant Eisenbach
@fubuloubu
was there any change in how selfdestruct is being handled for Istanbul?
IIRC there was not, but we are experiencing some issues: ethereum/vyper#1657