Nicolás Venturo

We haven't published to EthPM for a while now - @frangio is this something we want to go back to?

@FrozenKiwi could you expand a bit on the issues when using yarn PnP, and how EthPM addresses those?

https://github.com/balancer-labs/balancer-v2-monorepo/issues/1744 is related to this, as the fact that we upscale early, before decoding user data, is what ultimately causes for the wrong rounding direction to be applied (since we...

There's no valid weight for BPT, so we'd either have the scaling factors and weights have different lengths, or not have a factor for BPT either. Given that the BPT...

Closed as of #1867 and #1870

We're likely going to instead store normalized weights directly.

The proposed solution suffices for arbitrary values, but it won't help with edge conditions, particularly on the upper range. E.g. if I bound an 8 bit value to [10, 20],...

Thanks for the ping @mds1! Just run our tests using the v0.3 branch and everything seems to work correctly.

Actually, after further testing I'm seeing some changes in behavior when using commit [dc8d830](https://github.com/foundry-rs/forge-std/pull/184/commits/dc8d830d3af6f67758f793ce42572270fb0f41fb) when compared to f36dab2 [`testExitSwaps`](https://github.com/balancer-labs/balancer-v2-monorepo/blob/master/pkg/pool-weighted/test/foundry/WeightedMath.t.sol#L105) fails with too many `vm.assume` rejects. I imagine that could be...

Hi there @Arachnid, thank you very much for this! We've actually discussed your library a couple days ago in https://github.com/OpenZeppelin/openzeppelin-solidity/pull/1746, and started work on a [`Strings` library](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/fbbff535285fbff1a55a18af110b46eafb15f4bf/contracts/drafts/Strings.sol) (rather barebones so...