urbit / vere

An implementation of the Urbit runtime
MIT License
59 stars 40 forks source link

`++cut` jet mismatch for large spans #699

Open Quodss opened 2 months ago

Quodss commented 2 months ago

To reproduce:

  1. Switch test flag in _140_two_cut_a to c3n
  2. Run in Dojo (set --loom to 33):
=a (cut 2 [0 (bex 31)] (bex (bex 33)))

You'll get:

mismatch: good 3a5bbd82, bad 79ff04e8

This is caused by the "rounding" of the argument c here when it's not a direct atom.

joemfb commented 2 months ago

That's interesting (and rough). That rounding behavior has been there forever -- I bet the increased loom size invalidated that behavior. u3a_maximum is properly defined in allocate.h, but you'd have to take the bloq size into account when comparing the step to it.

Quodss commented 2 months ago

@joemfb another example:

> (met 32 (bex (bex 33)))
1

It should've returned 3. It didn't because of the shortcut here.

Quodss commented 2 months ago

another mismatch of different nature: ++lte should return %.y if nouns are equal, even if both are cells. But in Dojo:

> (slum lte [0 0] [0 0])
dojo: hoon expression failed
Quodss commented 2 months ago

Similarly, ++lth should return %.n if both arguments are equal cells