<snusnu>
guys, what are your thoughts on how plugins like dm-is-list or dm-is-nested_set will be implemented in rom?
<mbj>
mhh, interesting question. How these plugins should work once installed?
<mbj>
so do you plan to "change" the rom query dsl to add specific features?
<mbj>
Or do you plan to "infect" models?
<snusnu>
i'd expect to manipulate a plain ruby object (say, the list) .. and have session/mapper do the rest
<mbj>
found the root cause of the rbx crash
<dkubb>
yeah, I'd imagine the session and mapper would be handling it
<mbj>
I have a symlink int the repo from bin/zombie to bin/mutant
<mbj>
And rubygems will try to chown the files when installing a rubygem
<snusnu>
dkubb: do you think they'd need to know anything about the fact? .. i'd expect them not to
<mbj>
Detecting a symlink and calling "lchown", wich is not implemented in rubinius.
<snusnu>
i almost think rom will not care at all about plugins
<snusnu>
they should be datastructures imlpemented in "user land"
<dkubb>
I dunno
<snusnu>
which know enough about their "collection entries" that they can make all affected entries dirty in a good way, letting session do its regular thing
<dkubb>
I mean, i guess we'd have to look at what the functionality would be
<snusnu>
this is just a first thought btw
<dkubb>
I probably wouldn't want the model to have to know about it
<dkubb>
is-list functionality usually means that the records are persisted with a position, which you can change
<snusnu>
good point too … it shouldn'd be inside a "regular" model
<snusnu>
right
<dkubb>
oh, I guess you might need something to handle re-ordering of a set of objects to insert in the middle or something
<dkubb>
so there might be some business logic type stuff
<dkubb>
I dunno, I would probably look at what the functionality should be
<mbj>
dkubb, snusnu: That plugins "only" add semantic to specific attributes being persisted.
<mbj>
for example a list inside an rdbms has specific semantics on the index attribute/column
<mbj>
and I dont think session/mapper do neet to know anything about these semantics.
<snusnu>
yeah that's what i meant … is-list for example .. could be implemented in some "special" list class (plain ruby, no rom interfacing) .. which gets initialized with rom tuples, does its reordering magic on write ops, and then hand it back to session
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
<mbj>
snusnu: +1
<snusnu>
but how does that list class "integrate" with the domain model?
<dkubb>
snusnu: yeah, if it was a relation-like object it could probably handle stuff fairly easily
<mbj>
this was my first guess.
<mbj>
But I'd be totally okay with delegating list operations to a specific object
<snusnu>
hmm … maybe it could be implemented as a "special" rom relation after all .. because really, domain model code shouldn't need to know anything about it
<mbj>
So guys, turns out rubinius cannot install gems shipping symlinks. I can remove the zombie executable and add a --zombie switch to mutant.
<mbj>
This would also help for a mutant.yml where "options:" key could include "--zombie"
<snusnu>
mbj: is that the same error i saw on jruby too? the ERRNO::ESYSdunnoexactly error?
<mbj>
snusnu: yeah
<snusnu>
"cool"
<mbj>
I think going the --zombie route is the best option.
<snusnu>
mbj, dkubb: fwiw, i think the "design" of those plugins will be the same for at least all the persistent datastructures
<snusnu>
well, obviously ...
<mbj>
heh
<dkubb>
snusnu: yeah. and if the collection doesn't need the domain object and can act on the tuples, we'd be better off pushing it down to axiom
<mbj>
tbh I'm "müde", so moving to bed now.
<snusnu>
hmmm … moving that kind of plugin code to a specialized rom relation also means adding api to those .. something the rest of rom won't understand automatically
<mbj>
cannot really participate on our discussion.
<snusnu>
regular relation api isn't going to be enough .. think of #move or something like that
<mbj>
dkubb: "müde" => the opposite of awake
<snusnu>
hah
<snusnu>
mbj: have a good night then
<dkubb>
snusnu: ahh yeah
<snusnu>
mbj: tired, fwiw ;)
<mbj>
snusnu: I always misspell this one, so I have to avoid it.
<snusnu>
hehe
<mbj>
so cu guys! tomorrow will be a full OSS coding day. Enough on my todo list.
mbj has quit [Quit: leaving]
<snusnu>
dkubb: maybe hooking into the session would work? so the session sees a dirty { id: 1, position: 1 } and then rearranges everything accordingly?
<snusnu>
dkubb: somehow like uow will take care of tsort order ...
<snusnu>
otoh, that would mean it would only work with session enabled
<snusnu>
but since the session basically knows the previous/current states, it would be an ideal place to do the rearranging
<dkubb>
snusnu: I think I would probably start with the user interface and work downward
dkubb has quit [Read error: Connection reset by peer]
<dkubb>
snusnu: I just have to polish up a few things and I'll push it tonight
<dkubb>
snusnu: with this, the in-memory is essentially done
<dkubb>
assuming no one finds any holes like last time ;)
therabidbanana has quit [Quit: leaving]
<snusnu>
dkubb: nice! can't think of any holes in this ;)
<dkubb>
snusnu: is it roughly what you and solnic had in mind for the interface?
<snusnu>
dkubb: absolutely .. it is a bit confusing that your comment mentions setting up base relations but you actually assign Axiom::Relation, then again, it'd be weird having to state the name twice (once for the base relation, another time for #[]= .. would it maybe make sense to do: adapter.register(Axiom::Relation::Base.new(…)) ?
<snusnu>
dkubb: another tiny thing (and out of scope of the current work on relvars) is that with rom .. we kinda assumed that every adapter will have an URI .. the memory one simply being "memory://whatever" iirc
<snusnu>
dkubb: ok, i guess i see how #[]= is more flexible, because actually one should be able to assign arbitrary relations and give them a name? kinda like views have a name too
<snusnu>
dkubb: i guess there should be no restriction that says you can only register base relations with the memory adapter?
<dkubb>
snusnu: yeah, you could add any relation
<snusnu>
dkubb: yeah i thought so
<xybre>
Do you guys have a document that outlines how you want to use ROM in practice?
<snusnu>
xybre: we don't have any such documents yet .. but wdym by "in practice"?
<snusnu>
xybre: rom the lib will have a defined public api obviously, but how you'd integrate it into a larger app, remains to be seen .. i suspect the typical application architecture to be notably different from how, say, a rails AR app is done now
<snusnu>
xybre: fwiw, i'm working on my own library, snusnu/substation which basically implements a chain of responsibility, which seems to be very well suited for http request/response cycle style apps
<xybre>
snusnu: Even just example code of "I want to use it like this". I've seen the readmes for the various projects just wondered if there was a "goal" for the DSL/API to look at.
<snusnu>
xybre: ok, well, for the most part, rom's public api will closely resemble that of axiom relations
<snusnu>
xybre: the mapper dsl is still in flux, and we've ditched relationships for now (we had them in dm-mapper) .. so there's no relationship dsl atm either
<xybre>
snusnu: what made you give up the relationships code?
<snusnu>
xybre: we kinda approached it the wrong way, in dm-mapper, the mapper was wrapping the relation … in rom, we've split things so that there's a dedicated rom relation wrapping an axiom relation, and the mapper only works on single tuples
<snusnu>
xybre: while this wasn't the actual reason we ditched the relationships, that design made it increasingly harder to keep pursuing our goals
<snusnu>
xybre: also, if you think about it .. you don't really *need* relationships, they're just fancy names for joined relations anyway
<snusnu>
xybre: so without relationships (and we will of course add them back in) .. you can still achieve the same things .. only difference is, you'd need to write the joined relations yourself, and inject custom mappers into those
<snusnu>
xybre: once relationships are implemented again (along with a dsl) …. the respective joins will be generated for you, as well as appropriate mappers
<snusnu>
xybre: also, this time when we get around to implementing relationships, axiom will support #nest and #unnest relational operations .. which allow you to join, say, people and tasks, and then nest all tasks for any specific person inside an array accessible in person
<snusnu>
xybre: this will make the relationship code quite a bit simpler too (in dm-mapper, we did that nesting "by hand")
<snusnu>
xybre: in dm-mapper, we also followed an approach that would generate all join relations created from relationships "at boot time" .. storing them inside a graph object ….. i'm not entirely sure if we will go down that route again .. we'll see
<snusnu>
xybre: now that was quite some text … i guess i'm done ;)
jessekempf has joined #rom-rb
<xybre>
Wow
* xybre
gets a pipe and some tea, this coudl take a while
jessekempf has quit [Quit: Leaving.]
<dkubb>
lots of work is already done, but there's still some to do. we should have something usable pretty soon
<xybre>
Its trivial enough to generate them yourself if there's a good base for it.
<xybre>
But I like having them baked in, being able to "nest" relations in that fashion sounds wonderful.
<dkubb>
I suspect when it works we'll have lots of new use cases we never thouht of
<dkubb>
*thought
<dkubb>
I was at a user group yesterday and I was surprised that someone said "Oh I use veritas (what axiom used to be called) all the time"
<dkubb>
he was using it to process csv data. he'd parse the csv, feed it into axiom and then use it to join, restrict, etc
<dkubb>
things you can do in pure ruby, but they take time to setup and do properly
<xybre>
Nice!
<dkubb>
I would love for someone to work on a csv adapter actually
<dkubb>
csv, yaml and json adapters should be pretty easy to do and could share a ton of code
<dkubb>
there's also lots of stuff that people coudl be doing on the tooling side. like with mutant for example
<dkubb>
it's helped us make code that's much more solid than it would be without it
<xybre>
How well does mutant work in complex codebases?
<dkubb>
it depends. it takes a simple approach that should work in alot of situtions
<dkubb>
it depends on the speed of the tests and the granularity of the tests
<dkubb>
really big and slow integration tests won't work so well with it
<dkubb>
because it will make one change to the code and run some tests. it tries to isolate the number of tests to the minimum (and will be improving at this shortly), and then if the tests fail then it means the test covers the behaviour
<dkubb>
if the test passes even with modified code, it means some condition is untested
<dkubb>
it works with rspec, but it should be possible to write runners for minitest, test-unit and others
<xybre>
Hmm. I should trry it when I start my next project.
<dkubb>
there's also a bunch more mutations that we could add
<xybre>
Maybe I'll make a Uspec runner for it.
<dkubb>
and regexps aren't being mutated either. I suspect that'll expose whole classes of bugs in code (not ours, since we're pretty careful with regexps, but the average web app probably doesn't test their regexps very well)
<dkubb>
no doubt it'll find some things in our code. nearly every mutation I add exposes something somewhere
<dkubb>
I'm trying to contribute at least one mutation per week (which is about 10 mins of work)
<dkubb>
this week I think I contributed 10 or 15
<dkubb>
but my minimum goal is 1
<dkubb>
every new mutation helps the whole ecosystem become stronger.. and when mutant becomes more widespread it'll help ruby itself
<snusnu>
the *really* nice thing about mutant imo is that it teaches you to write solid tests, i found that after a while of using mutant, i tend to mutation cover almost all new code "by default"
<dkubb>
the only warning I have to someone who's never done it is don't get discouraged. mutant will find 10x more bugs in your code than you ever imagined
<dkubb>
if you think it'll find 10 bugs, it'll find 100 or 200. literally
<dkubb>
yeah, it also helps you learn how to write better tests
<xybre>
I don't know if I'd count that as bugs, lack of test coverage sure..
<dkubb>
I wasn't talking about code coverage really
<dkubb>
sure, it'll help find uncovered code, but I don't even bother to run it until I've reached 100% coverage on a specific block of code
<dkubb>
then I mutation test it, and make sure all the edge cases work as expected
<xybre>
I'm curious to see what you test suite looks like.
<xybre>
(after all that)
<dkubb>
even after all that, it's not perfect. we're still improving the whole process. I'm happy with some of the tests but not all. a few places I had to test a bit more invasive than I wanted
<snusnu>
xybre: i've seen a few mutations that will typically not be "bugs", e.g. because if you were to use your own code wrong, the app wouldn't boot for example .. apart from that, once a code path is reachable, and that path contains uncovered code, it may not be a bug per se (because it could still do the right thing), but you surely can't be sure about that ;)
<dkubb>
but we're looking at changing things up a bit so that only our documented public api requires tests, and everything else is covered implicitly by the other methods' tests
<snusnu>
xybre: that said, i'm probably not in the camp that thinks that any old application absolutely needs full mutation coverage .. but i truly think that every library (especially ones that are as foundational as rom, let alone axiom) should be fully mutation covered
<snusnu>
people loose so much time tracking down bugs in oss code bases they are not familiar with ....
<dkubb>
yeah, I wish we had done this with DM
<dkubb>
every library I've done mutation testing with, starting in 2009, has been significantly less overhead to manage
<dkubb>
it's not all panacea of course. it does take more effort
<dkubb>
but I don't really want to slap together this project, like most similar projects are.. I want to do something different
<dkubb>
there's no point in doing it if I'm not going to experiment with a different approach from what I did the first time around ;)
<xybre>
I wrote a little database helper (right on the pg gem) and it was a nice, using datamapper in projects is nice too. Using ActiveRecord is fine, at least for the first 2 weeks, after that is not nice at all. So, I'd just really like to no have to write everything by hand.
<xybre>
I don't have NIH Syndrome, I swear. I just want a good toolset.
<snusnu>
dkubb: btw, i want it to be as easy as possible to run mutant on integration tests too … i found that during development, rspec-dm2 or not, sometimes full mutation coverage makes you slower, and worse, more "afraid" to refactor … while code is heavily in flux, sometimes even unit specs themselves (mutation covered or not) are too much
<snusnu>
dkubb: once it gets near a release, i'd always add full mutation coverage of coure
<xybre>
Yeah, a heavy test suite discourages refactoring.
<snusnu>
like with the latest substation refactorings … it literally took me 30min to add a feature, then 4h adjusting the tests
<snusnu>
at the end of the day, it's still worth it i guess .. because inside my app, i *know* that substation won't be the problem .. but yeah, while working on substation itself, it sometimes was demotivating
<xybre>
It seems to be challenging to strike a good balance there.
<snusnu>
yeah .. i guess it's a matter of the process … and it will surely improve when mutant improves in that area .. the "bad" thing with not having it mutation covered all the way, is that mutant will find *that* many things, that if you have a reasonable amount of code, it will take you *a lot* of time, to get to 100% mutation coverage
<snusnu>
and i must still admit that i'm not the kind of guy who actually likes to *write* tests, i only like to have them :p …. so getting from low to 100% mutation coverage sure promises to be a rather boring time :)
<snusnu>
so yeah, striking the balance is kinda hard
<snusnu>
but the decision is somewhat easier with libraries .. as i know exactly what i want .. 100% mutation coverage … with apps, the decision maybe even harder, because you'll probably want to find the right percentage you're happy with
<xybre>
The more fingers in the pie, the more important tests are as well. I use them as a form of alternative documentation, so it helps show how things work and should be used. A lot of people don't write tests like that though.
<snusnu>
that's true yeah, nothing's better than looking at tests when it comes to understanding what some code does .. given there are (good) tests of course
snusnu has quit [Quit: Leaving.]
machuga is now known as machuga|away
<dbussink>
we have lchown in rubinius
<dbussink>
so if it doesn't work, that sounds like a bug to me
mbj has joined #rom-rb
zekefast has joined #rom-rb
mbj has quit [Ping timeout: 248 seconds]
mbj has joined #rom-rb
postmodern has quit [Quit: Leaving]
mbj has quit [Read error: Connection reset by peer]
zekefast has quit [Ping timeout: 276 seconds]
zekefast has joined #rom-rb
snusnu has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
mbj has joined #rom-rb
<dkubb>
mbj: I was looking at csv parsing today for a theoretical csv adapter
<dkubb>
I just had my first real-world user of axiom say he uses it all the time for processing csv files
<dkubb>
like at a user-group
<dkubb>
I obviously know people using it online, I hadn't gotten to the point yet (like with DM) where people would say "oh yeah I use that"
<dkubb>
I saw a bunch of gems that use ragel to parse, and a few that use C
<dkubb>
the funny thing about the C one is that it flips back and forth between C and ruby.. it uses ruby to read the next line, and then uses C to parse the line. I wondered why it doesn't just read the file in C, parse it, and yield each line back to ruby
<dkubb>
that'd surely be faster, wouldn't it? I mean, it's like 95% of the code in C anyway
<dkubb>
what I would want in a csv parse is something that can yield each line as it's read, so that I can use axiom's pipelining system to process things on-the-fly, rather than buffering things
<dkubb>
yeah, I've seen this. I didn't recognize the title
<mbj>
It should be mandatory for all coders.
<dkubb>
mbj: I finished up the axiom-memory-adapter yesterday
<dkubb>
mbj: now i'm starting on nest/unnest
<dkubb>
or at least I will be tonight
<mbj>
dkubb: nice, awesome!
<mbj>
dkubb: I have to come back to axiom and latest rom code.
<mbj>
My OSS time budget is currently consumed by mutant.
<mbj>
And I thin it is a good choce to spend my time here to help rom.
<mbj>
s/thin/think/
<dkubb>
yeah
<dkubb>
I think mutant is really important
<dkubb>
I would like to do some more work on axiom-fuzzer too
<dkubb>
I probably will beef it up once I get nest/unnest in, because I would want to fuzz it all
<dkubb>
what would be sweet would be to take the axiom-sexp ast, and bring it closer to the parser ast, so that we can use some of the mutations in mutant
<mbj>
I think this is possible.
<dkubb>
I don't think all of them will overlap, but there may be some overlap
<mbj>
dkubb: pls beware, axiom-fuzzer is FAR from being well refactored.
<dkubb>
the main difference is we're using the mutation to just find changes to existing expressions
<dkubb>
that's fine
<mbj>
I took your code and improved it a bit and made it adapter agnostic.
<dkubb>
mbj: I expect I will probably update it alongside nesting
<dkubb>
obviously I'll test and mutation test nesting, but even that's not enough
<mbj>
yeah
<dkubb>
I'd like the fuzzer to eventually be able to test writes too
<mbj>
I'd love to support nest/unnest in axion arango adapter, IMHO the query language can do this natively!
<dkubb>
nice
<dkubb>
I think postgresql may be able to as well
<dkubb>
or at least in a limited capacity
<mbj>
Have to talk to arangodb guys. Maybe they can sponsor me again.
<mbj>
yeah, postgresql can do it, but I think arangodb would support it "en full".
<dkubb>
yeah, no doubt updating the fuzzer will help find more bugs in the db too
<dkubb>
the fuzzer only probably covers like 20% of the cases it could too.. there's tons more it could be doing
<mbj>
yeah
<mbj>
moving back to barbecue, cu later.
<dkubb>
what I would love to do is somehow measure the fuzzer "code coverage" in axiom, axiom-optimizer and axiom-memory-adapter and bring it to the point where it can cover 100% of the cases
<dkubb>
kk
<dkubb>
maybe even do some mutation testing w/the fuzzer if that makes sense
<dkubb>
mbj: one idea I had would be to take axiom, zombiefy it so I have Zombie::Axiom, then mutate one piece of the code in it, and then run Axiom against Zombie::Axiom in the fuzzer
<dkubb>
mbj: the idea would be to verify if a specific piece of code is being exercised by the fuzzer. if it never breaks after a specified time (we'd need a timeout), then it's uncovered
<dkubb>
mbj: it's really high level, more like something even above an integration test, and I'm not sure if it's a good idea or not because it may be slow, but I was trying to think of ways to measure how much of axiom and the adapters the fuzzer covers
<dkubb>
ideally the fuzzer will eventually handle every possible node
<dkubb>
I suppose a subset of the fuzzer, whatever is responsible for mutation, could somehow be used to run the specs under
<dkubb>
it could modify every relation, run it's tests and see if the modification results in unexpected results. no failure would mean it's uncovered
<mbj>
dkubb: that is a really good idea!
<dkubb>
I'm just trying to think of ways we can eventualy identify parts the fuzzer isn't covering
<mbj>
dkubb: And easy to implement.
<mbj>
Heh it is really nice how "verbs" like zombify made it into our communication.
<dkubb>
right now, it's probably easy to identify because it's only a small subset. but as we go further, it will get harder
<dkubb>
:)
<mbj>
We need to have a talk about how we test our code.
<mbj>
I think we are in the top 1% of opensource projects, when it comes to testing.
<mbj>
dkubb: Yeah, AFAIK sqlite is the best tested lib out there.
<mbj>
And yes I read this document years ago and rereadit once in a while.
<mbj>
Even before I particiapted here :D
<dkubb>
what I'm really curious about is how our testing process will translate to the real world
<dkubb>
like when this stuff is in full use by the general public, will it mean much less reported issues
<dkubb>
or will the issues reported mostly be on usability and documentation, rather than actual software bugs
<dkubb>
as real bugs are discovered, we should of course write a failing test and fix it; but I think we should add an extra step to see if mutant could have introduced a mutation that would've exposed the bug. we should also look to see if the fuzzer could've done something to expose it
<mbj>
I have mutation covered libs in production
<dkubb>
that way we not only fix the bug, we find ways to identify whole classes of similar bugs elsewhere
<mbj>
And I never received bugs report, aparts from bugs I specified :D
<dkubb>
I have in limited cases
<dkubb>
some parts of dm-core actually
<dkubb>
those parts I never hear abiout
<mbj>
yeah
<mbj>
dkubb: does rubocop has something like "--fail-fast" ?
filipvanlaenen has joined #rom-rb
<filipvanlaenen>
Hi!
<mbj>
filipvanlaenen: hola
<mbj>
What kind of problems you have running mutant?
<filipvanlaenen>
When I try to run mutant on the project I referred, I do this: mutant '::LargeBinomials::LargeFloat' --rspec-unit
<filipvanlaenen>
And that throws the following error: /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- large_binomials (LoadError)
<mbj>
can you show me your spec helper?
<filipvanlaenen>
I tried to use -I lib, but the I option isn't allowed any more.
<mbj>
spec_helper.rb to be specific
<mbj>
yeah, I expect your test suite (rspec) will load the libs, and all your tests have a "require 'spec_helper'"
<dkubb>
mbj: feel free to just copy over the one from axiom if you want. you'll want to adjust the LineLength Max of course
<mbj>
dkubb: yeah
<mbj>
What about 1.8 hashes
<mbj>
should we accept them?
<mbj>
I like :foo => :bar more than foo: bar
<mbj>
I like :foo => :bar more than foo: :bar
<mbj>
dkubb: This is a general question for rom code
<dkubb>
mbj: I use 1.9 style hashes
<dkubb>
mbj: in some cases it's odd, but for the most part I think it looks nicer
<mbj>
dkubb: mhh, we should sync this.
<mbj>
dkubb: I hate foo(bar: :baz)
<mbj>
dkubb: Sure this does not happen often.
<mbj>
dkubb: foo(:bar => :baz) looks so much more nice.
<dkubb>
mbj: I've been trying to follow as many of the rubocop recommendations as possible. if I really disagree with it, I will update the config, but if I'm on the fence I just accept it for now
<dkubb>
mbj: I don't think it's significantly nicer. with syntax highlighting it's not much different
<mbj>
dkubb: they prefer && over and, without our control flow rule.
<dkubb>
mbj: yeah, although it's rare to use "and"
<dkubb>
mbj: most of the time I'd use "or" for control flow
<mbj>
dkubb: I hit "and" for control flow often.
<dkubb>
like in: statement or raise Something
<dkubb>
oh yeah?
<dkubb>
I don't seem to for some reason
<mbj>
if some_condition and another_one
<dkubb>
that's a boolean
<mbj>
Yeah
<mbj>
Yeah!
<mbj>
for some reason my brain made if => control_flow
<mbj>
sure this is a boolean.
<mbj>
heh, now I dont have "and" in control flow :D
dkubb|away has joined #rom-rb
<dkubb|away>
I would use and in this case: variable = statement and variable.process and variable.finalize
<dkubb|away>
not that I would do it very often
<dkubb|away>
in fact, *most* of the time I would not use this
dkubb|away is now known as dkubb1
<dkubb1>
argh, I can't use the nick because I got logged out
dkubb has quit [Ping timeout: 245 seconds]
dkubb1 is now known as dkubb
<dkubb>
mbj: thanks for the link to that presentation
<dkubb>
it's nice to see people who have an interest in mutation testing using the tool
<dkubb>
especially when they have experience with the other tools
<mbj>
yeeah
<dkubb>
if he gave a presentation about it, he's especially interested. that's precisely the kind of person who gets involved with the project ;)
<mbj>
I see it the same way.
<mbj>
I thing he'll love mutant
<mbj>
Especially once I find the time to add the "longest prefix match rspec killer" :D
<dkubb>
yeah
<mbj>
That thing + preloading of the world will fix 95% of user problems.
<mbj>
that 5% is postmodern with is demand for making a flag to disable "return foo" => "foo" :D
<mbj>
s/is/his/
<dkubb>
heh
<dkubb>
I would wait for 5+ requests before adding something I disagree with
<mbj>
mhh, true.
<mbj>
But he is a good reporter of problems. So investing some time to help him adopting it for his ronin project will result in good feedback.
<dkubb>
yes, that's true
<dkubb>
he's awesome at that
filipvanlaenen has joined #rom-rb
<filipvanlaenen>
Hi again.
<filipvanlaenen>
Got a little question about mutant again.
<filipvanlaenen>
I subclassed Integer, and mutant started mutation /usr/lib/ruby/1.9.1/openssl/bn.rb.
<filipvanlaenen>
Is it possible to turn it off to go outside my code?