00:00 <snusnu> mbj: alfred listed aggregated contributors along with commit count, no fancy graph tho

00:04 <mbj> snusnu: heh, yeah

00:04 <mbj> I have to go to sleep, cu tomorrow

01:13 <snusnu> dkubb: i was thinking, wwyt of yard @examples simply linking to integration specs?

01:14 <snusnu> dkubb: i realize it's kinda dirty and lazy, and still means maintenance

01:14 <snusnu> dkubb: but while something is in flux, it's really hard to keep @example up to date

01:15 <snusnu> dkubb: so i'm wondering, if something is under heavy dev, we could either ignore @example completely, or link to integration specs … i somehow think of out of data @examples as no examples, probably even worse

01:16 <snusnu> dkubb: also, fwiw, i'm not necessarily talking about what we should do in rom, but i'm considering that for substation atm

01:24 <xybre> You guys have some really great tools for development. Just discovered Coveralls because of Substation.

01:27 <snusnu> xybre: heh thx, coveralls is neat and a cool tool to have, but for the sort of gems we do, it's almost only to show off until we wrote the service that provides mutation coverage badges ;)

01:27 <xybre> Its a badge, its all for showing off ;)

01:27 <snusnu> heh, trudat

01:55 <snusnu> dkubb: can you explain to me why mutant thinks the following kills all mutations? http://pastie.org/8201766

01:55 <snusnu> dkubb: imo that's a bug

01:56 <snusnu> dkubb: clearly it should need 2 contexts, one passing no new_input, the other passing a new_input

02:05 <snusnu> dkubb: updated the pastie to reflect what i think should be needed: http://pastie.org/8201786

03:28 <dkubb> snusnu: what if we make it so if there is no config file we don't run the metrics for that thing

03:29 <dkubb> snusnu: then if people want to spike things out they can without worrying about fulfilling all the normal requirements

03:30 <dkubb> snusnu: also yeah, I'm not sure why mutant considers that covered. it would be nice to have a debug mode to see all the mutations it tried

03:30 <dkubb> snusnu: in general I have a 1:1 correspondence between context blocks and logic branches

03:30 <dkubb> snusnu: and I consider a default option like this to be a logic branch

03:31 <dkubb> at least a 1:1 correspondence I mean.. sometimes you have more, but you shouldn't have less. the ideal would be exect correspondence, no more contexts than you possible need to cover each branch

09:41 <travis-ci> [travis-ci] rom-rb/rom-relation#146 (master - 7d44be6 : Piotr Solnica): The build was broken.

09:41 <travis-ci> [travis-ci] Build details : http://travis-ci.org/rom-rb/rom-relation/builds/9802524

09:41 <travis-ci> [travis-ci] Change view : https://github.com/rom-rb/rom-relation/compare/0010c0cade67...7d44be6c9b0a

11:13 <mbj> .

12:01 <snusnu> yo mbj

12:01 <snusnu> i fixed the bug you found for substation

12:02 <snusnu> and i left a lengthy comment on GH about how i think we should handle docs and yardstick

12:06 <snusnu> mbj: ok, to make you respond, i'm gonna link you to what i think is a bug in mutant: https://gist.github.com/snusnu/6144875

12:06 <snusnu> :p

12:16 <snusnu> mbj: and the corresponding issue: https://github.com/mbj/mutant/issues/95

15:15 <snusnu> mbj: does adamantium::flat freeze ivars of a class, but not deep freeze them? or does it only freeze the class itself

15:27 <mbj> snusnu: It only freezes the instance of object, does not recurse

15:27 <mbj> so ivars dont get frozen

15:31 <snusnu> mbj: hm, i thought so, but i just can't find any inclusion of Adamantium proper, yet still objects get frozen, that i *definitely* do not freeze myself

15:31 <snusnu> mbj: i'm currently refactoring away Substation::Action, making all processors accept an array of observers instead

15:31 <mbj> snusnu: I debug this via def freeze; raise; end in affected class

15:31 <snusnu> mbj: and the observers get frozen

15:31 <snusnu> mbj: ah good point, i was about to ask

15:32 <snusnu> mbj: lemme try that

15:32 <snusnu> mbj: lol, the affected "class" is a lambda in my case

15:32 <mbj> snusnu: extend it

15:32 <snusnu> yeah, i might do that for debugging purposes

15:43 <snusnu> mbj: stack trace tells me nothing … i looked through the complete call stack and i have no single include Adamantium .. only flat

15:48 <snusnu> mbj: if that helps you anything: http://pastie.org/pastes/8203134/text … i swear i never do "include Adamantium"

16:18 <snusnu> dkubb: do you have any idea what could be happening in the above pastie?

16:20 <snusnu> grepping my code shows me that i *never* do include Adamantium, only Adamantium::Flat

16:25 <snusnu> dkubb, mbj: if i remove that line the error goes away https://github.com/snusnu/substation/blob/master/lib/substation/processor.rb#L9

16:25 <snusnu> which is very weird

16:46 <dkubb> snusnu: one way to debug that is to redefine freeze to raise and then check the callstack

16:46 <dkubb> so on the object you don't want frozen, do def freeze; raise; end

16:46 <dkubb> oh wait, I guess you did that

16:49 <snusnu> dkubb: yeah, i did that already, the stacktrace is from doing exactly that

16:49 <snusnu> dkubb: it all works fine if i remove that one include Adamantium::Flat .. which is weird i guess

16:52 <snusnu> dkubb: also note how the stacktrace shows that #deep_freeze is involved

16:52 <snusnu> dkubb: i grepped my codebase, and i don't do any include Adamantium, nor IceNine.deep_freeze

17:05 <snusnu> ok, have to go .. ttyl