effectfully
effectfully
We really want to have faster `Data` processing, but as per #6225 this is quite hard. Matching on integers is very inefficient too as one needs to perform repeated calls...
Couldn't make it a proper performance improvement, but let's see if it helps.
Currently the `validation` benchmarks don't seem to have any golden tests ensuring that what scripts evaluate to doesn't change. Unlike e.g. `nofib` or `bitwise` benchmarks (and `lists` ones have some...
Just checking.
#5867 fixed some of the screwed up benchmarks (See [this](https://github.com/IntersectMBO/plutus/pull/4914#issuecomment-1387710846) comment for an explanation of what went wrong), but we still have more of these issues in - `budgeting-bench` -...
This shows what happens if we add #6839 to #6841 (i.e. the base branch is `zliu41/inline--fix`, not `master`). See the comments.
`PlutusTx.Builtins.Internal` has ```haskell consByteString :: BuiltinInteger -> BuiltinByteString -> BuiltinByteString consByteString n (BuiltinByteString b) = BuiltinByteString $ BS.cons (fromIntegral n) b ``` but that's the old definition of `consByteString`, the...
There's this in the implementation of the CEK machine: ```haskell (VConstr i _) | fromIntegral @_ @Integer i > fromIntegral @Int @Integer maxBound -> ``` but `maxBount :: Int` can...
This issue is for dumping all the plans regarding tests improvements in a largely unstructured way.
This is how the denotation of `indexByteString` is defined: ```haskell indexByteStringDenotation :: BS.ByteString -> Int -> BuiltinResult Word8 indexByteStringDenotation xs n = do unless (n >= 0 && n <...