Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 02:48
    wberr opened #10469
  • 02:20
    cameel commented #10446
  • 02:13
    cameel commented #10409
  • 02:12
    cameel commented #10409
  • 01:34
    cameel commented #10429
  • 01:18
    cameel synchronize #10429
  • 01:18

    cameel on fix-and-enable-external-tests

    fixup! Update Gnosis external t… (compare)

  • 00:48
    cameel edited #10465
  • 00:47
    cameel edited #10429
  • 00:45
    cameel edited #10464
  • 00:45
    cameel edited #10464
  • 00:44
    cameel edited #10466
  • 00:43
    cameel commented #10468
  • 00:42
    cameel edited #10468
  • 00:42
    cameel edited #10468
  • 00:42

    cameel on force-latest-truffle-for-ens

    (compare)

  • 00:42

    cameel on run-external-tests-nightly

    Run external tests only nightly… Switch the external tests back … (compare)

  • 00:42
    cameel synchronize #10468
  • 00:42
    cameel synchronize #10466
  • 00:42

    cameel on update-external-tests-for-0.8.0

    Don't run Gnosis external tests… Update to 0.8.0 versions of sol… (compare)

Harikrishnan Mulackal
@hrkrshnn
@cameel Was info about the switch published somewhere?
Gabriele Rigo
@gabririgo
ok @cameel thank you for your help
Kamil Śliwak
@cameel
And the biggest problem with it was really that it's not our domain and we can't really switch it to something else. That's why we're recommending https://solc-bin.ethereum.org instead. It used to point at GH pages too but we've been able to seamlessly switch to S3 so everyone using it didn't even notice anything. If you use it, you will avoid this kinds of problems if we need to switch again.
@hrkrshnn Not really because it was meant to be a seamless change and using the GH pages domain wasn't really ever recommended.
But you have a point, from time to time someone reports this so I guess we should at least post on Twitter or something.
I've been also meaning to put it in solc-bin README. I think I'll do that now.
Franziska Heintel
@franzihei
@cameel I think we're good with the AMA
thanks for posting your answers°
Harikrishnan Mulackal
@hrkrshnn
Maybe @franzihei can tweet about it.
Franziska Heintel
@franzihei
I don't think there's any important question left unanswered. :)
Kamil Śliwak
@cameel
Great!
Franziska Heintel
@franzihei
I can tweet about the solc-bin.ethereum
what is the recommendation exactly?
Kamil Śliwak
@cameel
Basically that we have changed the hosting behind https://solc-bin.ethereum.org and the transition should have been seamless for anyone who has been using it but the files were also available via https://ethereum.github.io/solc-bin/ and anyone using it should switch.
We don't control that domain so we can't do anything about it ourselves. It's serving an older snapshot of the repo, new binaries won't show up there and it does not have the older Linux/Mac/Windows builds we recently started providing.
Franziska Heintel
@franzihei
ok will communicate that just to make sure everybody switches :thumbsup:
Kamil Śliwak
@cameel
Thanks. I'll also update the README, though getting it to show up at https://ethereum.github.io/solc-bin/ will be tricky (would require temporarily removing some files to go below the limit again and get GH pages to update one last time) so the tweet will be very helpful.
Alex Beregszaszi
@axic
@cameel not sure I understood your concern on #10147 ?
Kamil Śliwak
@cameel
My concern is that your change basically ignores m_generateEvmBytecode if necessary.
Alex Beregszaszi
@axic
How come it ignores it?
Kamil Śliwak
@cameel
But that seems to be done only because CLi does not do it at a higher level
ok, sorry, to be precise it skips compileContract(*contract, otherCompilers);, i.e. ignores (disables) the evm bytecode compilation
which used to be the effect of m_generateEvmBytecode.
Alex Beregszaszi
@axic
generateEVMFromIR is the replacement for acompileContract — the whole point of the issue this implements is to change the internal pipeline to IR and compileContract is the only piece which does the old route, but both functions output the same fields
Kamil Śliwak
@cameel
I mean, it's an alternative for it.
You can call one, the other or none of them.
Alex Beregszaszi
@axic
I just don’t see how EVM bytecode generation is skipped in the PR.
Kamil Śliwak
@cameel
Maybe I'll try to explain in a different way. My primary concern is this:
https://github.com/ethereum/solidity/blob/develop/libsolidity/interface/StandardCompiler.cpp#L913
Alex Beregszaszi
@axic
What does that has to do with the IR?
Kamil Śliwak
@cameel
i.e. standard JSON already has code to decide whether to enable evm bytecode compilation or not. and m_generateEvmBytecode was just a dumb flag
Alex Beregszaszi
@axic
I think you may be misreading the diff in the PR because the logic is not changed
Or perhaps you are talking about introducing further clarification which is tangential to the PR?
Kamil Śliwak
@cameel
Let's put it differently: why not do enableEvmBytecodeGeneration(!m_viaIR) in CommandLineInterface.cpp instead?
It would be more in line with what standard JSON does.
Alex Beregszaszi
@axic
The viaIR option is not only for the EVM output, but plenty of others.
It changes the source maps, the gas estimates, etc.
Kamil Śliwak
@cameel
I'm not saying to remove it.
I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.
Alex Beregszaszi
@axic
The original discussion which this PR fixes is #8722 and that proposes the exact thing you are saying, but now I am more on the side with @chriseth that switching the pipeline is a clearer option.

I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.

Because nobody cares about the CLI. We have been asking everyone to move over to the standard json. I consider the non-standard-json options of the CLI for compiler development purposes, and not as production tools.

Kamil Śliwak
@cameel
No, that's not what I mean. I'm not saying that your options should be an output options.
Alex Beregszaszi
@axic
Please read #8722 :)
Kamil Śliwak
@cameel
I've read it already :)
Alex Beregszaszi
@axic
#8722 says to add an output option, —ir-bin.
Kamil Śliwak
@cameel
Yeah. And that's not what I'm saying. I know that your option just changes the pipeline so that the --bin output starts coming from IR.
Alex Beregszaszi
@axic

I'm just wondering why standard JSON enables/disables evm compilation via enableEvmBytecodeGeneration() while CLI goes around it.

I’m not sure what the CLI is doing, but that thing is added to the standard json for speed purposes — to avoid generating that code in the first place. I assume the CLI just filters afterwards, as was the JSON interface doing initially. And the json interface is the one used by most so that is speed critical. Probably someone forgot to update the CLI code.

Kamil Śliwak
@cameel
ok, my bad, I reread what you wrote here and looks like I got it wrong. Sorry.
I mean, I understand what #8722 says and the difference between --ir-bin and your flag. Just for some reason I was interpreting the meaning of m_generateEvmBytecode in different ways in different contexts...
Alex Beregszaszi
@axic

No worries, sorry if I came across as a bit antsy :)

Just knew that it would take forever resolving this via github comments.

Kamil Śliwak
@cameel
Right :)
Leonardo
@leonardoalt
@mijovic ethereum/solidity#10120 and ethereum/solidity#10139 still need to be reviewed though
Đorđe Mijović
@mijovic
@leonardoalt ah, missed them. Will do review. Also, what is state of CHC early return PR?
Alex Beregszaszi
@axic
Every time I try to close some projects or issues, it turns into finding some obscene rabbit hole.