by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 19:59
    chriseth synchronize #9465
  • 19:59

    chriseth on unchecked

    Var is also reserved. (compare)

  • 19:18
    leonardoalt synchronize #9885
  • 19:18

    leonardoalt on smt_array_slices

    Support array slices (compare)

  • 19:17
    leonardoalt review_requested #9885
  • 19:15

    chriseth on develop

    EVMHost: keep precompile balanc… Add more semantic tests for bal… Merge pull request #9887 from e… (compare)

  • 19:15

    chriseth on evmhost

    (compare)

  • 19:15
    chriseth closed #9887
  • 19:14
    leonardoalt commented #9885
  • 19:13
    leonardoalt ready_for_review #9885
  • 19:13
    leonardoalt commented #9885
  • 19:13
    leonardoalt synchronize #9885
  • 19:13

    leonardoalt on smt_array_slices

    Support array slices (compare)

  • 19:11
    chriseth edited #9465
  • 19:11
    chriseth synchronize #9465
  • 19:11

    chriseth on unchecked

    Checked arithmetic by default. Grammar for unchecked. Wrapping arithmetics for Yul IR. and 1 more (compare)

  • 18:53
    lidiia-eld commented #9875
  • 18:42
    chriseth synchronize #9465
  • 18:42

    chriseth on unchecked

    Update existing tests. (compare)

  • 18:35
    axic commented #9888
chriseth
@chriseth
Artefacts should be added manually to the github release page and also to solc-bin (except for the nightlies)
@christianparpart I would like the filesystem and the internal list of sources to stay decoupled. This makes our life so much easier because we do not have to worry about permissions or directory separators
Christian Parpart
@christianparpart
I think the first part can be definitely be done. (just like file read callback), and the fs separator I don't see as a problem when one uses boost(/std) filesystem API. But I think that can all be moved outside libsolidity just like the file reader.
Daniel Kirchner
@ekpyron
@chriseth Since I just happened to read this :-): my plan was actually to have github actions build everything that ends up in the github release page - they can even directly create a draft release page and put the artifacts there automatically.
Christian Parpart
@christianparpart
@ekpyron I actually did that for a private repo a couple of weeks ago. It was a nightmare to get it the way I wanted. But you can automate a lot with that. prereleases pages for nightlys and actual release pages (with associated binaries each). And on the latter you can even say you create the release in draft mode, so that a dev still has to click "publish" manually for a last check. (Github release changelog can also be auto-generated from the Changelog.md)
Daniel Kirchner
@ekpyron
It's already pretty much working in my fork, not that much hassle actually...
Christian Parpart
@christianparpart
nice work then. What's missing?
chriseth
@chriseth
@ekpyron we talked about that, but I don't think it is a good idea to have the test runs in one system and create the release binary (which is then untested) in another
Daniel Kirchner
@ekpyron
Mainly macos builds and static linux builds, but just because I haven't gotten around yet.
chriseth
@chriseth
I would like to have a much more manual process where you can pause any time and run checks if you like
also I think the release pages of github are way too fragile
Daniel Kirchner
@ekpyron
Well, the actions would of course run the tests before adding to the release page...
chriseth
@chriseth
anyone with write permission to the repo can exchange a binary without anyone noticing
Daniel Kirchner
@ekpyron
Well, that will still (and especially) be the case, if one uploads the release binaries there manually... to avoid that we'd rather need to say: no binaries on the release pages at all... but well, we can talk about all that later this week, when I'm officially back and you can catch me up on the current state of things, just wanted to mention this being easily possible.
chriseth
@chriseth
right!
@cameel another thing I remember is that one job pushes binaries for the first commit on the release branch and not for the git tag, which is very annoying (and the source of ethereum/solidity#7512 ) - I think we should also be able to fix this with the manual method
a3d4
@a3d4
Can I execute a syntax test with --error-recovery(or any other) compiler option, or do I need a command line test for that?
Kamil Śliwak
@cameel

There are quite a few moving parts and decisions so I have written down a summary of what we discussed today for my own reference: https://github.com/ethereum/solidity/issues/9258#issuecomment-651220312

@ekpyron This might be of interest to you. Sorry that it's a bit long. I tried to organize and trim it a little but it's still based on a live discussion so not very organized overall.

chriseth
@chriseth
@a3d4 do you need that for an error id?
there are error recovery tests, maybe we should just include them in the scan
Daniel Kirchner
@ekpyron

There are quite a few moving parts and decisions so I have written down a summary of what we discussed today for my own reference: https://github.com/ethereum/solidity/issues/9258#issuecomment-651220312

@ekpyron This might be of interest to you. Sorry that it's a bit long. I tried to organize and trim it a little but it's still based on a live discussion so not very organized overall.

:+1:

chriseth
@chriseth
@cameel updated a detail in the Hosting binaries on IPFS section
Kamil Śliwak
@cameel
@chriseth Thanks. That reminds me that we actually didn't discuss one important detail: what about the GH pages size limit?
chriseth
@chriseth
@cameel that will hopefully be solved by ignoring old nightly builds and replacing them by redirects to ipfs
Kamil Śliwak
@cameel
So we'll be manually deleting old nightlies once the repo fills up (still keeping them in history of course)?
Or should that be automated?
chriseth
@chriseth
no, the jekyll site renderer should do this
gh pages is the result of jekyll running on the gh-pages branch
Kamil Śliwak
@cameel
Ah, I see. So don't delete them, just don't render them?
chriseth
@chriseth
exactly
Kamil Śliwak
@cameel
Sounds good. I'll add it to the summary.
chriseth
@chriseth
one problem we should also check if the .js files are maybe too large for the ipfs gateway...
Kamil Śliwak
@cameel
Right.
Alex Beregszaszi
@axic
The new eth2 testent (altona) uses the solidity deposit contract 🎉
chriseth
@chriseth
nice!
Alex Beregszaszi
@axic
It is verified on goerli.etherscan.io, I tried verifying the Vyper weeks ago but it just never worked.
I’ll try to verify it on source-verify later today, for dogfooding
chriseth
@chriseth
@axic just push the medatata and sources to ipfs - it "should" just work
(depending on how long ago the deployment was)
Alex Beregszaszi
@axic
is it checking goerli?
chriseth
@chriseth
sure
Alex Beregszaszi
@axic
still compiling 0.6.8 as i deleted it
a3d4
@a3d4

@chriseth

do you need that for an error id?

Yes.

there are error recovery tests, maybe we should just include them in the scan

OK, makes sense to add recovery tests to the scan. What about command line tests?

chriseth
@chriseth
@a3d4 yes, add them, too
@leonardoalt is it true that with regards to the information about storage I can gather right after the statement, the following statements are equivalent: sstore(a, b) and b := sload(a)
chriseth
@chriseth
ah, I think literal content currently does not yet work :(
Alex Beregszaszi
@axic
too bad! it has been compiled with that
tried the manual tool:
Could not match on-chain deployed bytecode to recompiled bytecode for: { "deposit_contract.sol": "DepositContract" }
chriseth
@chriseth
ping edi to implement it :)