bisectable6

query

my %column = :references, :model-name; say so(%column{<model-name model-type>.none}:exists) == so(%column{<model-name model-type>.all}:!exists) # is that expected (that's breaking Red)

result

Bisecting: 45 revisions left to test after this (roughly 6 steps)
[8529cc97a3267c89a436a9c079b2ac8edb0f3655] Use --/++$i instead of $i = nqp::add/sub_i($i,1)
»»»»» Testing 8529cc97a3267c89a436a9c079b2ac8edb0f3655
»»»»» Script output:
False

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is different
»»»»» Therefore, marking this revision as “new”
»»»»» -------------------------------------------------------------------------
»»»»» Testing 771655b0b5e18e2892f29a4e3c62d456054b4430
»»»»» Script output:
True

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is identical
»»»»» Therefore, marking this revision as “old”
»»»»» -------------------------------------------------------------------------
»»»»» Testing 4677dcb7ad98c87cbe8b984344b6f0c2955b9442
»»»»» Script output:
False

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is different
»»»»» Therefore, marking this revision as “new”
»»»»» -------------------------------------------------------------------------
»»»»» Testing fafcca3159967fe5e7270e8b128d0319c704b7b9
»»»»» Script output:
False

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is different
»»»»» Therefore, marking this revision as “new”
»»»»» -------------------------------------------------------------------------
»»»»» Testing c50f51f9527e39292ccf5ecd89a4788101fe9765
»»»»» Script output:
False

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is different
»»»»» Therefore, marking this revision as “new”
»»»»» -------------------------------------------------------------------------
»»»»» Testing df09bef0b9ad98bf1d5b84200bfaf5e4a0c35cc5
»»»»» Script output:
True

»»»»» Script exit code: 0
»»»»» Bisecting by output
»»»»» Output on “old” revision is:
True

»»»»» The output is identical
»»»»» Therefore, marking this revision as “old”
c50f51f9527e39292ccf5ecd89a4788101fe9765 is the first new commit
commit c50f51f9527e39292ccf5ecd89a4788101fe9765
Author: Vadim Belman <vrurg@lflat.org>
Date:   Tue Feb 8 21:20:14 2022 -0500

    Fix classification and categorization over junctions
    
    Potentially breaking change!
    
    Previously `classify` and `categorize` methods were autothreading over
    junctions internally, resulting in confusing results. In particular,
    where same value generally must only appear in a single class, use of a
    junction could result in duplication over different classes (see
    rakudo/rakudo#2814).
    
    This commit get things done right by putting junctions alongside other
    data types and allowing them to be the resulting hash keys. In other
    words:
    
        <a>.classify( * eq 'a' | 'b' ); # { any(True, False) => ['a']
    
    To achieve this outcome the resulting hash is now parameterized over
    Mu-typed keys. While this rather extends the API in general, but the
    change could also be breaking if there is code relying on the resulting
    hash to autothread over junctional keys.

:040000 040000 04dad3a2b784a0ad6e258d19b51a3ed6d7188143 aa3e40d09c5d158191798002a0937f6076d89765 M	src
:040000 040000 7483641c60b8df022dd9689fab6160ffde5b9b6c 8cc8f3633bb4bfa8372611f0829914fd07974f48 M	tools