<dkubb>
mbj: I wonder if we can revert that "expand all" mutation coverage patch. I haven't been able to mutation test axiom in over a month because of it
postmodern has quit [Quit: Leaving]
<solnic>
dkubb: it’s because of lack of filter function
<solnic>
not that patch
<solnic>
it tries to mutate Axiom::Types
<solnic>
and can’t find specs that would kill mutations of Axiom::Types
<solnic>
so it takes forever
<solnic>
+ it is going to be configurable
<solnic>
so, no need to revert that
<dkubb>
yeah, I need a filter really soon
<dkubb>
I can't really do the nested relation stuff if I can't mutation test it
<dkubb>
I'll start on it, but verifying it can't happen until I can filter out Axiom::Types stuff
<solnic>
dkubb: but you can run mutant against a specific namespace
<dkubb>
yeah, I can run it against the Axiom::Relation::Operation::Nested namespace, but if I have to change stuff outside that namespace it would be nice to verify that too
<dkubb>
btw, in the future we can't patch mutant in a way that breaks other gems. in this specific case we should've held back the patch until filtering was added
<dkubb>
hmm, the terminology in the RA papers is split between GROUP/UNGROUP and NEST/UNNEST .. I'm going with the latter because of the confusion with SQL. I do wish it wasn't the term SQL used though
<dkubb>
I think of grouping in SQL as more like folding
<solnic>
dkubb: you can workaround it now by generating a list of all namespaces - axiom::types and make a custom mutant-runner script
<solnic>
…for now ;)
<dkubb>
yeah I believe I did that for a rails project using mutant
andrei has joined #rom-rb
andrei has left #rom-rb [#rom-rb]
<mbj>
dkubb: I'm thinking the same
<mbj>
dkubb: We should revert it, and add it as optional behavior
<mbj>
dkubb: Not related to filter.
<mbj>
dkubb: BTW filters work since latest pushes to mutant
<mbj>
solnic: I'll have that expand all behavior in the next non -rc release
<dkubb>
oh yeah? that's awesome, I'll try it
<mbj>
dkubb: Sorry I have to run, cu later this evening
mbj has quit [Quit: leaving]
<solnic>
if you want to have that as optional behaviour then why reverting it?
<solnic>
this will break test suites of whole ROM so I’ll be not so happy
<dkubb>
well, it's done, but we need to all agree no more breaking one test suite in favour of another.
<dkubb>
if there's an established convention that other tools rely on then you have to follow it. if you want to change convention you can't change something that shifts the burden on the other libs. the proper thing would've been to add filtering at the same time as expansion
<solnic>
but expanding scope doesn’t break axiom specs, lack of filtering does
<solnic>
or did I confuse things?
<dkubb>
axiom worked with mutant before expansion, but stopped working afterwards because expansion is too greedy
<dkubb>
granted, no one could've predicted that would be the side effect, but when we found out a day or two later we should've reverted it until filtering was ready
<dkubb>
I didn't speak up at the time, which is my fault, because I thought as soon as I reported the issue I was having that someone would add filtering then
<solnic>
mbj was too busy
<solnic>
unfortunatelly
<dkubb>
I probably should've reverted it myself right away, and then asked that it not be added back until filtering is done
<dkubb>
it'd be the same if I made an breaking change in the axiom api that accidentally broke rom. it should be reverted immediately until I have a chance to make patches for rom-session, rom-relation, etc
<solnic>
well, with or w/o expanding scope it would take forever
<solnic>
no?
<dkubb>
obviously I realize the intention is that on one ever want to break interfaces, but when it does happen we need to assume it won't be fixed overnight and protect the foundation we had up to that point
<dkubb>
axiom takes a while, but with axiom-types it literally would take days
<dkubb>
with the expansion I mean
<dkubb>
I found it right away and reported it within a day or two, but I should've spoken up
<dkubb>
this will become especially important as we move forward and build more interfaces off each other's stuff
<solnic>
dkubb: ok it’s reverted
<dkubb>
just so I'm clear, I'm not upset. and I will probably help with making sure filtering is 100%
<solnic>
that’s OK, too bad we didn’t have time to handle all of that properly
<solnic>
I have a bigger problem now though, mutant task doesn’t work at all
<solnic>
it seems like it tries to require ‘rom’ because that’s my namespace
<solnic>
and that blows up
<solnic>
dkubb: ^
<dkubb>
that's messed up
<dkubb>
oh, mbj just left too, hmm
<solnic>
oh ok, I had to change name: rom to name: rom-relation
<solnic>
it works now
<dkubb>
where did you do that, in the mutant config?
<solnic>
yes
<dkubb>
all we need to revert that revert is to add filtering to the yaml file, right?
<dkubb>
mbj said filtering is in the core now
<solnic>
yes I think so
<dkubb>
I've got a spike for Axiom::Relation::Operation::Nest working
<dkubb>
I need to rewrite it and spec it properly, but it looks promising
<solnic>
sweet!
<dkubb>
I also need to work on Unnest after
<dkubb>
so the thing about nesting/unnesting is that you need to apply relational operators before nesting
<dkubb>
so like if you wanted to sort a relation, you'd apply it first and then nest
<dkubb>
you can always unnest, then apply the ops, and nest again. it should be possible to factor some of that out and/or use axiom-optimizer so it happens earlier
<dkubb>
ok, bbiab. I hope to commit an initial Axiom::Relation::Operation::Nest tonight