Nicholas Rodrigues Lordello

Currently, I believe the best way forward is to port the code from [`intx`](https://github.com/chfast/intx/blob/de3388d75bda494972c4dceb22ccd1b0f74e1e97/include/intx/intx.hpp#L1788).

Ported 128-bit integer division from `intx` to compare it with Rust's `u128` type: lib.rs ```rust const fn reciprocal_table_item(d9: u8) -> u16 { (0x7fd00 / (0x100 | (d9 as u32))) as...

Re-opening this issue. Integer division performance was greatly improved with #18, but there are still some cases that can be improved. Specifically, `intx` provides faster `u256` division implementation that would...

Hey @albttx - I created a separate PR #15 with just `serde` support for the crate.

Thanks! I will find some time to review it this week.

Another potential option for approximating `truecolor` support would be to do something similar to what [`osc52pty`](https://github.com/roy2220/osc52pty) does (found it in a link in the [`vim-oscyank` README](https://github.com/ojroques/vim-oscyank#vim-oscyank)) for support OCS 52...

Looks like this is a `serde` issue as for flattened structs, it buffers the visited values in a `serde::private::de::Content` first which does not support `{i,u}128`s. Should I move the issue...

Just wanted to add to this issue, as we are seeing similar things. For example, this `eth_estimateGas` call: ```json { "jsonrpc": "2.0", "method": "eth_estimateGas", "params": [ { "data": "0x13d79a0b000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000e0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000003600000000000000000000000000000000000000000000000000000000000000002000000000000000000000000a0b86991c6218b36c1d19d4a2e9eb0ce3606eb48000000000000000000000000c02aaa39b223fe8d0a0e5c4f27ead9083c756cc2000000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000003635c9adc5dea000000000000000000000000000000000000000000000000000000000012d88aa058000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000000000000000000000003af210eec25e95f470fda218c9df9291adb7dcfd00000000000000000000000000000000000000000000000000038d7ea4c68000000000000000000000000000000000000000000000000000000000000013980400000000000000000000000000000000000000000000000000000000632cb5dd040495c3ef9351bd2138bc47e4018192d081a611e796cf906e2afc104355f85500000000000000000000000000000000000000000000000000038d7ea4c68000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000038d7ea4c6800000000000000000000000000000000000000000000000000000000000000001600000000000000000000000000000000000000000000000000000000000000041c1d85bef40ce5b68f8ca9c7ed61ab5db0aadccfbc3f67f753d106ff1aec9185a580ce393fbd948132f32b858a51fdd85aef09ac96d0ef8e2d640b42da21aeb931c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000", "from":...

> should we add an I256 type to ethabi My favourite place to add it would be `ethereum-types` or `primitive-types` crate alongside the `U256` type. The argument being that signed...

I think we're trying to figure out Crates.io access :see_no_evil:.