Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 10:57
    cameel commented #8190
  • 10:55
    chriseth closed #7661
  • 10:55
    cameel commented #8190
  • 10:41
    erak opened #8194
  • 10:40
    erak commented #8190
  • 10:40

    erak on json-ast-extract-fix

    Removes the binary option from … (compare)

  • 10:30
    cameel commented #8190
  • 09:30
    chriseth opened #8193
  • 09:29

    chriseth on develop

    Polish changelog for 0.6.2. Merge pull request #8192 from e… (compare)

  • 09:29

    chriseth on polishChangelog

    (compare)

  • 09:29
    chriseth closed #8192
  • 09:13
    cameel synchronize #8164
  • 08:41
    chriseth opened #8192
  • 08:41

    chriseth on polishChangelog

    Polish changelog for 0.6.2. (compare)

  • 08:40

    chriseth on polishChangelog

    Polish changelog for 0.6.2. (compare)

  • 08:34
    chriseth synchronize #8168
  • 08:34
    chriseth closed #8168
  • 08:33

    chriseth on develop

    Fix Gentoo overlay link text (compare)

  • 08:30

    chriseth on makeYulExampleCompilable

    (compare)

  • 08:30

    chriseth on develop

    Make yul example compilable. Merge pull request #8189 from e… (compare)

chriseth
@chriseth
@Marenz can you check again?
added the tests.
Mathias L. Baumann
@Marenz
ok
Mathias L. Baumann
@Marenz
pushed my fixes
chriseth
@chriseth
thanks!
rebased?
Mathias L. Baumann
@Marenz
on latest develop?
chriseth
@chriseth
I don't see your fixes
Mathias L. Baumann
@Marenz
hu. true. checking..
ha, I rebased and forgot to push after that
chriseth
@chriseth
Nice, thanks a lot! Now let's hope that all tests are green
Nicolás Venturo
@nventuro
hey @chriseth! saw your message about a request for a call, and only now realized it might be easier to coordinate here. tomorrow i'll be available all day, and next week i'm pretty much always available except during the 14.30-16.30 UTC window, so just send an invite at your convenience
chriseth
@chriseth
@nventuro what about 14.30 UTC on Monday?
Nicolás Venturo
@nventuro
I can't make at 14.30, Monday could be either 13.30 or 17.00 UTC (or later)
Leonardo
@leonardoalt
ethereum/solidity#8178
This will need to be taken over (or wait 1 week until I'm back)
Philippe Castonguay
@PhABC
Is there no way to perform try contract_address.call(data) ....? Compiler complains that Try can only be used to external calls. Is there another way to elegantly return the error reason, if any, from the called contract?
realisation
@realisation
Hi everyone - I was hoping someone could comment on this issue for me: ethereum/solidity#2469
It's about dynamic libraries, as in reading the library address from storage then invoking it as a library rather than a contract
thereby saving the gas fee associated with delegate call
Is there any way to do that? Is that possible with Assembly?
chriseth
@chriseth
@PhABC .call returns the returndata as second value - the only problem is that you have to decode it. Is that what you are talking about?
@realisation what do you mean by "saving the gas fee"?
Starting the release unless there are objections.
@nventuro would 1400 utc work?
chriseth
@chriseth
please review: ethereum/solidity#8192
Erik K
@erak

Starting the release unless there are objections.

@chriseth Sounds good!

please review: ethereum/solidity#8192

Approved :)

Erik K
@erak
@chriseth Did you see ethereum/solidity#8190 ? I'm wondering if we need to read those files in binary mode at all? Maybe we could just remove b and keep the encoding?
chriseth
@chriseth
I did not see it. Can you try to fix it, please?
Kamil Śliwak
@cameel

@erak I think it will work fine unless there are any non-utf-8 files in the repo (I doubt it and you'll notice it when it fails) and as long as no code specifically needs to work on individual bytes rather than whole unicode characters (which may be encoded using multiple bytes). I think it's unlikely since that would be very low level and these scripts seem to do only very light text processing.

But just removing the encoding parameter in this particular call seems to work too. Looks like any functions it passes the file content to can deal with both bytes and str just fine. That makes sense since in Python 2 this code was working with str which is the equivalent to what is now bytes (the equivalent of the current str in the old Python was called unicode). So it used to process it byte by byte rather than by whole unicode characters and it didn't matter.

chriseth
@chriseth
I think there is a non-ascii file somewhere, otherwise the tests on windows wouldn't have failed
Kamil Śliwak
@cameel
Oh, right. In that case these would need to be decoded differently (encoding='cp1250' or some similar code page) and you would need to know which one is which on a case-by-case basis. Well, that might be the reason why it was using binary mode.
chriseth
@chriseth
we might also change the file instead :)
Erik K
@erak
@chriseth Do you remember which one it was?
Kamil Śliwak
@cameel
Is the dev call starting right now or is it the one that has been moved to 14:00 UTC (15:00 CET)?
Kamil Śliwak
@cameel
ok :)
Erik K
@erak
@cameel Ah, I think we need to check the extraction again. Does not work without binary mode: https://ci.appveyor.com/project/ethereum-free/solidity/builds/30375440
chriseth
@chriseth
@christianparpart (and everyone else) - can we start the wednesday meeting at 14.00?
Kamil Śliwak
@cameel

@erak It seems to break on something completely unrelated though. The bytecode comparison fails on Windows... I guess this could be caused by a file using the Windows encoding which used to just pass through and now is being (incorrectly) interpreted as utf-8? And parts of it are being used in the compiled code? That's just speculation on my part, I don't know enough about it to be sure but it would confirm what @chriseth said.

In that case I think you should leave it in binary mode and remove the encoding parameter. That should give you exactly the same thing the code was doing in Python 2.

@chriseth fine for me.
Erik K
@erak
Ok, so we could try to remove the encoding again, keep the binary mode and change the file in question?
Kamil Śliwak
@cameel
I don't think you'll need to change the input file if you keep the binary mode.
I actually ran the script on my machine earlier with encoding removed and it finished without errors.
chriseth
@chriseth
By the way, what I like about 0.6.2 is that it has many user-facing changes. We should keep it like that!
Kamil Śliwak
@cameel

@erak Some clarification about the binary mode vs encoding parameter:

Adding the encoding to all the open() calls made them do a bit more than they were doing in Python 2. Now they convert the data they read to Python's abstract Unicode representation. That's safer and nicer on one hand because now you don't have to worry about the fact that one character might be longer than a byte. The current code working with strings byte-by-byte could be doing something wrong with multi-byte characters and it wouldn't be easy to notice unless you tested it extensively with such input. On the other hand, to use this abstract representation you need to assume the encoding and if you get it wrong, it may throw UnicodeDecodeError during conversion, or worse, mangle the data silently (as it probably happened in the failing Windows build). UTF-8 is the best choice most of the time but some older encodings are still not dead on some systems :) If there are files in non-UTF-8 encodings in the repo, the first thing I would suggest would be to convert them to UTF-8. But if their purpose is specifically to test the compiler with other encodings, that might not be possible. Then either make them a special case (ugly) or keep the binary mode (potentially less safe, but at least not worse than it already was before).

Erik K
@erak
@cameel Thanks a lot for this extensive explanation!
Kamil Śliwak
@cameel
No problem :) I worked in Python a lot so I'm glad to help if you stumble into any other puzzling cases like this :)
Kamil Śliwak
@cameel
I have a question about Yul code. Is there any utility that can clone the whole syntax tree given a yul::Block?
All I've seen so far are optimizer steps based on ASTCopier but that's not quite what I need. E.g. even the base class changes some identifiers and what I need is an exact copy.
I could roll my own but I bet someone has already implemented something like that.
It would come in handy for my Program implementation. Instead of parsing the source every time I need to compute fitness, I could just keep one base instance of Program, and only make a copy when I need to apply optimization steps to it.