https://blog.ethereum.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/

https://medium.com/@mykelp/introducing-polaris-ced195dd798e

pretty interesting price feed for tokens that uses uniswap prices and prevents manipulation by not taking the current price but a median of checkpoints. we should check it out for payroll

cc @sohkai @facuspagnuolo @lkngtn @bingen

it is live actually: https://github.com/marbleprotocol/polaris

https://github.com/ethereum/EIPs/pull/1884

SLOAD might go from 200 to 800 gas (not ridiculous, but a 4x)

Hey guys, I need some Solidity expertise advice. I want to avoid this if:
https://github.com/aragon/aragon-court/blob/getLastPresent/contracts/lib/HexSumTree.sol#L196

• because it makes the code more expensive (even if it’s just an if)
• because past value never changes once the initial function is called, so it’s the same for every iteration of the loop and every recursion step
• because for the case sortition (where I have the same problem) adding this param makes me hit the stack too deep error
• beacuse it makes the code uglier
  First idea I had is to just copy the whole function changing only that line, but this sucks of course (too much repeated code)
  As far as I know there’s nothing similar in solidity to passing functions as parameters or dependency injection or any other fancy technique.
  I also thought of overloading the function get, but it comes from Checkpointing and there is no Library inheritance either.
  Any ideas?

IMO it is okey as it is, definitely cleaner than copying the entire function as in _sortition and _sortitionLastPresent

if this ends up being limited to just the current term (as I think we should do), then we could remove the option of doing it in the past all together and just allow linear searches

yes, that _sortition duplication is temporary, it was a quik work around for stack too deep issue, and I was waiting as you said to see if we really need both options or stick to just one

yes, that _sortition duplication is temporary, it was a quick work around for stack too deep issue, and I was waiting as you said to see if we really need both options or stick to just one

Is truffle supposed to compile dependencies? If so, why? security? 😕
(trying to update truffle to v5 which uses solc-js v0.5 and the compilation fails)

Moving to truffle@5 is going to be a longer process across the entire development pipeline

@danielconstantin Moving to truffle@5 is going to be a longer process across the entire development pipeline

I imagine we could start doing it for the boilerplates though

You should also be able to specify the solc version (it will have to be 0.4.24) in the truffle config

This is super cool: https://github.com/cgewecke/eth-gas-reporter/blob/master/docs/codechecks.md

Thanks for sharing it

A nice solidity build tool from a Nest grantee, @mcormier: https://github.com/macor161/quantal/

Hey thanks Brett! :)

Still a few months to go before production-ready though

wow, this is really cool @mcormier !!! So long waiting for nice error output! (So many times I have done truffle compile | grep Error, haha)

@bingen This is precisely because I was tired of doing truffle compile | grep Error that I started the project haha

It was basically a simple truffle-compile fork at first, but then I stumbled upon a few optimizations to speed up the compilation process.

This is quite cool for managing solc versions via docker: https://github.com/crytic/solc-select

The key things we should have this agent app do:

• Send / receive a eth transfer
• Send / receive a token transfer
• Contract invocation to another installed app (e.g. create a vote)
• Contract invocation to another org’s app (e.g. create a vote / vote)
• Contract invocation to an arbitrary contract
• Contract invocation that causes multiple tokens to be sent / received (e.g. atomically swap tokens for ETH)