Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 15:13
    pcaversaccio commented #3114
  • 15:12
    pcaversaccio commented #3114
  • 15:09
    pcaversaccio commented #3114
  • 14:41
    pcaversaccio edited #3116
  • 11:06
    pcaversaccio edited #3116
  • 11:06
    pcaversaccio edited #3116
  • 11:05
    pcaversaccio edited #3116
  • 11:04
    pcaversaccio opened #3116
  • Oct 03 14:50
    tserg synchronize #3112
  • Oct 03 12:53
    benber86 edited #3115
  • Oct 03 12:53
    benber86 opened #3115
  • Oct 03 10:41
    tserg synchronize #3112
  • Oct 03 03:44
    z80dev commented #2994
  • Oct 03 03:44
    z80dev commented #2994
  • Oct 03 03:43
    z80dev commented #2994
  • Oct 03 00:29
    zcor opened #3114
  • Oct 02 17:58
    tserg synchronize #3112
  • Oct 02 17:54
    tserg synchronize #3112
  • Sep 30 18:41
    charles-cooper labeled #3070
  • Sep 30 18:41
    charles-cooper labeled #3070
El De-dog-lo
@fubuloubu
I think adding else pass implicitly is okay from a static analysis perspective
And assuming return [void] (you can call return without any type to output) when no return exists in the function is also pretty okay
The observation that we handle some of these cases slightly differently is good feedback to take note of. I am with you on that point
Eth-Gitter-Bridge
@Eth-Gitter-Bridge

[Vitalik Buterin] > (allowing mixed type lists would result in a dynamically typed language because you can't determine the list types at compile time)

In the [1, 2.0, 3] case, what should happen is it gets auto-casted to [1.0, 2.0, 3.0]

[Vitalik Buterin] ah I guess now it doesn't even compile
[Vitalik Buterin] > Now correct me if I'm wrong here but does this mean vyper is not Turing complete?
[Vitalik Buterin] vyper is decidable, not turing complete
Charles Cooper
@charles-cooper
@Eth-Gitter-Bridge Thanks for helping clear those up!
Charles Cooper
@charles-cooper

@fubuloubu how do you feel about forcing each branch of an if statement to have the same effect type? Take for instance the following example

def foo (x: num) : 
    if x < 2 : 
        x = 2 # modifies locally scoped variable, call it the 'locally scoped mutation effect'
    elif x < 10 : 
        self.balances[self.owner] = x # modifies contract state, call it the 'contract mutation effect'
    elif x < 15 : 
        return 1 # exits the function, call it the 'control flow effect'
    else : 
        raw_call(stuff) # calls to external address, call it the 'external call effect'
    return 0

Each branch has fundamentally different properties which you might want to segregate. If you forced each branch to have the same kind of effect, it might be easier to perform certain kinds of analysis on these blocks.

El De-dog-lo
@fubuloubu
How would you even programmatically enforce That?
Interesting idea, but along with the forcing both branches thing I think it's a little unintuitive to work like that
Although it's definitely worth considering because it also helps with auditing friendliness (at the detriment of programmer friendliness)
Charles Cooper
@charles-cooper
Well the devil's in the details but basically you assign different kinds of statements different types (aka effects) and then let the type checker sort it out
Michael Sproul
@michaelsproul
Hi all, I've written a Vyper contract which takes an argument of type decimal in its constructor, but I can't work out how the heck to pass a literal using web3.py. I've unsuccessfully tried literals of the form: 0.2, 0, "0", "0x0", 1/2... Is this not yet possible? (I found this: ethereum/EIPs#598)
(I've also tried Python's Decimal type, with no luck)
El De-dog-lo
@fubuloubu
That sounds more like a bug with web3.py then Vyper
Solidity doesn't have a working decimal type yet I don't think, so that might be why web3 doesn't implement it properly
P.S. Technically our biweekly call is in 7 mins, but I say we push that until tomorrow or Wednesday lol
Michael Sproul
@michaelsproul
Yeah, I think it's a case of the ABI for "decimal" not being set in stone. As far as I can tell, pyethereum is the only client that implements support for it, and Vyper depends on that for testing? I've posted a comment on ethereum/EIPs#598
El De-dog-lo
@fubuloubu
Ah yeah, that totally makes sense. I was looking into porting pyrthereum to web3.py, probably would've ran into that issue as I got in the weeds
william bright
@whb07
sooo errmmm ummm... guess i'll help out with guide to install viper?
im going to see if we can make it nice and neat. anyone got any suggestions on what they want to see?
i'll be destroying and spinning up ubuntu/deebian servers like no other :)
El De-dog-lo
@fubuloubu
Sounds great! Make it so!
James Ray
@jamesray1
Jacques
@jacqueswww
@here this channel will be archived soon. Please continue discussions in : https://gitter.im/ethereum/vyper
:) :snake:
James Ray
@jamesray1
:grinning: :thumbsup:
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Jarrad Hope 侯家睿] Hey guys I was wondering what peoples time estimations for Vyper beta would be? ie should we start pushing it as the language to use?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] my personal preference is we get a spec freeze ASAP (ie. days), get remaining stuff coded up (as far as I can tell, basically the extra restrictions I mentioned in the gitter channel) and then aim for audit-readiness
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Jarrad Hope 侯家睿] okay sweet
Denis Bogdanas
@denis-bogdanas
Hi guys, I'm Denis Bogdanas. Currently I'm maintaining the Viper semantics in K.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[David Knott] It converts data types uint256 => int128
Denis Bogdanas
@denis-bogdanas
In other words function receives an argument of type uint256, but internally it is treated as int128? Is there any other place when such casting is allowed?
Denis Bogdanas
@denis-bogdanas
Or to put it differently: Why casting is done inside a parameter declaration, instead of function body?
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Vitalik Buterin] because uint256 is not a vyper type
[Vitalik Buterin] the type1(type2) syntax exists solely to interpret solidity-specific types
Holger Drewes
@holgerd77
@denis-bogdanas Short reminder: this channel has been moved to https://gitter.im/ethereum/vyper due to the viper->vyper renaming.
Denis Bogdanas
@denis-bogdanas
Ok, thanks for answer and reminder. Didn't know channel was moved.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[Hudson Jameson] Since the channel has moved to Gitter I am closing the Skype -> Gitter bridge. Most people are moving away from Skype so we will not be re-opening the bridge.
Jacques
@jacqueswww
Thanks for hosting it :smile_cat:
Jacques
@jacqueswww
Notice for all that this channel isn't followed anymore, please navigate to: https://gitter.im/ethereum/vyper
Jackgreen66
@Jackgreen66
Ok