abe has quit [Read error: Connection reset by peer]
lorenzo_off is now known as lorenzo
ksinkar has joined #rom-rb
ksinkar has left #rom-rb ["Konversation terminated!"]
mbj has joined #rom-rb
postmodern has quit [Quit: Leaving]
mbj has quit [Ping timeout: 240 seconds]
postmodern has joined #rom-rb
mbj has joined #rom-rb
jfredett has joined #rom-rb
jfredett has quit [Client Quit]
postmodern has quit [Quit: Leaving]
snusnu has joined #rom-rb
<snusnu>
mbj, solnic: i refactored devtools … still a way to go (pulling the rake task work into Devtools::Task::Runner objects) … but it conforms to our style now, and working on it will be much easier now … ;)
<snusnu>
wraps a project and provides devtools' public api
<snusnu>
so we can work with instances only, instead of shitty singleton methods
<solnic>
word
<snusnu>
Project is just a data container now, providing access to configs .. and it can definitely be trimmed down still
<solnic>
awesome man, really awesome
<snusnu>
thx :) now we can also start testing it
<snusnu>
once tasks work is done in Task::Runner objects, we can start solidifying the threshold system … like, i want exclude option for flay/flog e.g
<snusnu>
e.g. i noticed that with our immutable objects, flog tends to score highest at the boundary of the system (like in .coerce or .build methods) … i don't want code like this to set the threshold for the rest of the system
<solnic>
snusnu: yeah
<solnic>
those are the most complex parts of our libs
<snusnu>
once we have an object that does flog invocation, we can easily start parsing flay/flog results, and thus support an exclude option in config files
<solnic>
because building immutable objects is an effort
<snusnu>
yeah
<snusnu>
which reminds me, as i saw your tickets on Environment#finalize for consts as strings
<snusnu>
can we think about that some more
<snusnu>
i believe i have a generic way (not shared code, but shared concept) to avoid finalization
<snusnu>
think about DSL objects: when split into something like Registry and Registry::Mutable objects, we can fill up Registry::Mutable instances during "data collection phase" (i.e. during the require phase) .. and in the end, call sth like Registry::Mutable#registry which returns a new immutable instance of Registry
<snusnu>
with our style, we tend to expose an INSTANCE to clients (think, environment)
<snusnu>
after requiring all the code, we can construct that *immutable* instance, as long as we collect all info we need with the *mutable* one during require phase
<snusnu>
it has the same effect as finalization, we can even call it finalization, but the mutability is nicely localized
<snusnu>
i did that for 2 codebases already, and it works nice
<mbj>
snusnu, solnic: BUSY
<mbj>
I'll go offline
mbj has quit [Quit: leaving]
<snusnu>
mutant mutant mutant
<snusnu>
lol
snusnu has quit [Quit: Leaving.]
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
<solnic>
haha snusnu
<solnic>
snusnu: I just need whatever to make finalizing models from strings work
<solnic>
snusnu: we can pitch in some more fancy solution later of course
breakingthings has joined #rom-rb
snusnu has joined #rom-rb
jfredett has joined #rom-rb
mbj has joined #rom-rb
<mbj>
hi
<mbj>
snusnu, solnic: I have "some" time, anything where I could help with?
<mbj>
snusnu: I like your latest devtools changes!
<snusnu>
mbj: tbh, i thought so ;)
<mbj>
snusnu: more "condensed"
<snusnu>
mbj: next up will be moving logic in .rake files to Devtools::Task::Runner objects
<snusnu>
mbj: then it will be easier to implement exclude option for flay/flog
<mbj>
snusnu: Ideally we can just drop rake!
<snusnu>
mbj: yeah, i've thought about that too, would be nice
<mbj>
snusnu: Less deps, and lets "non our style" deps :D
<snusnu>
mbj: btw, if you have some time, you could integrate rspec-level option with devtools mutant
<mbj>
snusnu: I plan that mutant.yml can be read by mutant natively.
<mbj>
snusnu: Or even better, mutant would try config/mutant.yml and .mutant.yml per default.
<mbj>
snusnu: All options you give to the executable would be added.
<snusnu>
imo config/mutant.yml by default is stupid
<mbj>
snusnu: yeah
<snusnu>
the name config is rudely squatted, as i mentioned yesterday
<mbj>
snusnu: .mutant.yml per default
<snusnu>
yeah
<snusnu>
better
<mbj>
snusnu: You read about "coveralls.io" for mutation analysis on twitter.
<mbj>
I see some demand.
<mbj>
One potential customer :D
<mbj>
I could need some help with business decisions, later.
<snusnu>
haven't looked at twitter in a while ...
<snusnu>
mutcov?
<mbj>
Ideally I'd just start with the OSS version, yes.
<mbj>
yes - mutcov.
<mbj>
And see if there is more demand for private repos.
<mbj>
The problem: The mutated and original source would be transferred to this service.
<mbj>
So I'd need to spend more thoughts on security as with an pure OSS solution.
<snusnu>
btw, the CLI syntax you suggested is somewhat unfamiliar .. it'd be better to do: mutant —rspec=Foo::Bar —test-unit=Foo::Baz ……. instead of using ":"
<mbj>
snusnu: I dislike to have any "-" or "--" prefix for "normal" operation.
<mbj>
snusnu: And I expect most people will use a .mutant.yml
<mbj>
Only for selecting a specific target when hunting the CLI should be used.
<mbj>
If I'm building a service for private repos, I should probably team up with a bigger player that already has good infrastrucutre regarding the "keep the code private" problem.
<snusnu>
ok, right, technically those are not (cli) options
<snusnu>
mbj: probably yes, then again, most likely you won't like their code :p
<mbj>
Not that I think I'd be totally dump stuff. Just the problem and the amount of problem I'd create, is to big for a lone soul to deal with.
<mbj>
snusnu: haha, yeah
<snusnu>
;)
<mbj>
snusnu: the initial "private repo" system could just submit a score.
<mbj>
So not "that" a big problem :D
<snusnu>
imo a private system can be dealt with later
<snusnu>
we need it for oss now
<mbj>
snusnu: I need to pay my bills :D
<mbj>
snusnu: So I need to find a reason to get some income from it :D
<snusnu>
i know, but the open version will allow you to gain much deeper insight into wether there actually is a market or not
<mbj>
snusnu: Okay a public "submit the score and get a badge" thing would be totally easy.
<mbj>
snusnu: Yeah
<mbj>
I talked to dkubb about this in depth some while ago.
<mbj>
I'll start "most simple"
<mbj>
A score.
<snusnu>
once people ask you if it's available for private code, and there are enough of them, it's soon enough to start building it imo
<mbj>
And a simple opt in, "install the mutcov gem and run mutant in your build".
<mbj>
No need for accounts, github connection etc.
<mbj>
The only thing, how I make sure nobody is submitting a score for rails/rails :D
<snusnu>
i was about to say that, if the UI is also oss initially (whatever the license), people can run it privately theirselves too
<snusnu>
you can even choose a license where they would have to pay
<mbj>
Yeah
<snusnu>
and don't worry about copyright breachers initially
<mbj>
haha
<mbj>
yeah
<mbj>
The thing is, if the "interface" to mutcov.org is a stupid "gem"
<mbj>
and mutant would detect this them and submit scores
<mbj>
how I make sure nobody tricks the submission interface
<mbj>
I think I need to verify I'm within one of the whitelisted CI environments.
<mbj>
And this environment is NOT reproducible without knowing a travis/circleci priv key.
<mbj>
I think it is "doable", both have a "signing" interface.
<mbj>
Or an encrypted nonce (with their pkey) in the enc, (alongside the plaintext version) where the submission interface (that one that accepts scores at mutcov.org) could check it was a run at travis.
<mbj>
s/enc/env/
<mbj>
snusnu: just thinking out loud :D helps me to structure the storm in my brain
<snusnu>
sure :) i currently don't have time to discuss this more in depth, but i'm happy to do that later on
<mbj>
snusnu: np
bf4 has left #rom-rb [#rom-rb]
bf4 has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mbj has quit [Quit: leaving]
<snusnu>
solnic: imo we *cannot* add an EV/EC concept easily, like, at all
<snusnu>
solnic: EV yes, trivial, it's still a flat tuple
<snusnu>
solnic: EC, not trivial, a set of tuples that need to be collapsed based on FK info, and collapsing on FK info would only give us relationship "emulation" obviously, it's by no means a generic group/ungroup
<solnic>
snusnu: true
<snusnu>
solnic: it's fine tho, we kinda knew it … all we need is group/ungroup in axiom ;)
<solnic>
snusnu: true ;)
<snusnu>
that's even why, after some time, i changed my mind and thought of that as the #1 priority to be able to push rom forward .. more important than sql write support
<snusnu>
as long as we don't have that, we cannot leverage our current design (which i still think is completely on the right track)
<snusnu>
we can build out other parts of the system, but we can't even emulate EC easily until axiom provides us with this stuff
<snusnu>
and yeah, EC is somewhat important :p
<snusnu>
we know what initial stabs at emulating brought us: the jersey thing.
<snusnu>
well, that last part probably isn't entirely true, we got TJT because we stupidly moved FK definition into relationship instances, needing to track renames across RA ops, but yeah ...
<snusnu>
s/relationhip instances/relationship DSL
postmodern has joined #rom-rb
<solnic>
snusnu: true but w/o a memory adapter we wouldn’t do *anything* so that was even more important
<solnic>
I could only finish session thanks to memory adapter
<solnic>
dkubb didn’t have enough time for both
<snusnu>
solnic: oh absolutely, i know that … i was contrasting SQL write support and group/ungroup
<solnic>
snusnu: I think we need to learn how to work on axiom
<snusnu>
yeah
<solnic>
it’s really bad for the project that only dkubb is working on axiom
<snusnu>
yeah, the thing with axiom is, that while i'm absolutely not afraid to dive into code, because it's beautiful anyway, i seriously lack the theoretical background it's built on
<snusnu>
it's math, covered in a nice ooapi, i like building ooapis, but i suck at math, usually
<snusnu>
so to me it feels like i need to understand the underlying math, if i want to add new api
<snusnu>
and tbh, i don't have the time to start studying that *and* writing code for it
<solnic>
snusnu: I don’t think you need to know all the details to add group/ungroup
<solnic>
also, relational algebra was probably the easiest part of math at uni :P
<snusnu>
not for me lol
jfredett has quit [Quit: Leaving.]
<snusnu>
anyway, i don't wanna chicken out, but i dare to say that i won't be the guy to implement that in axiom
<snusnu>
not for lack of interest, but for lack of time
<snusnu>
or to be even more honest, other things interest me more, and i want to spend time on them
<solnic>
yeah same here
<solnic>
I would love to help with axiom though and it interests me as much as other parts but…don’t have time for everything that interests me :(
breakingthings has quit []
mbj has joined #rom-rb
mbj has quit [Ping timeout: 264 seconds]
mbj has joined #rom-rb
mbj has quit [Read error: Connection reset by peer]