Bump plutus to 1.58

[zliu41]

No description provided.

[palas]

Let's see if we can get the wasm bit working and the fix in IntersectMBO/plutus#7362 reviewed before merging, please. If it becomes urgent we can go ahead without it, but it would be for the best

[palas]

Oh, in fact I am getting this error int the wasm test. I must have done something wrong in the patch:

RuntimeError: Expected Right, got Left: "Error in $.costModels: CMInternalWriteError \"parsing Int failed, value is either floating or will cause over or underflow 9.223372036854775807e18\""
CallStack (from HasCallStack):
  rightOrError, called at src-lib/Cardano/Wasm/Api/Tx.hs:194:25 in cardano-wasm-10.0.0.0-inplace-cardano-wasi-lib:Cardano.Wasm.Api.Tx
  estimateMinFeeImpl, called at src-wasm

[palas]

I think I found the culprit: https://github.com/IntersectMBO/plutus/blob/0ddb89848cfd7f23199e23b7d3cb5a090054bea4/plutus-core/plutus-core/src/PlutusCore/Evaluation/Machine/ExMemory.hs#L67-L68

[zliu41]

@palas None of these is specific to plutus 1.58, correct? We didn't start to use Int just recently.

I'm not sure what's the goal here, but if it is to compile the entire Plutus evaluator to wasm, there must be a lot of things worse to compile than Int - like all the ST stuff, and there are also a lot of Integers, though I'm not very familiar with the constraints of the wasm backend.

[palas]

@zliu41 the issue is not using Int, the issue is assuming Int is 64 bit, I think. That wasn't an issue until now, but something that changed since 1.57 made that matter, because the previous patch https://github.com/IntersectMBO/plutus/compare/wasm-patch5 compiles and passes the test fine. And now it either doesn't compile, or with my patch it doesn't pass the test.

And the test is not evaluating plutus, it is just trying to read the protocol parameters from JSON

[zliu41]

Ok, in that case, let's table this for now - I need to get 10.6.2 out first. Then, we can investigate this further.

I'll open a PR shortly for bumping ouroboros-consensus to 0.30.0.1.