jam and cue in core are wrong

[mariari]

I was looking over some anoma encoded data via the repl and saw very strange data

Swap> 1 |> anomaEncode
18014398509482168
Swap> 0 |> anomaEncode
184
Swap> 2 |> anomaEncode
36028797018964152
Swap> 3 |> anomaEncode
54043195528446136
Swap> 4 |> anomaEncode
72057594037928120

consumedMagic : Nat := anomaEncode "hello";

Swap> consumedMagic
148107274127321517247825720839002784496

These with the naieve cue implementation all give 5.

iex(anoma@YU-NO)14> 72057594037928120 |> Noun.atom_integer_to_binary |> Nock.Cue.cue
{:ok, 5}
iex(anoma@YU-NO)15> 148107274127321517247825720839002784496 |> Nock.Cue.cue
{:ok, 5}

however on a real implementation this doesn't use all the bytes, and thus is invalid with a proper implementation

iex(anoma@YU-NO)20> 184 |> Noun.atom_integer_to_binary |> Noun.Jam.cue
{:ok, <<5>>}
iex(anoma@YU-NO)21> 18014398509482168 |> Noun.atom_integer_to_binary |> Noun.Jam.cue
:error
iex(anoma@YU-NO)22> 18014398509482168  |> Noun.Jam.cue
:error

The jam and cue seem to work via the Juvix repl

foo : Nat :=  1 |> anomaEncode |> anomaDecode;
Swap> foo
1

so I assume the jam and cue implementation on Juvix core terms is wrong?

[mariari]

Further the encoding is insanely large for what it is. (encoding a resource takes 22 KB!)

[lukaszcz]

I don't think the encoding in the Core evaluator is meant to correspond to the "real" jam and cue. It's just automatically derived default serialization/deserialization with cereal

[paulcadman]

I don't think the encoding in the Core evaluator is meant to correspond to the "real" jam and cue. It's just automatically derived default serialization/deserialization with cereal

Yes, this is correct. jam and cue only makes sense for nock terms and in the REPL we only have JuvixCore terms.

We provide serialisation of JuvixCore terms (and some other Anoma stdlib functions on JuvixCore) in the JuvixCore evaluator so that we could test logic functions / transaction functions at the JuvixCore level. However we have since changed our testing strategy so that all testing will happen against the Anoma client and so our coverage of Anoma stdlib / RM functions is now incomplete in JuvixCore.

To avoid confusion perhaps it makes sense to remove support for all Anoma stdlib / RM functions from the JuvixCore evaluator?