search

jeffreykegler / yahc

Yet Another Hoon Compiler
MIT License
0 stars 1 forks source link

TISGAR on HEPHEP line #40

Closed jeffreykegler closed 5 years ago

jeffreykegler commented 5 years ago

In a handful of places in hoon.hoon and clay.hoon, a TISGAR is piggy-backed after a HEPHEP. From hoon.hoon, lines 3659 on:

++  toon  $%  {$0 p/*}                                  ::  success
              {$1 p/(list)}                             ::  blocks
              {$2 p/(list tank)}                        ::  stack trace
          ==                                            ::
++  wonk  |*(veq/edge ?~(q.veq !! p.u.q.veq))           ::  product from edge
--  =>
::                                                      ::
::::  4: layer four                                     ::
  ::                                                    ::
  ::    4a: exotic bases                                ::

It strikes me that this should not be allowed. The problem shows up, among other places, in the staircase in the above, which is anchored based on the HEPHEP (--). My current anchoring logic requires the re-anchor brick to be a parent of the rune, and HEPHEP isn't a parent, it isn't even strictly speaking a rune.

@ohAitch: require the HEPHEP to be on a line by itself, or with other HEPHEPs in a criss-cross? Or something else?

ohAitch commented 5 years ago

All of those should be outer =~s instead yup. I guess it's maybe trying to reiterate "adding a new layer now"?

On Friday, 10 May 2019, Jeffrey Kegler notifications@github.com wrote:

In a handful of places in hoon.hoon and clay.hoon, a TISGAR is piggy-backed after a HEPHEP. From hoon.hoon, lines 3659 on:

++ toon $% {$0 p/*} :: success {$1 p/(list)} :: blocks {$2 p/(list tank)} :: stack trace == :: ++ wonk *(veq/edge ?~(q.veq !! p.u.q.veq)) :: product from edge -- =>

:::: 4: layer four :: :: :: :: 4a: exotic bases ::

It strikes me that this should not be allowed. The problem shows up, among other places, in the staircase in the above, which is anchored based on the HEPHEP (--). My current anchoring logic requires the re-anchor brick to be a parent of the rune, and HEPHEP isn't a parent, it isn't even strictly speaking a rune.

@ohAitch https://github.com/ohAitch: require the HEPHEP to be on a line by itself, or with other HEPHEPs in a criss-cross? Or something else?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jeffreykegler/yahc/issues/40, or mute the thread https://github.com/notifications/unsubscribe-auth/AAOFPBVEQBHUDKWWOVYXJXLPUY66FANCNFSM4HMHH2SA .

jeffreykegler commented 5 years ago

Added these to anomaly.suppressions. Also created a check that HEPHEP only shares a line with other HEPHEP's, and added the 9 occurrences of warnings about it to anomaly.suppressions. Marking "ready to be closed".

jeffreykegler commented 5 years ago

Closed as per the above.