<snusnu>
dkubb: anyways, wdyt wrt the mutation? is it killable?
<snusnu>
dkubb: fwiw, unparser did a good job, that's the *only* thing different from your proposal in the issue || => |_|
<dkubb>
I think it would only be killable with a method expectation
<snusnu>
right
<snusnu>
and for some stupid reason, i didn't think about that
<dkubb>
:)
<dkubb>
I think it's good to think about how to kill something before reaching for that
<snusnu>
but yeah, strictly speaking a very useless method expectation
<dkubb>
I would rather kill it with "real" state than something like that
<dkubb>
use it as a last resort
<snusnu>
yeah
<snusnu>
the thing is, the logic "around it" forbids any other length for the array
<snusnu>
oh no it doesn't
<snusnu>
oh yes it does .. it can be 0
<dkubb>
we don't *have* to use Array#fetch either
<snusnu>
is there something like tuples.first ?
<snusnu>
lemme just try, sorry
<snusnu>
oh heh, we need the block
<dkubb>
tuples.shift || block.()
<snusnu>
sorry, it's late already :p and i came home from a few glasses of wine heh
<dkubb>
hehe
<dkubb>
YEAH DRUNK CODING!!
<snusnu>
hah! yeah! .. sometimes that's nice
<dkubb>
actually tuples.first is better
<dkubb>
not tuples.shift
<snusnu>
so no "or" instead of || here? ;)
<dkubb>
actually or may be better
<snusnu>
heh, so: block.() => 0 instead of 1 args error … block.call(tuples) => 1 instead of 0 error ….. block.call() => 0 instead of 1
<dkubb>
snusnu: can you paste the actual method?
<snusnu>
dkubb: sorry, my mistake, works now
<snusnu>
dkubb: i nuked the |_| in the first line to verify what i said before about the argument error .. then forgot to add it back
<snusnu>
mutant running ...
<snusnu>
dkubb: sweet, all mutations killed
<snusnu>
dkubb: thx for the help1
<dkubb>
no problem
<dkubb>
this is probably more straight forward anyway
<snusnu>
hm, i was about to say i like the #fetch better, but yeah, it involves the magic number, so yeah, tuples.first or block.call(tuples) is better
<dkubb>
do you think we need to yield tuples?
<dkubb>
I was thinking just tuples.first or block.()
<dkubb>
I thought about this, but I don't know if we even need the tuples in there
<snusnu>
dkubb: yeah, but for some reason, there's this argument error 1 for 0 if i do || instead of |_| in the default block in the first line
<snusnu>
wait, we don't use fetch anymore
<snusnu>
lemme check
<snusnu>
dkubb: ok fixed
<snusnu>
dkubb: do you strongly prefer block.() over block.call ?
<snusnu>
dkubb: looks weird, but kinda cool, heh
<dkubb>
no
<dkubb>
I don't have any specific preference
<dkubb>
I guess it was added to the language, so I don't have a problem using it
<snusnu>
dkubb: heh i messed up history a bit ( ;) ) … the diff is dirty because i forgot to remove the previously commented old code :/
<snusnu>
dkubb: now if i go force push it, it would be somewhat inconsistent with what i said earlier today evening hah
<snusnu>
dkubb: oh actually no, it's fine .. heh
<snusnu>
sorry for the noise ...
<dkubb>
haha
<dkubb>
don't feel self concious
<dkubb>
most oss history is fine. I've worked before where it was all crazy
<dkubb>
commit messages like "Fixed"
<dkubb>
you've got an extra space in "or block" ;)
<dkubb>
I bet you anything that #one will become used quite a lot
<dkubb>
I stole it from SQL Alchemy
<snusnu>
heh thx, fixed
<snusnu>
yeah, i can already see me using it a lot
<snusnu>
just to make sure you got me right before, by saying "oh actually no, it's fine" .. i was referring to the commit being fine, not dirty .. not the force pushing ;)
<snusnu>
dkubb: btw, i was thinking of some sort of "pattern" wrt DSLs and immutability … i will refactor substation to have both Definition and Definiton::Mutable classes for the Environment and the Chain dsl classes
<snusnu>
Definition::Mutable will be used during "collecting phase" .. and instead of finalize, a Definition will be returned from the dsl builders
<dkubb>
ahh I see
<dkubb>
heh, when do you actually sleep? :)
<snusnu>
i expect that to be usable in rom's dsls too
<snusnu>
lol, i asked myself the same question ..
<snusnu>
it's crazy hot around here … and i'm a night owl anyway
<snusnu>
altho, one could probably say it's daytime already, heh
<snusnu>
also, fwiw, i won't start that refactoring now, i definitely need sleep before that ;)
<snusnu>
but it seems like a fitting pattern, 2 places in substation where it's applicable, and rom's schema and mapper DSLs could use it too
<dkubb>
hmm, I don't think I've ever seen this before: stub(relation).take(2) { [user1] }
<snusnu>
dkubb: that's bogus, and accidentally the reason i even started to rom code
<snusnu>
dkubb: i wanted to try it out, solnic really likes it
<snusnu>
well, it took me a few extra minutes to look up the stuff, but yeah, currently i'm just familiar with the syntax, and i like it … i haven't yet gotten to "feel" the real advantages
<dkubb>
ok, I just added sort() and reverted that change that allows sort_by to not accept anything
<snusnu>
like, bogus will yell at you if you stub non-existing methods, and it can be configured to yell at you if you haven't written any "contract tests" .. those are tests, that test wether your stubs, when not stubbed, actually return what you stubbed ;)
<dkubb>
I'm going to add one() tonight I think
<snusnu>
sweet
<dkubb>
oh wait,it's there already
<dkubb>
haha
<dkubb>
I've got to make it so it uses fetch though
<dkubb>
er the block syntax
<snusnu>
hah yeah, now that you say it, i remember delegating to it already, back then with dm-mapper
<dkubb>
I'm glad I forgot because it made me think about the interface with a fresh pov
<dkubb>
I might've just said it was good enough if I knew about it
<snusnu>
heh yeah
<dkubb>
I like the block syntax. I find myself using Hash#fetch all the time
<snusnu>
yeah me too, it avoids hardocding errors, or using standard ones
<snusnu>
btw, i read a discussion between you and solnic wether axiom should live under the rom-rb org (iirc) .. wouldn't it be better for axiom to have its own org?
<snusnu>
while rom uses it, it is a full infrastructure on its own, in no way tied to rom
<dkubb>
yeah
<dkubb>
I'm still not sure yet
<dkubb>
I could move it under an axiom-rb namespace on gh
<dkubb>
I kind of like it under dkubb though :)
<dkubb>
otoh, I do agree with you, we need to keep it decoupled
<dkubb>
I want us to agree to a common interface, but then other than that have both sides evolve independently
<snusnu>
yeah, that's important
<snusnu>
and i do get your point re dkubb/axiom
<snusnu>
the most important thing to me is that rom-rb seems like the wrong place for it
snusnu has quit [Quit: Leaving.]
dkubb has quit [Quit: Leaving...]
dkubb has joined #rom-rb
dkubb has quit [Quit: Leaving...]
dkubb has joined #rom-rb
solnic has joined #rom-rb
<solnic>
dkubb: morning
<solnic>
dkubb: re #one, I didn't forget about, it's on my todo list
<solnic>
feel free to hack on it if you want of course
<dkubb>
solnic: I think snusnu added it for you
<solnic>
uhm yeah I just noticed
<dkubb>
solnic: I updated the axiom side to match
<solnic>
sorry, it was hard to follow all those discussions before the coffee :D
<dkubb>
you may be able to simplify the ROM side down maybe, not sure
<dkubb>
hehe
<dkubb>
I guess it also depends on if you want to catch axiom exceptions and rethrow them as ROM exceptions
<solnic>
dkubb: any progress with that #update interface
<solnic>
?
<dkubb>
solnic: no, not yet. been working on nesting on and off in between other stuff
<solnic>
dkubb: right now #update in rom-relation is broken
<solnic>
it only works in rom-session
<dkubb>
ahh ok
<solnic>
I kinda want to get it fixed before 0.0.1
<dkubb>
I probably won't start on update until group/ungroup is working
<dkubb>
the first version of update will probably just include the hash based interface. I think I can use a header object to carry the set of attributes to update and the functions to apply to the attributes
<solnic>
dkubb: the problem is that rom-relation operates on objects
<solnic>
so, its update method receives an object
<solnic>
you don't know the previous state
<solnic>
you just get an object
<solnic>
so, axiom could find the tuple using keys and update it
<dkubb>
and just use it's key?
<solnic>
that's how I imagine it, otherwise I cannot imagine it to work
<dkubb>
that does assume the key can't change, which isn't really a valid assumption if someone is using a natural key
<solnic>
well, I can remove update interface from rom-relation
<solnic>
and have it only in session
<dkubb>
I might do that temporarily
<dkubb>
let's figure out the interface and then propagate it up
<dkubb>
er, I mean, I would do that if I were you
<solnic>
or change it so that it accepts previous state (old tuple) as the second arg
<dkubb>
then we can start to think about how it should work
<solnic>
which is basically what I did in session
<dkubb>
in axiom, the update statement was going to be applied to the relation
<dkubb>
so you have a relation and you provide an update statement that is applied to every tuple in the relation
<solnic>
something like "update all tuples which matches this criteria"?
<snusnu>
mbj: i guess i couldn't offer much more than a +1, which, given that i'm a rom team member, would not be very surprising for the rubocop maintainers
<mbj>
snusnu: Maybe you find another worlding that convinces them. Rememer you are my README hero :D
<mbj>
*remember
<snusnu>
hah
<snusnu>
i can't beat dkubb tho, he's the one with the solid arguments :p
<mbj>
heh
<mbj>
Sometimes I'm so lazy with solidification of my arguments. Cant beat dkubb here.
<mbj>
I try with code, but I'll never compeate with his comments :D
<snusnu>
mbj: i was somewhat surprised btw that you said substation relies heavily on class injection, when it does not … it relies on "interface injection" as you said (it reminded me of java interfaces, something i always liked)
<snusnu>
mbj: there's nothing stopping you from injecting everywhere the current demo app injects classes
<mbj>
snusnu: Defining a memoizer on this class later will blow
<snusnu>
mbj: yes we are, but not because substation requires it, but because it seems feasible from an app's pov
<snusnu>
mbj: oh wait
<mbj>
snusnu: Yeah, as I said, this is not substations fault.
<snusnu>
heh, the Wrapper is in fact an exception
<snusnu>
it requires .new
<snusnu>
or #new
<snusnu>
heh
<mbj>
it is not subsations fault
<mbj>
This will happen over and over again
<snusnu>
yeah
<mbj>
And instead of taking care at all points of my program that uses deep freeze, "not to freeze a Class instace" there, I'd love to move this to the root. ice_nine in this case
<snusnu>
and there's nothing wrong with doing it .. i like how you called that "interface injection" .. it really is a different concept at work
<snusnu>
mbj: agreed, would be nice to have
<mbj>
snusnu: yeah
<snusnu>
oh nice, i was just starting to type "mbj" .. did it in the wrong window, and now i know that pressing m makes GH pop up markdown help
<mbj>
I hope I can take more load for rom later this month
<mbj>
I was absent in discussions and backlog consumption the last 4 weeks.
<snusnu>
no worries about that, good things need time
<mbj>
And code.
<mbj>
But at least I torture the rest of the team with mutant :D
<snusnu>
hah, we wouldn't wanna live without that anymore
<snusnu>
mbj: but yeah, got a minute re that substation thing removing the requiremnt for so many consts?
solnic has joined #rom-rb
<solnic>
snusnu: yo
<snusnu>
mbj: i think i'm on the right track, but i don't like the api
<snusnu>
solnic: yoyo
<solnic>
snusnu: sorry for bringing this up again
<solnic>
but...can you remind me why there's value in building a pure axiom::relation/relation::base schema?
<solnic>
as in, no adapter gateway proxies, just pure axiom relations
<snusnu>
because of users that don't need mapping? reporting etc?
<solnic>
no, that's not what I mean
<solnic>
we build schema with pure axiom relations
<snusnu>
well, it'd need an adapter, but no mapper .. schema should be ubiquitous
<solnic>
they are in memory only
<solnic>
only base ones
<solnic>
and it's kinda bugging me right now
<solnic>
cause I don't see any value
<solnic>
according to what you wrote
<solnic>
you actually want them to be adapter gateway relations
<snusnu>
yeah
<solnic>
as in, relations w/o mapping
<snusnu>
that's more precise yes
<solnic>
which I totally agree is valuable
<snusnu>
yup, then we're on the same page
<solnic>
ok good
<snusnu>
i didn't express myself precise enough
<solnic>
I knew something was not right :)
<snusnu>
heh
<solnic>
ok, I'm gonna go and do that now :)
<snusnu>
nice!
<solnic>
snusnu, mbj: got a good name for mapped relations registry?
<solnic>
"schema" is used for non-mapped relations
<solnic>
maybe just Environment.registry
<snusnu>
solnic: ok, so bear with me for a minute, i thought of a DSL/registry idea/pattern yesterday
<solnic>
with a Environment#[] shortcut
<solnic>
snusnu: oh ok and?
<snusnu>
i want to have Data and Data::Mutable objects, where the Data::Mutable is used during "collecting phase" of the DSL, and instead of #finalize, the actual DSL class wraps the Data::Mutable in Data when asked for the collected data … Data would not expose any writer, and encapsulate a frozen Data::Mutable
<snusnu>
solnic: i brought that up, because those basically are the registries
<snusnu>
solnic: i will do that in substation in 3 places, and i think it'd fit for rom too
<solnic>
snusnu: yeah I started seeing a pattern too
<solnic>
didn't see it clearly yet though
<snusnu>
i will try to implement what i just said in substation today or tomorrow, it seems totally fitting … it also allows for using the DSL in multiple files
<snusnu>
and no #finalize is needed
<solnic>
yeah I don't want finalize
<snusnu>
when the DSL instance is asked for the data it collected, it just wraps it in the immutable Data object
<solnic>
in fact, I already removed it hoping it won't come back
<snusnu>
yeah, i want to come up with other ways too
<snusnu>
we needed it in dm-mapper, but i guess we won't with rom
<solnic>
yeah
<snusnu>
we won't build so much upfront eventually, for relationships, i guess
<solnic>
no :)
<solnic>
damn this was one crazy son of the bitch, that dm-mapper you know
cored has joined #rom-rb
<snusnu>
lol yeah! when i see rom code now, i'm like, dude, wtf were we even thinking
<snusnu>
:D
<cored>
morning
<solnic>
snusnu: buhahaha word
<solnic>
snusnu: I say that to myself every single day
<solnic>
but yeah, that's how it works, you experiment, you learn
<snusnu>
otoh, it's easy to say, we have no relationship concepts yet .. but yeah, i'm almost certain we won't end up having to write so much crazy code
<solnic>
morning cored
<snusnu>
yup
<solnic>
no we won't have to, it'll be much simpler
<solnic>
snusnu: not sure if you noticed but I simplifed rom-mapper by using axiom's rename feature
<solnic>
so basically a mapper renames and projects a relation
<solnic>
and that's it
<snusnu>
i found it particularly nice, when lukesutton (the guy who designed the dm1 page) said, he was like, what? that's all there's to it? :D
<snusnu>
solnic: yeah saw that, and like it *very* much
<solnic>
so entire "mapping attribute names" thing goes away
<solnic>
snusnu: I must've missed that :)
<snusnu>
yeah, i didn't really get it back then with dm-mapper, but that was just because it wouldn#t have been possible with dm-mapper
<snusnu>
with dm-mapper, i thought about hacking/injecting axiom evaluator context to achieve the same thing
<snusnu>
solnic: lukesutton said that he was really surprised how so "little, simple" code can do so much :p
<solnic>
snusnu: when did he say that?
<snusnu>
solnic: a few days ago, and don't quote me on that .. but yeah, iirc it was the day before yesterday
<solnic>
kk
<solnic>
yeah he wanted to chat with us
<snusnu>
dkubb and him were also talking about using raw axiom (memory adapter) to do some cross repo reporting they need to do .. axiom should be all set for their usecases already
<solnic>
snusnu: reading the logs and grinning
<snusnu>
heh
<solnic>
snusnu: btw there's one caveat now with registry
<solnic>
you have to have unique names for all relations
<solnic>
those are not scoped withing repositories
<solnic>
within even
<solnic>
so you can't have 2 relations named :users even if those are in 2 separate repositories
<solnic>
personally I think that's how it should be, right?
<snusnu>
solnic: and that's a good think imo
<solnic>
right?
<solnic>
RIGHT?
<solnic>
geeez thanks
<solnic>
:D
<snusnu>
heh
<snusnu>
db_1.users db_2.users wouldn't surprise you in sql land ;)
<snusnu>
hence, 2 names
<snusnu>
of course all distinct relations need to be accessible with a unique name
<snusnu>
it's no limitation, it's an, can i say that, axiom
<solnic>
huh right
<snusnu>
btw, where are we wrt to self joins in rom? all good, but needing manual renaming i guess?
<snusnu>
i can't remember if that worked with dm-mapper an axiom engine
<solnic>
snusnu: no automation
<solnic>
in general
<snusnu>
yeah, then it works
<snusnu>
good
<solnic>
there is no automation for joins
<snusnu>
good
<solnic>
so, you do it manually
<solnic>
once group/ungroup is done
<solnic>
we can easily add support for loading children via mappers
<snusnu>
yeah, can't wait
<solnic>
me too
<snusnu>
mbj: btw, if you won't talk to me about that substation, i'm gonna force apis on your code … just sayin' … :p
<snusnu>
solnic, mbj: btw, did you guys read about my suggestion to add a "devtools jc" task?
<solnic>
snusnu: jc?
<solnic>
nope
<solnic>
where is it?
<snusnu>
even if you haven't, you should be able to figure out what that does
<snusnu>
lol
<mbj>
snusnu: sorry, no time :D
<solnic>
snusnu: sorry no idea what it would do
<snusnu>
solnic: ok, so jc stands for james cameron, so what would it do?
<solnic>
I knew it
<snusnu>
hah
<solnic>
:)
<snusnu>
the idea was to run our metrics with devtools passing adjusted threshold to the tools
<snusnu>
so that they would show the currently "edgy" code
<snusnu>
thus, supporting to raise the bar
<snusnu>
thus jc
<snusnu>
:D
<solnic>
it would be epic
<solnic>
I want to add it
<solnic>
:D
<snusnu>
yeah me too hah
<snusnu>
it'd be simple, read configs, adjust thresholds down by 1 in memory, pass it along to flay/flog
<snusnu>
then devtools jc would print out the code right at the edges of what we accept
<solnic>
snusnu: my biggest priority in devtools now is to figure out how to use yardstick in a sane way, it has a neat config but it doesn't work
<solnic>
snusnu: I want to call ROM alpha "The James Cameron Release"
<solnic>
:P
<mbj>
snusnu: +1
<mbj>
Another one should be "Zombie vs Mutants" :D
<mbj>
Or "The X-Men" :D
<snusnu>
heh
<snusnu>
i dunno, maybe "The James Cameron" release would be suitable for a 1.0
<solnic>
right
<solnic>
true
<snusnu>
"The Jersey Thing" would be fitting for the first alpha
<snusnu>
:p
<mbj>
snusnu: anima attributes are protected with include Anima.new(:foo, :bar) what about Anima::Public(:foo, :bar) ?
<solnic>
buhaha
<mbj>
hehe
dkubb has joined #rom-rb
<snusnu>
mbj: tbh, i thought it worked like that already?
<snusnu>
mbj: i mean, attrs being public?
<mbj>
snusnu: mhh
<snusnu>
mbj: concord has Concord::Public for that
<mbj>
snusnu: I thought so
<mbj>
snusnu: But just got a visiblity exception on an anima infected class
<mbj>
dkubb: hola
<snusnu>
mbj: i wonder, when would dto's with protected readers *ever* be feasible?
<mbj>
snusnu: my fault
<mbj>
snusnu: I overwrote that stuff in another mixin
<snusnu>
heh ok
<dkubb>
good morning
<mbj>
snusnu: But what having an Anima::Protected ?
<snusnu>
morning dkubb
<snusnu>
mbj: where would u use it?
<dkubb>
mbj: we should just fork robocop and update the gem dependency. if the tests pass we can submit a PR
<snusnu>
yeah, fork it under rom-rb
<mbj>
ü1
<mbj>
s/ü/+/
<mbj>
german keyboard layout :D
<snusnu>
i knew that … ;)
<snusnu>
mbj: still interested when you would use an anima infected instance with protected readers ...
<snusnu>
mbj: i just can't see the usecase, maybe i'm missing something obvious
<mbj>
snusnu: complex method objects
<mbj>
snusnu: *that should be refactored :D
<snusnu>
haha
<snusnu>
interesting tho, for some reason, i never thought about using anima outside of a "dto scope"
<snusnu>
mbj: wdyt about introducing Substation::Response::Exception with #success? => false, #exception? => true plus adding #exception? => false to Response:.{Success, Failure}
<snusnu>
mbj: i could then move Chain::FailureData to Response::Exception::Data and have a general way to distinguish "bugs from logic errors"
<snusnu>
mbj: chain invocations would then *always* return one of Response::{Success, Failure, Exception}
<snusnu>
mbj: currently, also exceptions lead to Response::Failure, which is kinda misleading
<snusnu>
mbj: a failure indicates a business logic error, an exception indicates a bug in the code
<mbj>
snusnu: +1
<snusnu>
good
<snusnu>
mbj: and then there is ONE more thing to add before the next release: a new processor type, Processor::Command::{Incoming, Outgoing} which simply invokes the given handler, and returns an unmodified request or response
<snusnu>
mbj: e.g. Processor::Command::Outgoing could be used to register a handler that implements some sort of "catch all" observer, as the last handler in a chain, potentially doing something important, "or" provide the callback mechanism useful for the hexagonal rails architecture linked by therabidbanana recently
<snusnu>
mbj: in general tho, that type of processor seems useful, it allows you to "step out of" regular chain processing, and do some common thing .. like logging a request or whatever
<mbj>
snusnu: PR :D
<snusnu>
mbj: oh you ...
<snusnu>
:p
<mbj>
snusnu: I'd love to see it in a PR to have a chance to comment it
<snusnu>
mbj: ok will do that (anyway) .. just wanted to hear from you in case you had any obvious objectsions
<mbj>
snusnu: it feels like observers.
<snusnu>
mbj: yeah, it has a resemblance to them
<snusnu>
mbj: not by accident can they be used for exactly that, a catchall observer
<snusnu>
mbj: generally tho, it's really just a (potentially unrelated) call "outside of" the regular chain processing
<solnic>
I'll refactor stuff to use this interface
<dkubb>
solnic: yeah, I was mostly just doing a first pass over the code before trying to understand it
<dkubb>
I find I kind of absorb what the code is doing just by looking at individual pieces first
<dkubb>
solnic: so when you do env = Environment.coerce(test: 'memory://test'), you create a schema inside that environment? I noticed in the env.schema block you have repository :test. I assume that corresponds to the key in the environment. can you specify multiple repository connection URLs?
<dkubb>
solnic: also, if there is only one repository specified, is the repository() command necessary or will it effectively default to the only Hash entry, again assuming there's only one there?
<dkubb>
solnic: also (sorry to bombard you) can I specify attribute :id, without a type and have it be the same as if I had just used Object ?
* dkubb
is going to pause the questions for a sec
<solnic>
dkubb: no worries
<solnic>
dkubb: ok soooo
<solnic>
first, you setup environment by passing repository config hash: Environment.coerce(test: 'memory://test')
<solnic>
this just sets up repositories hash inside environment using actual repository instances
<solnic>
then, you can start building your schema
<solnic>
this assumes all repos that you need are already configured
<solnic>
because once you specify a repo name for a specific base relation the schema builder will look up the repo instance to establish final relation object
<solnic>
if the repo isn't there it will crash with key error
<dkubb>
I wonder if some of the schema stuff can be pushed down to axiom
<solnic>
dude, you gotta left something for us ok? ;)
<dkubb>
it doesn't seem like much of it is mapper specific
<dkubb>
haha
<dkubb>
my goal is to make ROM a one-liner
<solnic>
rom will end up being 20 LOC class this way
<solnic>
LOL
<solnic>
ok!
<solnic>
;);)
<dkubb>
nah, I think object mapping and anything object related is totally for ROM.. sessions, anything that knows about the domain object should be ROM
<solnic>
I know I'm kidding :)
<dkubb>
but schema defintion.. I'm looking over it and thinking "man, this would be sweet to have to define axiom relations"
<solnic>
re attribute w/o types I believe it does default to Object, lemme double check
<solnic>
dkubb: so you're talking about having such dsl in axiom?
<dkubb>
yeah, I was wondering if that make sense
<dkubb>
the schema stuff
<solnic>
I'm not sure, maybe
<dkubb>
does anything in the schema block know about the domain objects?
<dkubb>
or is that all in the mapping blocks?
<solnic>
ROM's schema is a must have because it would be WAY too hard to get up and running with anything
<dkubb>
yeah, I agree. axiom's relation DSL was meant to be a minimal set of functionality, not what I expected the end user to use
<solnic>
dkubb: no, schema is just a dsl for building axiom relations and turning them into adapter gateways via Adapter#[]= interface
<dkubb>
plus I wanted to do things where the adapter can reflect on existing schemas and populate it's own internal schema
<dkubb>
that's cool then
<dkubb>
so we could push it down if we wanted I guess
<solnic>
you could literally copy and paste everything except the part related to repositories
<solnic>
yeah totally
<dkubb>
interesting
<dkubb>
and a repository is basically an adapter instance? does it have more state besides an adapter and a name?
<dkubb>
I realize I could just check the code but it's faster to ask :P
<solnic>
not really, repository has a name, an adapter and relation registry
<solnic>
those relations are the ones created via Adapter#[]=
<solnic>
gateways, basically
<dkubb>
ahh ok
<dkubb>
btw Adapter#[]= is supposed to return a gateway/relation variable
<dkubb>
er I mean #[]
<dkubb>
Adapter#[]= is supposed to take a relation and will wrap it in something adapter specific
<dkubb>
be it a gateway or a relation variable, whichever it needs
<dkubb>
the in-memory adapter doesn't need a gateway, but the rdbms adapter will
<dkubb>
or sql adapter, whatever we call it
<solnic>
well, that's what I meant by gateway, a relation wrapper that an adapter needs, or something
<solnic>
we gotta agree to a single word for that
<dkubb>
I would call it a gateway
<solnic>
sounds good
<dkubb>
I can make a gateway for axiom-memory-adapter that simply inherits from Relation::Variable, to keep things clear
<dkubb>
then you'll have something like Axiom::Adapter::Memory::Gateway that it returns
<solnic>
up to you, not sure if that's needed
<dkubb>
it probably won't hurt anything, and maybe it'll make things more clear (?)
<solnic>
yeah it would be in-line with other adapters right?
<dkubb>
every adapter would have to return a gateway object that does whatever that adapter needs
<dkubb>
yeah, we could establish that as a naming convention
<dkubb>
from the pov of someone using the objects they wouldn't need to care what is happening internally
<solnic>
btw should a gateway wrapping relation A == relation A?
<dkubb>
they'd just know the adapter author has it taken care of
<dkubb>
I think so
<dkubb>
== is a weaker form of comparison
<dkubb>
it's usually meant for equivalency
<solnic>
hmm cause variables don't == their relations
<dkubb>
not necessarily object equality
<dkubb>
oh really? hmm
<dkubb>
I think that is probably a bug then. I should think about the implications
knowtheory has quit [Quit: Computer has gone to sleep]
<solnic>
notice that I had to wrap relations with variables to make it pass
<solnic>
I expected it to just pass
<dkubb>
I think in general Relations in axiom will == even when they are different types, but the same data
<solnic>
rspec's eql does == under the hood right?
<dkubb>
btw, key() allows multiple arguments?
<dkubb>
no, eql uses #eql? .. you want eq without the "l" for ==
<dkubb>
eql? usually compares object type
<solnic>
shit
<solnic>
that's why it fails :)
<solnic>
so many years using rspec and I still can't remember
<dkubb>
hehe
<dkubb>
it's ok
<dkubb>
I don't think it's the best UI actually
<dkubb>
the names are too close
<dkubb>
I would prever equiv() or something
<solnic>
passed :)
<solnic>
pushed already
<dkubb>
solnic: so with key I can specify: key :name, :age, :ssn
<solnic>
yeah eq and eql *can* be confusing
<solnic>
dkubb: yes key accepts many args
<dkubb>
excellent
<dkubb>
one thing I wanted to do with axiom is have it so adapters can reflect on the schema, so that if you specify the connection string for an RDBMS, and then do: adapters[:users], assuming there's a users table, it could just return an axiom relation with all the types it reflected. of course you could overwrite it with a new one
<dkubb>
I see the need for a schema that sits on top of multiple adapters that makes them all resemble a single logical schema
<dkubb>
which I think is what you've been doing with ROM::Schema
<solnic>
yes
<solnic>
adapters should have ability to reflect the schema from the db
<solnic>
dkubb, mbj, snusnu: so, who wants to fork rubocop? :P
<solnic>
oops, gtg, bbiab
<dkubb>
I can fork it
<dkubb>
the one thing I need to add in the adapter interface is a way of finding out which relations an adapter knows about. I was thinking about adding #each and making the adapter Enumerable, and then you could iterate over them and do things to them
<snusnu>
dkubb, solnic: let's fork it below rom-rb, no?
<dkubb>
sure
<dkubb>
it should only be a temporary fork
<snusnu>
ah ok, i was confused for a sec, because solnic asked who would do it .. i was like, who cares, it'll be in rom-rb anyway
<dkubb>
well, I'll update devtools's shared Gemfile to use it too
<snusnu>
dkubb: also, i guess i'd strongly vote for pushing the "multiple adapter spanning logical schema" down to axiom .. especially after solnic's latest refactoring, which makes the schema basically a hash of gateways
<snusnu>
dkubb: it will be another step that will make sure that we don't accidentally tie that too close to rom
<dkubb>
yeah, it seems like something axiom needs anyway
<snusnu>
dkubb: when really it should be usable completely without rom
<snusnu>
dkubb: that the schema "belongs to" axiom is especially obvious with that schema reflection you were talking about … it must not need rom for that
<dkubb>
I can also independently refactor the adapter interfaces if the Axiom::Schema is the primary integration point to ROM
<snusnu>
yeah, good point
<snusnu>
dkubb: once i need some fun task, i'm gonna implement "devtools jc" unless someone beats me to it
<dkubb>
snusnu: heh
<dkubb>
snusnu: one fun task I want to do is port dm-ambition to axiom
<snusnu>
dkubb: i'd especially love to have it for reek .. it would need the most work, selectively mutating the reek config based on some command line switches … or maybe, we should even "mutate" the complete reek config automatically, printing out the stuff that needs adjustment
<snusnu>
dkubb: yeah, axiom-ambition would be nice to have
<snusnu>
dkubb: with reek, i find that i tend to forget to remove exclusions, or adjust max_* threshold back when i fixed something .. because reek has nothing built in that warns about those cases
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] dkubb/adamantium#94 (master - 4221713 : Dan Kubb): The build was broken.
<dkubb>
mbj: hmm, it looks like rubocop fails with the latest parser. did you want to try your hand at upgrading it and fixing some of the spec failures?
<mbj>
dkubb: want yes, time no :D
<dkubb>
mbj: ok, I'll try to do it later today after work
<dkubb>
I've got to run for now though, will bbiab
<cored>
snusnu: you mean to use devtools with Javascript?
<snusnu>
cored: no, devtools jc .. where jc is an abbreviation of james cameron .. a somewhat inside'ish joke, related to an awesome southpark episode in which james cameron is trying to "raise the bar"
<snusnu>
:p
<snusnu>
cored: what we're trying to do with rom, is exactly that, raise the bar
<cored>
he
<cored>
I don't tend to see that much tv :-P
<cored>
but I just notice where you guys start to be in the channel, so I have dkubb around for some stuffs regarding axiom
<snusnu>
cored: what devtools jc would do, is it reads your flay/flog config, adjusts the thresholds so that flay/flog would fail, printing out the offending code
<cored>
I haven't have the brain power to check out others part of rom
<cored>
interesting
<snusnu>
cored: so it would pass mutated thresholds to flay and flog, pointing us to potential places where we can "raise the bar"
<snusnu>
;)
<cored>
I installed devtools from rubygems, but it doesn't have the init command so I'm guessing I should use the development version
<cored>
right/
<snusnu>
cored: i always tend to "accept" the current thresholds, only looking at not making them worse .. with devtools jc, we could run that from time to time, and look at offending code, potentially refactoring it from there
<snusnu>
cored: yeah, always use devtools from master
<snusnu>
for now at least
<cored>
oki
<snusnu>
cored: you can very easily get the same effect like devtools jc by manually dropping flay/flog thresholds/total_score by 1 (or really any number) .. but yeah, it's "tedious" .. can be automated, and makes for a fun task to code, and a fun tool to have ;)
<snusnu>
cored: reek would be somewhat more involved
<snusnu>
cored: but even more interesting imo .. i always forget to remove previously offensive code from reek's "exclude" sections after i fixed it … or i forget to adjust reek's max_* settings per smell once i improved code
<snusnu>
cored: so it'd be cool if reek would warn for those cases .. like, you're excluding a method from a smell, but that method actually doesn't smell anymore .. reek should tell us that
<snusnu>
cored: maybe for reek, that'd be best implemented in reek itself tho
<cored>
oh
<cored>
snusnu: yes, probably
<snusnu>
cored: otoh, it might be simple to just write a reek runner, that mutates the config, runs reek, and sees if the output is different
<snusnu>
cored: doing that for every smell config, eventually printing out all the stuff that needs adjustment
<snusnu>
cored: it's basically just a helper to keep your reek config minimal and to the point
<cored>
snusnu: "Simple" hehehe
<snusnu>
heh :p
<snusnu>
i agree, it's probably a bit more involved ;)
<snusnu>
the others, flay and flog, would be dead simple tho
<snusnu>
iirc, devtools already invokes flay/flog via an object api, not the command line client, so really, it should be a matter of creating a new config object, mutating the threshods, and pass that along to flay/flog
<snusnu>
by creating a new config object i don't mean add any class or anything, just take the Devtools::Config::{Flay, Flog} instances populated during devtools boot, and create new instances from those, with adjusted threshold/total_score
<snusnu>
passing those new instances down to the tools
<snusnu>
then flay/flog will both do their regular thing, printing the warnings to stdout
<cored>
I want to see what devtools can do with a Rails app
<snusnu>
i want to see no rails apps
<snusnu>
:D
<snusnu>
srsly tho, it should be of great help, taming the beast
<snusnu>
hehe
knowtheory has joined #rom-rb
<cored>
:-)
<cored>
parser pre3
<cored>
dependecy mismatch
<snusnu>
yeah :/ we forked rubocop already for that reason
<snusnu>
they pin their parser dep to the exact version number, because they pretty much exercise every parser api
<snusnu>
the easy fix for now, is to remove rubocop and rubocop-guard from your Gemfile.devtools
<snusnu>
i dunno what state our fork is currently in, alternatively you could try to bundle rom-rb/rubocop .. but that still leaves out rubocop-guard
<snusnu>
what i did locally, is the easy fix i suggested to you
<snusnu>
so you'd sync devtools to get the latest and greatest deps, and then comment out the 2 rubocop gems
<snusnu>
from then on you can develop just fine
<snusnu>
for now
knowtheory has quit [Quit: Computer has gone to sleep]
theCrab has quit [Ping timeout: 240 seconds]
mbj has quit [Quit: leaving]
<cored>
cool
dkubb has joined #rom-rb
* dkubb
is about to dive into rubocop
<dkubb>
it shows 18 failures in the specs
<snusnu>
dkubb: when bumping to latest parser?
<dkubb>
yeah
<dkubb>
maybe I should bump to pre4 first, fix the issues then bump to pre5
<snusnu>
that might be worthwhile, yeah
<dkubb>
oh maybe not. there's an error in pre4 :(
<snusnu>
btw, i'm currently fighting a spec for (local) substation code, can't get it to pass, am stuck quite some time already, and i suspect it's all because that specific part, is not immutable :)
<solnic>
dkubb: not sure if return self in []= methods is such a good idea
<solnic>
Hash doesn't work like that
<solnic>
wdyt?
<solnic>
returning*
<snusnu>
dkubb: fwiw, i probably should've added that the failure i get is that there's no registered action named :test inside actions
<snusnu>
i just don't get it ...
<snusnu>
especially given that the code actually *works*
<snusnu>
dkubb: i've decided to make it a command method, thx for suggesting it .. there's no need for assigning the return value to a const, you can always get at it with Environment#[] anyway
<snusnu>
dkubb: however, spec failures are the same after that little refactor
<snusnu>
which of course, i expected
<snusnu>
solnic: as a convention, i typically do: Rename Repository#{get => []} instead of "Rename Repository#get => Repository#[]" in commit messages, less typing
<snusnu>
solnic: just so you know
<snusnu>
solnic: i found that this form makes quite some typical refactoring ops very readable while still being a short commit msg
<solnic>
snusnu: cool
<snusnu>
solnic: e.g: Move Foo::{Bar => Bar::Baz}, Collapse Foo::{(Bar, Baz) => Bam} .. it somewhat breaks down if you "leave the namespace", but yeah .. happens rarely
mbj_ has joined #rom-rb
<snusnu>
solnic: Extract Foo::{Bar => (Baz, Bam)}
<snusnu>
whatever … just sayin' … cause i still didn't win against my specs ...
snusnu1 has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu1 has quit [Client Quit]
snusnu has joined #rom-rb
mbj has quit [Ping timeout: 268 seconds]
<snusnu>
dkubb: OMG
<snusnu>
it 'registers the chain under the given name' do
<snusnu>
dkubb: lol, your suggestion fails with the same error as before, and i have no idea why
<snusnu>
dkubb: does that need to be in a before block maybe?
<solnic>
snusnu: just do expect(subject).to change {} ?
<dkubb>
I don't think that'll work
<snusnu>
solnic: the same error
<dkubb>
because subject will be evaluated first
<solnic>
dooh
<solnic>
right
<snusnu>
dkubb: the tricky thing is, object[name] raises in my case
<snusnu>
dkubb: i guess i'll just stick with calling subject .. looks terrible, but i'm kinda used to it already
<dkubb>
that's weird it didn't work
<snusnu>
ok, now on to solnic's pet peeve … writing the ("symmetric") test for #[]
<snusnu>
dkubb: yeah weird, right? however, object[name] raises before, but not after subjewct
<snusnu>
dkubb: so the nil expectation would be wrong anyway
<dkubb>
oh I see
<dkubb>
it executes the block once to get the return (from) value, and then runs it after executing the subject to find out the to value
<snusnu>
dunno if you can do sth like expect(foo).to change { from_raise_error }.to(being cool)
<dkubb>
hah
<snusnu>
;)
<dkubb>
ok, if anyone wants to test out the rom-rb/rubocop feel free to update from devtools
knowtheory has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]
<snusnu>
dkubb: currently running mutant in my old bundle, once it passed, i will try and update devtools
knowtheory has joined #rom-rb
<dkubb>
ok, I've got PRs in to parser and rubocop that fix everything, now to wait
<dkubb>
well, kinda anyway. in rubocop it works-around the parser bug, and the parser PR fixes the bug so the work-around isn't necessary
<dkubb>
the rubocop one also includes normal fixes for parser api changes of course
knowtheory has quit [Quit: Computer has gone to sleep]
<solnic>
dkubb: cool, rom-relation is green :)
<dkubb>
sweet
<dkubb>
I'll look at what I'll take to push it down to axiom.. I probably won't do it right away, but when it is done I
mbj_ has quit [Read error: Connection reset by peer]
<dkubb>
I'd imagine rom-relation's schema stuff would be a thin wrapper
<dkubb>
or maybe it wouldn't need to wrap it at all. not sure
<dkubb>
either way we should be able to cut the code down and provide some nicer DSLs to the axiom level
<dkubb>
I'd like for the DSL syntax and the migration syntax to actually be aligned somewhat
<dkubb>
at least, your migrations would reflect on the current schema, and then use normal relational operators to transform the data to something new
<solnic>
dkubb: sounds like a plan
<dkubb>
using relational operators to do migrations would kick ass. it's all there built into the language
<dkubb>
as long as we were good at educating, I'm sure people could wrap their heads around it
<solnic>
dkubb: I tried to explain this idea to some people and they were like "WAT" :)
<dkubb>
when you perform a query you're defining a set of transformations on the relations. the real difference between that and migrations is you're "persisting" the change
<dkubb>
hehe
<dkubb>
WAT as in "I don't understand" or WAT as in "mind blown"
<solnic>
in the middle
<solnic>
:)
<dkubb>
haha
<dkubb>
ok, I can live with that
<solnic>
yeah, that was an initial reaction
<solnic>
then I explained a bit more and it was all good
<solnic>
dkubb: mutant crashes for me in rom-relation :)
<dkubb>
as long as it's not WAT as someone would say when being exposed to javascript quirks
<snusnu>
mbj: i have no idea why line 22 let alone 23 don't kill the mutation
<snusnu>
mbj: i feel like there must be a solution different from a method expectation on "other" .. which btw would require complete stubbing of other, as it's adamantium::flat
cored has joined #rom-rb
<dkubb>
mbj: are other.app_env and other always the same object?
<dkubb>
oops I meant snusnu with that
<dkubb>
snusnu: if you pass in "other" as the first argument in build, does it reach in and use other's app_env to populate it's state?
<dkubb>
I guess I answered my own question
<dkubb>
snusnu: sometimes when I'm not sure how to kill something I make the change to the code in the mutation and run all my specs to see what fails. then I will run just that spec and use binding.pry to see what the object state is
<dkubb>
snusnu: then I work backwards from that to write a spec that does it everytime
<dkubb>
snusnu: sometimes I'll even add assertions into the code to assert the state that causes the failure and use that to guide me writing the test. then I remove the assertions and try to kill the mutation
<snusnu>
dkubb: yeah, looks like there's an actual bug somewhere … obviously, if i change the code like mutant suggests, the unit spec still passes .. but … the integration spec too :p
<dkubb>
oh interesting
<dkubb>
snusnu: maybe add something to the code like: raise if other.equal?(other.app_env) on line 41 there
<dkubb>
snusnu: then run the specs and see what blows up
<snusnu>
dkubb: i know why that is tho, i only have a fake app_env = Object.new in integration spec, and it never gets exercised, i wanted to change that for a while already
<dkubb>
snusnu: assuming it *is* invalid for other to be equal to it's app_env
<snusnu>
dkubb: sorry, was away for a bit, guess what, adding the raise you suggested, still leaves green specs
<mbj>
snusnu: sorry, busy again :(
<dkubb>
snusnu: oh I see, so I guess nothing puts the code in that state
<dkubb>
that is really weird then
<snusnu>
dkubb: it's totally weird, i *really* expected those specs to kill that mutation .. currently trying to construct the expected object another way, tho i'm not sure if that could change anything
<snusnu>
dkubb: yeah, still the same
<dkubb>
I would generally assume that it's not a mistake in mutant
postmodern has joined #rom-rb
<snusnu>
dkubb: yeah, i'm sure of that
<mbj>
Too much faith in mutant :D
<mbj>
Mutant is NOT self covered, expect any kind of very subtible bug.
<snusnu>
mbj: i'm trying to track that mutant sucker down for ages already ...
<mbj>
snusnu: Already changed the code to the mutation?
<mbj>
snusnu: And see if specs fail?
<mbj>
snusnu: This is the best strategy for "hard to kill mutations".
<snusnu>
mbj: yeah did that, specs pass
<mbj>
snusnu: So write more specs till they fail for that mutated code
<snusnu>
mbj: i don't see how that's fundamentally different from what i've been doing for ages now, but ok
<snusnu>
mbj: it's trading red for green
<snusnu>
one would think it's so simple … i inherit a completely new env from an already existing env, the new env should simply take the old app_env as its app_env
<snusnu>
it's like inheriting from a class, take it from the baseclass
<snusnu>
conceptually
<dkubb>
snusnu: if you run out of time tonight feel free to push it to a branch and wrap the code within the example in a pending block and I can look at it tonight
<dkubb>
mbj: it's fairly rare for me that I find a mutant bug. I mean, it does happen, but for every 10 times I blame a tool I'm probably right only once ;)
<dkubb>
if that actually
<mbj>
hehe
<snusnu>
dkubb: thx for the offer! if nothing else works, i might very well get back to that .. but usually, my mind can't rest until it could fix it ;)
<snusnu>
that said, mbj, i'd appreciate one closer look of yours ;)
<snusnu>
it's self contained, no browsing of other code needed
<snusnu>
:p
<snusnu>
the tough thing is, it's the freakin' LAST remaining mutant, then that huge PR would be done
<snusnu>
heh
<mbj>
snusnu: hehe
<mbj>
still looking
<dkubb>
haha
<mbj>
But tbh I cannot force my brain
<dkubb>
I totally get that
<mbj>
01:00 localtime
<mbj>
I just added 2 new mutators
<mbj>
s/mutators/mutations/
<snusnu>
lol
<mbj>
If I cannot participate on rom* because of time, I can slow down the team :D
<mbj>
via new mutations :D
<dkubb>
haha
<dkubb>
please do!
<snusnu>
ok then, i will use our rubocop in the gemfile bundle update, and will tackle new mutations :o
<dkubb>
I figure it this way, we slow down a tiny bit to fix mutations, or hundreds of people slow down later to fix broken code
<snusnu>
and "wehe" mbj, there are no new ones …… :D
<mbj>
snusnu: lulz
<mbj>
dkubb: "wehe" is german and some kind of a "drohung" :D
<xybre>
Some contributors are going to hate you guys.
<dkubb>
mbj: thanks for those send -> public_send and gsub -> sub mutatiuons
<mbj>
snusnu: now rool the ball and explain "Drohung" with another german word :D
<mbj>
s/rool/roll/
<mbj>
xybre: this is the james cameron project :D
<mbj>
We hope we can prove extreme quality via zero bugs on v1.0.0 :D
<dkubb>
I'm sure some people will hate it
<mbj>
s/zero/close-to-zero/
<xybre>
Code might be correct to design, but we can only hope the design makes sense ;)
<dkubb>
I'm totally ok with that
<dkubb>
well, yeah, that's the trick
<dkubb>
you pick the wrong abstraction then you're kind of fucked
<snusnu>
mbj: haha
<mbj>
oha
<mbj>
yeah
<mbj>
And the point is we have lots of new abstractions.
<mbj>
RA, the most fundamental one
<snusnu>
dkubb: so actually, mbj "thinks" i was "threatening" him ;)
<mbj>
DM (pattern)
<dkubb>
the thing is, we're kind of optimizing for the kinds of problems we had with DM
<mbj>
And lots of "Beiwerk", frozen object trees, functional style code, ...
<mbj>
Yeah, and this is good.
<dkubb>
with DM we had an active developer community, totally open submission process, etc
<mbj>
Solving "real world problems".
<dkubb>
the thing is I still ended up writing 90% of the code
<snusnu>
mbj: mutant running ….. fingers crossed .. or .. should i say, cross your fingers :D
<dkubb>
but I ended up maintaining and rewriting almost everything else that was submitted
<xybre>
There's some projects out there that will merge in anything. The codebase quickly becomes a mess.
<snusnu>
mbj: send => public_send, gsub => sub won't affect me … i bet
<dkubb>
I'd rather have a higher bar to entry. if we're going to end up maintaining most of the code I'd rather have the code we maintain do precisely what we expect
cored has quit [Ping timeout: 264 seconds]
<mbj>
xybre: All software becomes a mess over the time. We just need to push the "becomse messy point" the far in the future as possible.
<dkubb>
xybre: yeah, I can think of lots of projects like that
<xybre>
It starts to look like "cut-up" Burroughs.
<xybre>
mbj: Thats a sucky truism. :(
<dkubb>
for every person we piss off by having such high standards, I think we'll have an equal number of people who appreciate it.. even just to use the project and help us test out the edge cases
<dkubb>
even if we piss off 10x more people than we make happy I'm totally cool with that
<dkubb>
I don't think we will. everytime I talk to people about ORMs and ODMs the first thing that they talk about is reliability.. or the tool not doing what they tell it to do
<dkubb>
or doing way too much, etc
<xybre>
I've noticed, that even when the guy who built a gem is sitting next to you, most people won't bother reporting bugs. They will complain, kludge around, etc but never report.
<mbj>
I ended up in asking all people sitting next to me to report bugs. With "I'll not fix it if there isnt a bug report".
<snusnu>
mbj: still only that one bastard mutant alive ...
<mbj>
gota go to bad
<mbj>
angry wife
<mbj>
closing my notebook
<snusnu>
heh
<xybre>
I found comments in some code from a guy I work with where he worked around a bug in one of my gems. I fixed the bug after someone else reported it to me. Then I run across code in the codebase I get paid to write in, refering to one of my gems.
<mbj>
ahhh, child rescued me :D
<snusnu>
!
<mbj>
additional 5min
<snusnu>
kill my mutant!
<snusnu>
;)
<dkubb>
hehe
<mbj>
snusnu: I'm thinking how to add a new mutant to your code :D
<dkubb>
xybre: I've had the same experience
<snusnu>
lol
<mbj>
ahhhh
<mbj>
wife is here again
<mbj>
cu guys
<mbj>
....
mbj has quit [Quit: leaving]
<dkubb>
haha
<xybre>
It was something really trivial too, like I'd put Pry in the runtime dependencies by accident.
<xybre>
I fixed it back in February, but ran across the work around just last week.
<xybre>
I like Tarsnap's code bounties, but that requires income.
<xybre>
"According to Linus' Law, "given enough eyeballs, all bugs are shallow". This is one of the reasons why the Tarsnap client source code is publicly available; but merely making the source code available doesn't accomplish anything if people don't bother to read it."
<dkubb>
it would be nice if by solely open sourcing code you get lots of eyeballs on it
<dkubb>
but people like using black boxes and don't usually audit code until something goes haywire
<dkubb>
there's such an enormous amount of trust given to oss developers
<snusnu>
dkubb: the only way i could come up to kill the mutation, and i count that as no kill actually, is to do this:
<snusnu>
dkubb: the problem is, i cannot do that actually, because Environment is Adamantium::Fla
<snusnu>
dkubb: and the above expectation, ugly as it is anyway, won't work when that's enabled
<snusnu>
dkubb: i'm really starting to doubt there's any other way than stubbing things, which i'd really dislike to do
<snusnu>
dkubb: the thing is, an "internal" Environment instance gets created during the course of that method, and that internal object gets initialized with env.app_env … but since it never really "manifests" because it gets merged into the incoming env immediately, i can't really do anything that makes sure that that internal object actually received a a *property* of the incoming env, not itself