<mbj>
zaidan: jo, it is my best "Emitter" I designed so far.
<mbj>
zaidan: Backported lots of improvements to unparser/mutant already.
dkubb has joined #rom-rb
<mbj>
dkubb: hola
<mbj>
dkubb: BTW I take full blame for that adamantium misdesign
<mbj>
dkubb: I was the person extracting it this way from axiom :D
<dkubb>
good morning
<dkubb>
mbj: no worries.. I don't care who designed something or not. I also don't see code as good or bad. what's more important to me is that code is moving in a specific direction along the spectrum
dkubb has quit [Ping timeout: 245 seconds]
dkubb has joined #rom-rb
<solnic>
morning dkubb
zekefast has quit [Quit: Leaving.]
<dkubb>
solnic: good morning
<dkubb>
solnic: I haven't forgotten about the memory adapter btw. I've got a semi-working gateway now, I just need to finish it up
<dkubb>
solnic: I have some time tonight for oss work, so I'll probably try to get something working tonight
<solnic>
dkubb: cool! I was just going to ask about that :)
<cored>
morning all
<solnic>
hi cored
<cored>
hello
<dkubb>
cored: good morning
<dkubb>
cored: I fixied a couple of simple failures last night in the axiom-types refactoring
<dkubb>
cored: the remaining ones seem to be caused by the way attribute inference happens inside the context evaluator
<cored>
dkubb: oh, great so you change what I did, I asume
<cored>
?
<dkubb>
cored: I'm not sure if I changed what you did, but I fixed a couple of the other failures I saw
<cored>
dkubb: good
<dkubb>
cored: the attribute inference in the context evaluator seems like it needs a bit more work
<cored>
dkubb: will check it out in a couple of hours to keep working on it
<dkubb>
cored: I think I wrote the code originally, but some of the assumptions change now
<cored>
dkubb: I see
<dkubb>
cored: Attribute.infer_type now returns a Types::Type subclass instance, while previously it returned an Attribute subclass instance
<dkubb>
cored: so the code assumes it'll have an Attribute, and it calls coerce on it
<cored>
I think that will break the other specs
<dkubb>
yeah, that's the reason the other specs that touch the code fail now
<dkubb>
I know we probably need to keep the change in Attribute.infer_type, since there are other places that use it that *do* need a type and not an Attribute subclass
<dkubb>
the problem is I'm not sure the best way to fix that evaluator code
<dkubb>
if you're planning on looking at it I would first try to get a local fix working in that code and then only extract it to something in Attribute when it works
<dkubb>
I tried something quick but I couldn't get it to work, but it was late and I only had a few minutes to try it
<snusnu>
imo the coolest feature was the irc bot which basically had memo functionality, but posted questions/answers to the website
<snusnu>
mbj: i'm totally fine with that, yeah
<cored>
mbj: thanks
<snusnu>
mbj, zaidan: the idea was that because we get asked so many questions in the channel, and answered them over and over again, we wanted a FAQ to grow out of that, available on a website
<snusnu>
additionally, it collected all sorts of project stats from the various related projects
<mbj>
snusnu, zaidan: Today I'd love to pull stack over flow questions also.
<snusnu>
absolutely
<mbj>
But lets start with: travis, github-issues, codeclimate, mutcov, ...
<mbj>
All those "RO" services :D
<mbj>
zaidan: This is the chance to take over a project :D, I dont have the time to maintain rom-status/alfred?!
<solnic>
snusnu: blast from the past
<snusnu>
solnic: inorite?
<snusnu>
mbj: do you think it'd be worth putting the old alfred online somewhere, for reference
<snusnu>
?
<zaidan>
mbj, snusnu: yeah sounds great
<mbj>
snusnu: yeah, but dont waste to much time!
<zaidan>
snusnu: would be nice to see a running demo
<snusnu>
mbj, zaidan: i'll see what i can do
<mbj>
zaidan: where is your twitter profile?
<snusnu>
btw, i'm still impressed by how large the dm1 ecosystem is .. 183 related projects
<snusnu>
111 people writing code for those
<zaidan>
mbj: lol forgot to create one :D
<mbj>
zaidan: pls do so, it is easy to stay in sync with lates project related news.
<solnic>
snusnu: weeeeelllll....rails received contributions from 500 people only in 2013 ;P
<mbj>
solnic: It takes a way more work to keep this mess stable :D
<snusnu>
lol solnic
<snusnu>
where did it get them?
<snusnu>
:p
<solnic>
I think on github
<snusnu>
heh, i think you misunderstood me, but anyways :p
<solnic>
that was supposed to be a joke
<solnic>
O_o
<snusnu>
:D good one
<mbj>
lulz
<solnic>
ba-dum-tssshhh
<mbj>
solnic, snusnu: Given we'd have a rom-style alfred implementation, would we link it? alfred.rom-rb.org?
<solnic>
dunno, maybe, why not
<solnic>
I'm more concerned with setting up a basic website now
<mbj>
hehe
<solnic>
alfred would be cool
<solnic>
but it's not a prority imho
<mbj>
Alfred would be self maintaining, and producing visible activity for free.
<mbj>
If you'd combine a commit stream of all related projects our activity would look immense.
<mbj>
This was the idea when i started {rom,dm}-status, but never finished it.
<snusnu>
i'd love to rebuild alfred using rom and substation, but i too think that there are more important things to be done
<snusnu>
maybe i should just rephrase the above .. i'd love for someone to rebuild alfred using … :p
<solnic>
haha
<solnic>
totally
<solnic>
using rom :)
<snusnu>
of course, everything else is no option
<mbj>
hehe
<mbj>
And mutation covered :D
<solnic>
well using rails 4 with activerecord would be cool, there are some nice features
<mbj>
solnic: heretic
<snusnu>
lulz
<solnic>
:D
<snusnu>
mbj: btw, can we get that router you were talking about? :p
<mbj>
solnic, snusnu: You might missed it also. Mutant has an epic BUG.
<mbj>
It does not recurse into memoized methods and skips them silently
<mbj>
both public and private!
<snusnu>
mbj: i haven't missed it, i was talking about initializing ivars … :)
<mbj>
snusnu: yeah, remember
<mbj>
so all our 100% mutation coverage from past is a lie
<mbj>
snusnu: My new machine has around 5-6 hours, so I typically forget about charger in the beginning of day
<mbj>
to get interrupted HARD.
<solnic>
snusnu: I recently worked whole day on a battery
<solnic>
> 8 hours
<solnic>
when I finished there was still around 30 minutes left
<solnic>
mbp <3<3<3
<solnic>
I wonder if Mavericks has anything to do with this
<solnic>
I don't think I had more than 7 hours battery life before the upgrade
<snusnu>
yeah, it was like that for me too .. but now the mbp is almost 4 years old ...
<solnic>
yeah mine is a little over a year
<snusnu>
the shitty thing is, it doesn't warn me anymore nowadays, while it actually says it's charging, it just dies
<snusnu>
what is mavericks?
<snusnu>
solnic: ^^
<cored>
solnic: how did you do that?
<cored>
have to research about how to make my XPS do that
<mbj>
snusnu: May I ask you to spend your typical "documentation love" to mutants README?
<snusnu>
mbj: hm, well, not really, i mean now .. also, wdyt is missing?
<mbj>
snusnu: "love"
<mbj>
snusnu: I think the structure is misleading and the document looks not really friendly
<mbj>
I enjoyed reading the substation readme over and over again.
<snusnu>
mbj: heh thx, know what, just ping me again when you think about it again :)
<cored>
did you guys see the link about datamappify
<cored>
?
<solnic>
cored: I know about datamappify
<solnic>
it uses virtus internally
<cored>
solnic: yes
<cored>
looks like rom-rb but with less stuff
<cored>
right?
<mbj>
solnic: okay! thx!
<kpwz>
!memo
<kpwz>
how do I do this memo stuff
<kpwz>
ah well, I'll find out later
<solnic>
kpwz: "!memo nickname message"
<snusnu>
mbj, zaidan: i don't even know why i did that now, but i tried to start up alfred but it doesn't work anymore .. rails changed too much in the meantime
<solnic>
cored: weeellllllll it uses another ORM under the hood
<solnic>
snusnu: btw Dan told me that he'll have a working memory gateway later today
<solnic>
snusnu: once that's done I'll wrap up session rewrite
<snusnu>
solnic: how awesome!
<solnic>
and move back to relation/mapper
<solnic>
it'll be easy to get the first release from there...
<solnic>
I want to add a simple DSL to define mappings too
<solnic>
something trivial
<solnic>
I think we will have to use a configuration where you provide a mapper class
<solnic>
which defaults to ROM::Mapper
<solnic>
or maybe that's not needed
<solnic>
actually, it is not needed
<solnic>
if you want something custom you can inject a mapper instance
<solnic>
ok nevermind that was loud thinking ;)
<solnic>
gtg bbl maybe ttyl
<snusnu>
mbj: did you already use substation failure chains?
<snusnu>
mbj: so, i wanted to discuss a refactoring that would introduce dedicated Chain::Incoming and Chain::Outgoing classes with you
<snusnu>
mbj: the issue here is, that currently, a chain stops if any processor returned a failure response … so that code i linked above makes sure that if a *response* was passed in, this doesn't happen (as a failure chain is an outgoing chain, and *exists* for further processing a failure response)
zaidan has quit [Quit: leaving]
<mbj>
snusnu: busy, back later
<snusnu>
fair enough
dkubb has joined #rom-rb
<dkubb>
mbj: do you think mutant is ready for another beta release?
knowtheo1y has joined #rom-rb
knowtheory has quit [Ping timeout: 264 seconds]
<mbj>
dkubb: I need to cover that adamantium case than yes.
<mbj>
dkubb: Do you need a specific fix that is in master?
zekefast has joined #rom-rb
<dkubb>
mbj: no, not atm. I was just wanting to make sure the gem is kept relatively close to master
<mbj>
dkubb: I have that adamantium fix in the pipeline
<mbj>
dkubb: Will release soon!
<dkubb>
mbj: sweet
<dkubb>
mbj: zombification helped expose bugs, which is nice
<mbj>
dkubb: BTW we are planning a rom-sype meetup 18:00 CEST
<mbj>
tomorrow
<mbj>
*skype
<dkubb>
mbj: I suspect we'll see another bump in exposed bugs when we start mutating the class/module body and regexps
<dkubb>
mbj: ahh ok, I'll have to see but I'll try to make it
<mbj>
dkubb: Yeah, mutant is a longterm project
<mbj>
There is also lots of stuff in mutants code I dont like
<mbj>
I'm passing 3 objects around inside the matchers.
<mbj>
at least the method matchers.
<mbj>
I need to collapse this somehow
<mbj>
And to inject the runner with configuration inside the mutator to allow per run selectively deactivation of some mutations
<dkubb>
yeah, you have to see if you can come up with a name for the group of 2 or 3 things
<mbj>
For example I see many people dont like "return value" => "value"
<dkubb>
I've only seen one complaint
<mbj>
At my workplace they love explicit returns
<dkubb>
I don't think it's common convention in ruby code to use an explicit return, except for an early exit
<dkubb>
it reminds me of when people try to write C in ruby
<mbj>
Yeah, but demands for configuration inside the mutator are rising
<dkubb>
yeah, I can see that being an eventuality
<mbj>
So I need to make this step soon
<dkubb>
I guess I would just defer it until it's really painful. you'll have better use cases by then too
<mbj>
But currently I focus on bug hunting :D
<mbj>
I have enouhg syntax errors and crashes left!
<dkubb>
hehe
<mbj>
Also the zombifier could need a small refactoring
<dkubb>
have you mutated unparser?
<mbj>
yeah, but it takes 5-6 hours now
<dkubb>
I'd also be curious if mutating parser using --rspec-unit might expose some bugs
<dkubb>
hehe
<dkubb>
does unparser use dm2 style unit tests?
<mbj>
unparser has around 2k examples currently
<dkubb>
maybe that's where your fast-fail would be helpful
<mbj>
I'd get an implicit begin node and an explicit kwbegin node.
<mbj>
This allows far easier unparsing, before I had to be context aware if a begin node is a body of a method or not.
<mbj>
I still track the context, but maybe I can remove this.
zekefast has quit [Read error: Connection timed out]
<mbj>
dkubb: Also I have to rework that "spike spec" lots of context descriptions are invalid.
<mbj>
It grew over the time :D
<dkubb>
mbj: yeah it's understandable. the specs need just as much maintenance as the code
<dkubb>
mbj: one thing I saw that was neat is ruboto actually pointed out a few things in my specs that could use improvement, style wise
<mbj>
dkubb: nice, running our tools against the specs is interesting
<mbj>
dkubb: I plan to write my own unit spec framework
<mbj>
dkubb: It materializes already more and more in my brain
<mbj>
dkubb: It is an rspec like dsl, focusing on doing *one* method call
<mbj>
dkubb: And asserting lots of stuff on the return value and or side effects.
<mbj>
dkubb: Ideally it produces a runner tree (just like mutant) other tools can use. And I build reporters on top of this.
<mbj>
dkubb: This will allow me to check wich specific assertion/expectation killed a mutantion and wich never killed a mutation!
<mbj>
Those that never killed a mutation are eighter:
<mbj>
* Not needed
<mbj>
* A sign mutant has a blind spot
<mbj>
And ideally that specs can pass flay/flog/reek etc.
<mbj>
you remember that rspec rom/dm2 style spec inference thing i wrote?
<mbj>
Where by name of spec file subject, object, etc where set. Just like this.
<mbj>
Each spec should be minimal.
<dkubb>
mbj: I would like something that can infer some of the method specifications from the YARD docs themselves
<mbj>
Yeah
<mbj>
But we IMHO have to rewrite yard on top of parser before!
<mbj>
It has some conceptual problems IMHO.
<dkubb>
hehe
<mbj>
unparser will soon reproduce comments!
<dkubb>
well, YARD does provide an api to get at the comments. it shouldn't matter what it uses underneath to parse the code.. aside from being more accurate with parser
<mbj>
Mhh, I think yard has blind spots and could be implemented much easier with parser.
<mbj>
Also yard should *load* the library
<mbj>
And not only introspec the source, especially yardstick would benefit
<mbj>
Because you know if a specific method is private or public if you load the library.
<mbj>
If you cannot load the lib without executing some code that causes side effects (runs servers, or whatever) you have a problem.
<mbj>
If I add comment support I think unparser can soon be our prettifier.
<mbj>
I can detect {} vs do; end
<snusnu>
huh? pastie? mbj?
<mbj>
snusnu: not mine
<mbj>
snusnu: resurected it from ruby-lang :D
<snusnu>
lol
<snusnu>
ok
<snusnu>
all is still good then
<mbj>
lulz
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
djsell has joined #rom-rb
<elskwid>
Hey, neat, IRC still exists!
<elskwid>
(Hi everyone)
solnic has quit [Quit: Leaving...]
postmodern has joined #rom-rb
<dkubb>
elskwid: heh, did you think the IRC channel wouldn't be around, or has it been a while since you used it?
mbj has quit [Quit: leaving]
djsell has quit [*.net *.split]
djsell has joined #rom-rb
<kpwz>
dkubb: hey, I only just saw your message sent to kapowaz
<kpwz>
sorry, I only think to check that (on irccloud) once every blue moon :)
knowtheo1y is now known as knowtheory
<kpwz>
dkubb: anyway to answer your question, I do contract these days, and whilst I am currently engaged until September I'd certainly be interested about anything that's cool, particularly in the Ruby world.
djsell has quit [Read error: Connection reset by peer]
mbj has joined #rom-rb
mbj_ has joined #rom-rb
<mbj>
snusnu: FYI i released ducktrap 0.0.1
mbj_ has quit [Client Quit]
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] mbj/ducktrap#107 (master - d3eb39e : Markus Schirp): The build has errored.
<chendrix>
and for this particular method that's the only mutant it says is alive
<snusnu>
chendrix: ah ok, well, i guess i was once talking to mbj about this .. iirc his take is that mutant should point you towards the "minimal" code that's necessary .. since the explicit return is not necessary in this case, mutant points you towards a "simpler" way to achieve the goal …
<snusnu>
chendrix: which in this case, btw, also fits with most ruby styleguides i've seen so far
<chendrix>
I guess. that's pretty opinionated style-wise for a mutation detector, IMO
<snusnu>
chendrix: but yeah, mbj can give you the definite answer, or maybe dkubb too :)
<snusnu>
yeah, i totally see how it's opinioted
<chendrix>
so it doesn't *add* explicit returns, only removes them, it sounds like
<snusnu>
yeah, because adding wouldn't lead to "minimal" code
<snusnu>
removing would
<chendrix>
gotcha
<snusnu>
btw, i dunno if this is the "official" take on this, just what i heard at some point
<snusnu>
only recently mbj and dkubb were chatting about this
<chendrix>
well at least it's being actively talked about
<snusnu>
absolutely! it's an integral part in our toolchain (not only) for rom
<snusnu>
btw, i'm always interested in reasons people choose a different style .. what's your particular reason?
<chendrix>
I've seen code where a block is evaluated at the end of a method, and the implicit return of it has ended up yielding funky results
<chendrix>
also when the implicit return is a boolean
<dkubb>
hey
<dkubb>
sorry was working
<chendrix>
np
<dkubb>
actually, in this case mutant doesn't know anything special about return
<dkubb>
in fact it's pretty dumb in how it works in that case
<dkubb>
it's not opinionated at all. probably the opposite
<chendrix>
so what was the mutation i pastied about?
<dkubb>
it treats any expression in the source code the same as any other. it will remove some part of the expression, and if that doesn't cause the specs to fail it will consider it unkilled
<chendrix>
gotcha, that just happens to lead to this
<dkubb>
if you had something like: 1 + 0 it would mutate it to 1
<dkubb>
my personal feeling is that explicit return statements are redundant
<chendrix>
does it make sense to make an exception for language constructs?
<dkubb>
I generally try to express code using the least amount of text
<dkubb>
I think mbj is considering handling it by making an exception
<dkubb>
I love how mutant points out placed in my code where I was redundant
<snusnu>
dkubb: btw, i guess that's what i meant by opinionated, i thought i once heard mbj say the same thing, "if mutant points you toward minimal code, that's fine"
<snusnu>
which i btw agree with
<dkubb>
just yesterday I had something like: redirect_to user_path(current_user) .. and mutant rewrote it as redirect_to current_user .. showing me that my use of the url helper in this instance was redudant
<dkubb>
snusnu: yeah, I guess that's the only opinion. it pushes you in a direction of lower complexity code
<dkubb>
lower complexity is also easier to test and easier to kill mutations in
<chendrix>
isn't that just using rails magic at the expense of clarity?
<chendrix>
user_path(current_user)
<chendrix>
vs current_user
<dkubb>
I don't consider it magic if it's part of the interface and the mechnism is fairly well understood
<dkubb>
you could fault me for using rails altogether :)
<dkubb>
but I don't have much choice in this case
<chendrix>
haha no fault there, I use rails all the time
<snusnu>
hehe
<chendrix>
in fact I'm trying to use mutant on a rails project right now
<dkubb>
I don't think it's a loss in clarity though.. I mean, I just had forgotten about that part of the interface to redirect_to
<dkubb>
oh yeah? I've had some good luck with it
<dkubb>
using it on a rails 4 + DM project
<chendrix>
nice!
<chendrix>
have you run into this?
<chendrix>
gems/activesupport-3.2.13/lib/active_support/dependencies.rb:245:in `load': cannot load such file -- /Users/chendrix/Projects/console/code/::Manifest (LoadError)
<chendrix>
when doing mutant '::Manifest' --rspec-unit
<dkubb>
oops, I didn't know about the name collission
<chendrix>
figured after I found it (considering the room I'm in)
<dkubb>
ahh well, it's a dev dependency so we just reference it using :git in a Gemfile
<dkubb>
we use that in all our gems
<dkubb>
it has some built-in metrics and stuff we run against code before it makes it into master or a gem release
<chendrix>
nice
<chendrix>
getting some form of metrics visibility into any of my projects that go through CI has been such an unnecessary PITA
<dkubb>
yeah, this makes it relatively simple
<dkubb>
it uses thresholds mostly specified in config files
<dkubb>
so if you drop below your configured threshold it will let you know
<dkubb>
it's not so concerned with stuff like metric_fu and generating reports.. it's more about letting you know when you unintentionally forget to document something, or introduce complex code, etc
<dkubb>
and of course when you have uncovered mutations ;)
<chendrix>
nice. following this README is not as easy as it looked
<chendrix>
ha :)
<dkubb>
which one is that?
<chendrix>
for devtools
<dkubb>
ahh ok. keep in mind most of the contributors are not native english speakers. I need to do a pass over it
<dkubb>
plus we've all been using and evolving it for a while, so it's possible the getting started step is fuzzy
<chendrix>
yeah
<chendrix>
I've added the stuff to my rails' default Rakefile