<mbj>
snusnu: For that issue I pushed the fix already
<mbj>
snusnu: but the generic mutator exposes more bad stuff in unparser :D
<snusnu>
mbj: which is good i guess :)
<mbj>
snusnu: and bad :D
<mbj>
snusnu: I need to do clients stuff again
<mbj>
snusnu: Cannot make myself to bill hours on mutant again on this :D
<snusnu>
mbj: hehe i understand
<mbj>
snusnu: mutant + unparser together is a significant amount of work.
<snusnu>
mbj: but …. would you mind actually *pushing* the fix for that issue i mentioned? … just saying cause you said you already pushed it, but it isn't on github :)
<snusnu>
mbj: yeah dude i know
<mbj>
snusnu: pushed
<snusnu>
mbj: thx!
<snusnu>
mbj: i see mutant now prints out "cannot find definition of …" warnings (mostly) for concord generated code
<mbj>
snusnu: As it should
<mbj>
snusnu: Silencing that kind of warnings made me miss adamantiums memoizers :D
<snusnu>
mbj: yeah, i've heard you talk about it
<snusnu>
mbj: i got some for concord, abstract_type, and some of my own code … which oddly(?) seem to be attr_readers mostly?
<snusnu>
mbj: yeah, i only get those warnings for concord, abstract_type and attr_readers i defined
<mbj>
snusnu: okay
<mbj>
snusnu: okay for me
<snusnu>
mbj: i guess the attr_reader ones can be silenced tho?
<mbj>
snusnu: nope, ruby does not give me any information I could reflect on
<snusnu>
mbj: ah ok
<mbj>
snusnu: Mutant only sees a class and a list of symbols
<mbj>
snusnu: From there I need to reflect
<snusnu>
mbj: i see
<snusnu>
mbj: well ok, apart from that, mutant master is now green for substation
<snusnu>
mbj: thx for the quickfix!
<snusnu>
mbj: if i had a free wish, i'd vote for hiding those warnings behind some sort of verbose flag .. obviously, that's very low prio
<snusnu>
mbj: what other mutations does it generate now, btw?
<snusnu>
mbj: with the generic mutator i mean
<mbj>
snusnu: Basicaly it visits children of nodes that have no dedicated mutator.
<mbj>
snusnu: Before it stopped recursion at unknown nodes.
<mbj>
s/unkown/un-explicit-handled-nodes/
<mbj>
snusnu: The biggest problem, my client will kill me and my wife will kill me
<mbj>
snusnu: I "wasted" the whole day on this mutant stuff
<snusnu>
mbj: please don't get killed!
<snusnu>
:p
<snusnu>
mbj: also, if it comforts you, imo your day wasn't wasted ;)
<mbj>
hehe
<mbj>
tell my GF
<snusnu>
hehe
<mbj>
I'll be dead tomorrow. Did not do any billable hour till 14:00
<snusnu>
i hardly ever do that
<snusnu>
:D
<mbj>
lulz
<snusnu>
so … i guess now is a good time to ask you for a substation pr review plus suggestions?
<mbj>
sure
<mbj>
snusnu: TBH, I'm still hunting that dstring issue, sorry
<snusnu>
lol, i hope you didn't take that too serious, that said, please don't review now, as you shouldn't get killed … :p
<mbj>
lulz
<mbj>
Without my GF I'd be bankrupt already
<mbj>
OSS is too addictive
<snusnu>
i exactly know what you are talking about
<snusnu>
it's not oss that's addictive per se, it's the fact that most work is boring, while oss is play .. we all like to play, don't we
<snusnu>
the fact that it's a game that produces actual *value* doesn't help either :D
<mbj>
heh
<mbj>
snusnu: heya
<mbj>
snusnu: problems fixed
<mbj>
snusnu: With latest mutant ducktraps coverage whent down from 100% to 97%
<mbj>
A good sign :D
<snusnu>
mbj: with something you have locally, or with the stuff that's on master?
<snusnu>
mbj: asking cause substation still is fully covered with latest master
<snusnu>
mbj: which probably is a good sign too ;)
<mbj>
snusnu: jo
<mbj>
snusnu: local, will push soon
<snusnu>
heh damnit
<mbj>
snusnu: But you have the mutator changes already
<snusnu>
heh awesome
<mbj>
snusnu: pushed my latest changes
<mbj>
and released beta10
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] mbj/mutant#452 (master - 30436d1 : Markus Schirp): The build was broken.
knowtheory has quit [Quit: Computer has gone to sleep]
ChanServ has quit [shutting down]
ChanServ has joined #rom-rb
knowtheory has joined #rom-rb
zekefast has quit [Quit: Leaving.]
fphilipe_ has quit [Ping timeout: 264 seconds]
dkubb has joined #rom-rb
<dkubb>
good morning
<solnic>
morning
<dkubb>
solnic: I commented a bit on your DSL todo issue
<solnic>
dkubb: thanks
<dkubb>
fwiw, I usually look at using a block in a DSL if it provides a heirarchy, separation from the code in the same scope, overrides some defaults in the same scope, or provides some "callback" type logic that needs to be applied to multiple items. I don't think those are the cases here
<dkubb>
one thing I might recommend though is looking at the RA operations and see if we can apply any of them in the mapper
<dkubb>
the map :attr, :to => :other could just be a shorthand for: self.relation = relation.rename(:attr => :other)
<dkubb>
or something like that
<dkubb>
mbj: did you say a per-class mutation would be easy to add? I could sure use that for 0.4. mutation testing in my rails app is starting to slow down a bit
<solnic>
dkubb: not sure if I get that last part
<solnic>
dkubb: are you talking about pushing mapping logic down to relation?
<solnic>
cause that's what this rename would do
<dkubb>
I was just talking about exposing the relation
<dkubb>
I probably would push mapping down to the relation, at least where possible
<dkubb>
the dsl specifies it, but the relation can easily handle it
<solnic>
yeah that's very easy to do
<solnic>
mapper could handle more complex stuff, like the coercion you mentioned
<dkubb>
yeah
<dkubb>
axiom doesn't provide any casting functions built-in, but the .extend operator can have any function added to it
<dkubb>
complex coercions always have to be handled in ruby I'd think
cored has quit [Ping timeout: 248 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
fphilipe has joined #rom-rb
<snusnu>
solnic, dkubb: i just commented on that PR as well
<snusnu>
and i have to run in a few minutes, so if you guys want to discuss, be quick about it :)
<solnic>
snusnu: yeah that's cool too
<solnic>
I'm on the fence wrt having mapping define inside schema
<solnic>
one thing though is that relation NEEDS a mapper (at least right now)
<solnic>
soooo
<solnic>
prior building relations FROM the schema
<snusnu>
solnic: yeah, *if* we need to support it, we should do so in some dedicated Mapper::Schema dsl
<solnic>
you gotta have mappers defined already for those relations
<solnic>
snusnu: that's cool, I can add that to rom-mapper
<solnic>
question is
<solnic>
what would schema do w/o mappers?
<solnic>
we can create a dummy pass-through mapper
<snusnu>
yeah imo it should just work with raw tuples then
<solnic>
sounds like a plan
<snusnu>
via a null mapper or directly, i don't care
fphilipe has quit [Ping timeout: 248 seconds]
<snusnu>
imo it'd be cool if the environment would *only* wrap the schema and some logical repository info for connecting … so it would simply wrap axiom relations .. you could then ask it to give back a ROM::Relation with something like PEOPLE = ROM_ENV.relation(:people, PERSON_MAPPER)
<snusnu>
solnic: ^^
<solnic>
snusnu: well, schema on its own is already that because you have gateways connected to repositories there
<solnic>
building rom relations with mappers is the missing part
<snusnu>
solnic: even better
<solnic>
so basically your raw relations are axiom relations
<snusnu>
solnic: then we should just provide SCHEMA.mapped(:people, PERSON_MAPPER)
<solnic>
and rom relations are backed by mappers
<snusnu>
yeah
<solnic>
damn
<solnic>
this turns into a quite beautiful design :)
<snusnu>
heh yeah
<solnic>
I *love* how those pieces are decoupled
<solnic>
we're not hiding everything behind a gigantic abstraction
<solnic>
we're building a layered system
<solnic>
where every layer is pretty much accessible and usable
<solnic>
that's *so* freaking powerful
<snusnu>
i guess that's our goal yeah, and it should be :)
<solnic>
yeah it is the goal
<solnic>
that's how I always advertised DM2 (now ROM)
<snusnu>
solnic: i've added that latest idea to the PR, and i have to leave now to visit my parents .. i'll be online a bit during the weekend tho
<dkubb>
stepping back a bit a relation can be thought of as a schema. you could have it so the schema object is basically just responsible for generating a relation that the mapper acts on
<solnic>
dkubb: that's how it works already :)
<dkubb>
ahh ok :)
<dkubb>
maybe I should make a better DSL for axiom for describing a relation?
<solnic>
schema object generates a relation and then you can inject a mapper that will be loading/dumping tuples/objects
<cored>
hello all
<solnic>
dkubb: not sure if we need anything better
<dkubb>
cored: hello
<solnic>
dkubb: it's pretty clear and simple now
<dkubb>
solnic: ok. yeah, what I did in the original relation interface was as bare bones and simple as I could think of
<solnic>
I mean let me know if you have ideas how it could be improved
<dkubb>
sure
<cored>
need to go full axiom this weekend, have been working on some vagrant stuff for an school project of sort
<dkubb>
I mean, if we see things that we can push down into axiom to improve it's interface I'm all for it
<dkubb>
cored: sounds awesome
<solnic>
snusnu: ok thanks for the feedback and have a great weekend then
<snusnu>
thx guys, you too
snusnu has quit [Quit: Leaving.]
zekefast has joined #rom-rb
<mbj>
dkubb: You talk about --rspec-file-per-class?
<dkubb>
mbj: yeah, I was thinking for this rails app I'm working on it might be useful to speed up mutation testing
<mbj>
dkubb: I thought all the time you talk about the class body :D
<mbj>
dkubb: It is easy to add yes.
<dkubb>
mbj: hehe.. well class body would be alright to have too ;)
<dkubb>
mbj: I was just wondering if we'll ever want to mix rspec strategy on a per-class basis. lemme show you the mutant output in one of my rails apps to explain this better.. one sec while I run it
zekefast has quit [Read error: Connection timed out]
<solnic>
dkubb: I think we're close to have functionality from your ideal world ;) please see my comment
<dkubb>
solnic: hehe, yeah I think we're all on the same page, but I was mostly commenting just in case ;)
<solnic>
yeah I think so too
<solnic>
fwiw I find current design to be very easy to extend
<solnic>
session already proved that
<solnic>
this relation <=> mapping separation is a really cool idea
<solnic>
after all mapper pattern is about mapping stuff only
<solnic>
that's what rom-mapper is doing
<mbj>
solnic: I still see my original session design in the current code :D
<solnic>
anyhow, dinner time, ttyl
<solnic>
mbj: wdym? loader/dumper?
<mbj>
overall :D
<solnic>
hmm not really
<solnic>
there are some similarities though
<mbj>
The last time I checked is 7 days ago.
<solnic>
it hasn't changed
<mbj>
okay, so I still see it and I like the direction it enolved.
<solnic>
I'm just waiting for dkubb to finish memory adapter so I can add missing specs and merge it in
<solnic>
mbj: yeah sure :)
<solnic>
I'm especially happy with the flexibility of proxy pattern that dkubb introduced in do gateway
<solnic>
I use it in 2 places in session and it gave me great power
<mbj>
Okay, and you said you are about to explain something better, what.
<dkubb>
mbj: actually, I'm not sure if I can justify my earlier comment. oh well, enjoy the output ;)
<mbj>
I dont see an obvious problem, apart from lots of generated methods, rails env.
<dkubb>
hehe
<dkubb>
yeah, rails is crazy in what it adds
<mbj>
We can silence some of the warnings later.
<mbj>
But now I hate the fact I missed memoized methods
<dkubb>
it's fine for now. maybe we'd have --verbose which would output this
<mbj>
Yeah
<dkubb>
I'm using the memoist gem and it looks like those methods aren't being mutated
<mbj>
Because they are missing source locations
<mbj>
Mutant can only mutate methods with source locations.
<dkubb>
mbj: what does "Cannot find definition of" actually mean? does it meant it can't find the specifications for that method or it can't find the original source?
<mbj>
It cannot find source to mutate!
<dkubb>
oh interesting
<mbj>
If you do:
<dkubb>
maybe I should extract the memoization in Adamantium and use that
<mbj>
define_method(:bar) do
<mbj>
end
<dkubb>
I can put it in a separate gem, and have Adamantium use it. then it'll be mutant-safe
<mbj>
you dont have method(:bar).source_location
<dkubb>
and stop using Memoist.. it was extracted from rails so it has some crazy source. I hate when I have to debug it
<mbj>
Call it idempotent
<dkubb>
:)
<mbj>
require 'idempotency'
<mbj>
class Foo
<mbj>
include Idempotency
<mbj>
end # lulz
<dkubb>
yeah, I would probably rename the method from #memoize to #idempotent .. I'd have a temporary alias with a warning to the old name
<mbj>
jo!
<mbj>
dkubb: So I'm about to run, can you open an issue about --rspec-per-file, I can try some minutes in the evening.
<dkubb>
mbj: ok
knowtheory has quit [Quit: Computer has gone to sleep]
solnic has quit [Quit: Leaving...]
knowtheory has joined #rom-rb
cored has quit [Ping timeout: 264 seconds]
<mbj>
dkubb: I have to see the original source
<mbj>
noob mutation fails can be caused by one of:
<mbj>
* mutant bug
<mbj>
* unparser bug
<mbj>
* parser bug
<mbj>
* spec failure
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
<mbj>
snusnu1: hola
mbj_ has joined #rom-rb
mbj_ has quit [Client Quit]
mbj has quit [Ping timeout: 248 seconds]
snusnu1 has quit [Ping timeout: 256 seconds]
knowtheory has quit [Quit: Computer has gone to sleep]
knowtheory has joined #rom-rb
mbj has joined #rom-rb
<mbj>
dkubb: interesting question
<mbj>
--fail-fast for mutant, stop on first unsuccessful mutation
<mbj>
Or after first unsuccessful subject.
<mbj>
AKA: Do we run all mutations of a subject than stop
<mbj>
Or stop on first mutation that fails.
<mbj>
I prefer the stop on first mutation, but I'd like to hear another voice.
<dkubb>
mbj: if I was using --fail-fast it's because I want fast feedback, and I want to proceed through and fix each problem as it's found.. once a problem is found I would want things to stop so I can work on it
<dkubb>
it wouldn't matter to me if there were other failures/successes after the first one is found. I would want mutant to stop right away so I could fix it and re-run again
<dkubb>
mbj: on the rspec side I use fail-fast when I don't want to get overwhelmed with errors. usually I'm focusing on a single class or method for a class and I want a tight as possible feedback loop
<dkubb>
mbj: so I guess I want the same thing as you, stop on the first failing mutation
<mbj>
dkubb: I feel totally the same (rspec)
<mbj>
I'll implement it as "stop on first mutation fail"
snusnu has joined #rom-rb
snusnu has quit [Read error: No route to host]
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
snusnu1 has quit [Read error: Connection reset by peer]
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
snusnu1 has quit [Read error: Connection reset by peer]
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
snusnu1 has quit [Read error: Connection reset by peer]
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
snusnu1 has quit [Read error: Connection reset by peer]
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
mbj has quit [Ping timeout: 264 seconds]
snusnu1 has quit [Ping timeout: 256 seconds]
kapowaz has quit [Remote host closed the connection]