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)
I think that's what other libraries have done
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].
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
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.
Sorry it has been so long, we've all been pretty busy lately with other things. Keep in mind we are all volunteers (currently)
@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
@scherrey yeah, Brownie is legitimately awesome
@iamdefinitelyahuman added a mainnet interaction tool, you can do testing against mainnet with your contracts!
@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.
@iamdefinitelyahuman Hey Ben, just in case that it may be of some use for this black/isort thing: timothycrosley/isort#694
@sbellem thanks! i have a PR waiting to be merged with new linting rules that will make black compatible with isort - vyperlang/vyper#1964
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?
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
if you see anything in the docs that are missing or unclear to you, feel free to bring them up here!
we added a bounty to help create a means of distributing Vyper where it can be used in dev frameworks and client-side apps with more than 1 version at a time. it's a complex feature, so feel free to reach out for further clarification! https://gitcoin.co/funding/details/?url=https://github.com/vyperlang/vyper/issues/1953&sb=1
- Hi, I have been looking into your bounty on Gitcoin. Before I apply for the bounty, I was wondering if I could get some more clarity as to what you (all) are looking for.
- Can you clarify the two following statements from the post?
- Allow multiple Vyper binaries to play nicely with each other.
- Can use multiple versions of Vyper in any host framework that is supported with this proposal.
- Can you clarify the two following statements from the post?
We want
vyper/vyper-json CLI scripts in a standalone format that can use multiple versions of those standalone binaries at least in Python and Javascript, so someone can compile a project that uses different versions of Vyper entirely client-side (without running a server or anything). This would be similar to how Solidity distributes their solc library on NPM: https://www.npmjs.com/package/solc and as a separate binary: https://github.com/ethereum/solidity/releases
I added a comment with some work that @jacqueswww did a long time ago that could help build something really nice we can use to build and distribute these copies to appropiate places: https://github.com/vyperlang/vyper/issues/1953#issuecomment-631596232
I'd like to refactor that work so it doesn't use a fork of pyodide
