kedars
commented
2 years ago Changing this still compiles, however unit tests for me always failed. Before the patch:
failures: data_model::attributes::test_read_success data_model::attributes::test_read_unsupported_fields data_model::attributes::test_read_wc_endpoint_only_1_has_cluster data_model::attributes::test_write_success data_model::attributes::test_write_wc_endpoint data_model::commands::test_invoke_cmd_wc_endpoint_only_1_has_cluster data_model::commands::test_invoke_cmds_success data_model::commands::test_invoke_cmds_unsupported_fields test result: FAILED. 4 passed; 8 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00sAFTER the patch
failures: data_model::attributes::test_read_success data_model::attributes::test_read_wc_endpoint_all_have_clusters data_model::attributes::test_read_wc_endpoint_only_1_has_cluster data_model::attributes::test_read_wc_endpoint_wc_attribute data_model::attributes::test_write_success data_model::commands::test_invoke_cmd_wc_endpoint_all_have_clusters test result: FAILED. 6 passed; 6 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00sit seems more things pass (specifically some invoke bits) but I am unsure why ... the change is supposed to be a noop. Guessing some unwrap/mutability bits. Please see if this makes sense.
Ah, so I use a slab allocator (boxslab: the newbie excitement to implement an allocator :-) ) and that only has about 4 or 5 buffers. As cargo runs the tests parallelly it runs out of the buffers and complains about memory.
I have been using cargo test -- --test-threads=1 this command to build the tests.
I had spent some time trying to figure out whether I can configure the pool size if its a test run, but couldn't find a way to do it.
Changing this still compiles, however unit tests for me always failed. Before the patch:
AFTER the patch
it seems more things pass (specifically some invoke bits) but I am unsure why ... the change is supposed to be a noop. Guessing some unwrap/mutability bits. Please see if this makes sense.