Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Jacques Wagener
    @jacqueswww
    https://youtu.be/NwSIaNhRHFQ
    Jacques Wagener
    @jacqueswww
    https://www.python.org/dev/peps/pep-0617/
    In 3.9 beta
    Daniel Dias
    @1140251
    image.png
    I'm not very experienced in python, but I tried to install vyper through makefile and the error occurred
    I had to run the - pip3 install . by hand
    Just some guy
    @fubuloubu
    @1140251 do you have Python installed? (pip is included in most Python distros)
    It seems likely that you do not, and that the Makefile failed to find pip to install with
    What OS are you using? Also, have you tried the docker image?
    Richard Moore
    @ricmoo
    Heya! Was wondering if I could get some feedback on ethers-io/ethers.js#816 ? I’m not sure if Vyper output this ABI or if Uniswap modifies it manually afterward?
    Just some guy
    @fubuloubu
    @ricmoo we most likely output that (as of the version UniSwap was compiled with). I don't think the ABI specification dictates that named outputs must be unique for tuples, but we can certainly fix that by ensuring they have unique names
    Indeed, the latest version of Vyper does not give them names at all
    Richard Moore
    @ricmoo
    No names is better than conflicting names. :)
    Thanks. :)
    For now, I'm going to make it so that conflicting names don't throw, but instead make result properties available positionally, but not by kwargs.
    (and log a warning)
    Just some guy
    @fubuloubu
    @ricmoo cool, and if there are no names you will skip making them available via name?
    I think that's what other libraries have done
    Richard Moore
    @ricmoo
    Yeah. They are only available positionally if there is non name. So, I will treat name collisions the same as having no names.
    So, (address foo, uint bar), have result[0] === result.foo and result[1] === result.bar, but (address, uint) and (address out, uint out) only have result[0] and result[1].
    Ben Scherrey
    @scherrey

    Any ideas when the following issues will be merged into a release? They're causing a lot of frustration and code bloat. Having to initialize our large array at declaration time actually doubles the size of our contract! #1676

    Can't use constant 2D arrays in code.
    ethereum/vyper#1915

    Private functions may blow up with parameters in different orders. (we've got this patched in our custom beta17 now)
    ethereum/vyper#1848

    Add zeroing function for array initialization.
    vyperlang/vyper#1676

    @inline private functions decorator.
    vyperlang/vyper#1677

    Just some guy
    @fubuloubu
    @ricmoo sounds good to me!
    @scherrey 2 of them are merged, 1 is WIP for 0.2.0 (@iamdefinitelyahuman is working on this), unsure how @charles-cooper is making out on #1848 but that is a lower priority (not blocking for 0.2.0). Seems like #1677 may depend on some stuff in #1848, I can't comment further.
    The type checking updates are the only thing blocking the new release from coming out, they are a significant breaking change and I want all the breaking changes to make it in together.
    Just some guy
    @fubuloubu
    Some other things to look forward are changing syntax for defining events (similar to structs), emitting events (I think either log MyEvent(...) or log(MyEvent(...))), and yes a lot more consistency around how constants are defined and used
    Sorry it has been so long, we've all been pretty busy lately with other things. Keep in mind we are all volunteers (currently)
    Ben Scherrey
    @scherrey
    @fubuloubu yep understand - was just curious if there was any sense of timeframe based on present progress.
    Just some guy
    @fubuloubu
    I hear if you say nice things about Brownie, type checking might ship faster
    Ben Scherrey
    @scherrey
    haha I haven't tried Brownie yet but it looks really promising.
    arjuna sky kok
    @arjunaskykok_gitlab
    @scherrey Don't forget to try Mamba (https://mamba.black) too. I'll try to add a basic smart contract auditor to Mamba in this year.
    1 reply
    Just some guy
    @fubuloubu
    you mean static analysis tool?
    @scherrey yeah, Brownie is legitimately awesome
    @iamdefinitelyahuman added a mainnet interaction tool, you can do testing against mainnet with your contracts!
    arjuna sky kok
    @arjunaskykok_gitlab
    @fubuloubu sort of. I would explore approaches like formal verification, and machine learning. I need to add some stuff first to Mamba, like GUI support, box (like Truffle box), EPM support, then I would start studying Vyper in depth. Hopefully I have something to show in Q4 of this year.
    Sylvain Bellemare
    @sbellem
    @iamdefinitelyahuman Hey Ben, just in case that it may be of some use for this black/isort thing: timothycrosley/isort#694
    Ben Hauser
    @iamdefinitelyahuman
    @sbellem thanks! i have a PR waiting to be merged with new linting rules that will make black compatible with isort - vyperlang/vyper#1964
    Sylvain Bellemare
    @sbellem
    :+1:
    Timothy O'Reilly
    @crazykid080

    Hi, I'm currently working on learning Vyper and I pulled the sample Prysmaticlabs Contract on etherscan and started to adapt it to the newest version and I ran into and issue:

    vyper.exceptions.StructureException: line 44:16 Cannot call public functions via 'self'
     43
---> 44     log.Deposit(self.get_deposit_root(), deposit_data, self.to_bytes(index))
------------------------^
     45
.......
vyper.exceptions.StructureException: line 44:16 Not a top-level function: get_deposit_root. Did you mean self.get_deposit_root?
     43
---> 44     log.Deposit(get_deposit_root(), deposit_data, self.to_bytes(index))
------------------------^

    Can anyone help me out here?

    Just some guy
    @fubuloubu
    are you using the correct version of Vyper? It was compiled against a hotfix branch of beta.13 maintained especially for the deposit contract: https://github.com/vyperlang/vyper/tree/1761-HOTFIX-v0.1.0-beta.13
    Timothy O'Reilly
    @crazykid080
    I'm adapting it to 0.1.0b17+commit.0671b7b just to help me understand more about the syntax and nuances
    Just some guy
    @fubuloubu
    oh I see, yeah sometime between then and now we disallowed public calls within mutating calls. You should do something like:
    deposit_root: bytes32 = self.get_deposit_root()
log.Deposit(deposit_root, ...)
    Timothy O'Reilly
    @crazykid080
    Hmmm, still getting the same complaint, odd
    Timothy O'Reilly
    @crazykid080
    After taking a break I decided to simply grab the value it needed directly instead of calling the function. That fixes the issue, though I'm not sure if that should be the correct way of going about it
    Timothy O'Reilly
    @crazykid080
    How would I explicitly initialize branch: bytes32[32]? My first assumption would be to create a large array though I assume that isn't the best way to do it
    Just some guy
    @fubuloubu
    @crazykid080 as of Apr 8th, you can use branch: bytes32[32] = empty(bytes32[32])
    vyperlang/vyper#1676
    Timothy O'Reilly
    @crazykid080
    Oh boy, looks like I'll have to wait until the next release then, thanks for the answer though
    Just some guy
    @fubuloubu
    hopefully coming shortly :grimacing: 🤞
    Oli Guei
    @olivrg
    I'm really happy to come across this community. I've been thinking about getting into smart contract development but Solidity's JS-like nature turned me off then I found Vyper. Currently completing the tutorial on the docs. Thank you for the work you do!
    arjuna sky kok
    @arjunaskykok_gitlab
    @olivrg Welcome to the club!