Michael Müller

@forgetso Your contract is making heavy use of ink!'s `HashMap` ‒ this is totally fine, but that data structure takes a lot of space and this altogether results in the...

>I have a debug print in my constructor but it still doesn't print anything. @forgetso Sorry for the late reply. This is an unfortunate bug of the UI's: * Canvas...

> Thanks @cmichi. Is it also true that debug only prints on `read` and not `execute`? I only seem to receive debug messages when reading the contract functions. @forgetso Sorry,...

@ceikit We switched to a consensus mechanism "menual seal" a while ago (in https://github.com/paritytech/substrate-contracts-node/pull/42). This was done so that there is no block time, but instead transactions are processed alsmost...

Thanks a lot for this! I don't see how it will resolve https://github.com/paritytech/ink/issues/1428, but we should merge it nonetheless, as it's more structured this way. I don't think it will...

The proper solution would be to have each E2E `#[ink::e2e_test]` spawn its own node executable with a unique port (to not have nodes for individual tests collide). Then each test...

I don't see a proper solution for this that doesn't lead to bugs in tests due to ambivalence in behavior of `node_log_contains`. We could execute tests in a sequential order...

> Was this feature primarily to detect `debug_println!` output from contracts? If so these can be read as results from RPC dry runs. Yes that's possible and we're already doing...

@athei @agryaznov This issue is closed, is this correct? If so, could you then please create a follow-up issues in `ink` for removing the `seal_` prefixes from the FFI?

Persisting some of our discussions: ```rust #[ink(xcm_receive, max_gas_consumed = 50_000)] pub fn ink_xcm_receive(src: MultiLocation, msg: &[u8]) { if msg[0] == 1 { // expensive computation } else { // cheap...