witnet
Rad replace separators
@tmpolaczyk thanks a lot for your suggestions. Those helped make the code much cleaner.
I'm fixing something really stupid that breaks the end-to-end tests under /examples. Happy that we have those.
I'm fixing something really stupid that breaks the end-to-end tests under /examples. Happy that we have those.
Oh, I didn't notice the test failure. Funnily enough, I was considering removing those examples because they didn't seem useful, and they are missing many data requests from the data feeds app. Anyway, if you find the cause please also add a unit test somewhere!
The issue was with trying to read JSON native numbers as strings. As integers and floats are now internally handled first as strings, pre-processed, and then converted to their right type, I was having problems with one of the examples that has a data source with a raw float (not encoded into a string).
With the latest changes, those wild floats can be read either as a float or as a string.
Also took the chance to simplify how RadonType conversions work, and to improve how the decoding errors are managed.
@tmpolaczyk do you think it's worth it if I guard these changes behind a TAPI conditional in this same PR? Or shall I merge it into a new branch and make another PR there for the guards?
The changes in impl TryFrom<RadonTypes> for RadonString are problematic because they cannot be made conditional using TAPI (there is no way to pass an extra argument to try_from), and it's hard to find all the usages of that function to ensure that it doesn't cause any accidental breaking changes. I haven't found any potential breaking changes in the tally creation, which are the dangerous ones, but I can't guarantee that they don't exist yet.
So I think it's better to solve the TAPI issues before merging.
The changes in operators can be easily guarded because operate_in_context has access to the list of active wips, so it's just a matter of moving the operator calls from operate to operate_in_context. And it doesn't need to have a custom wip name with an activation date, something like if wip_xxxx should be fine. Also we need to create a witnet-1.6 branch.
The changes in
impl TryFrom<RadonTypes> for RadonStringare problematic because they cannot be made conditional using TAPI (there is no way to pass an extra argument to try_from)
This shouldn't be a problem anymore as I have reverted most of those changes and covered them with exhaustive tests that verify that the behavior before the activation of the WIP remains unchanged.
The changes in operators can be easily guarded because operate_in_context has access to the list of active wips, so it's just a matter of moving the operator calls from operate to operate_in_context.
Great suggestion. That is exactly what I have done.
Looking great! I found some unexpected changes in the StringMatch operator: basically if the default value is a string, the result of the match is now converted to a string. I was able to find a quick workaround so that's fixed in this branch, with tests. I disabled the new behavior, but we could enable it with TAPI if we find it more useful, and that would allow us to remove the workaround after the WIP is enabled.
I have merged in the changes from @tmpolaczyk, and updated the TAPI guards so they have the right WIP number (0024). This should be ready to review and merge.
