swarmhost has quit [Read error: Connection reset by peer]
xargoon has quit [Ping timeout: 246 seconds]
xargoon_ is now known as xargoon
swarmhost has joined #rom-rb
snusnu has quit [Quit: Leaving.]
knowtheory has quit [Ping timeout: 252 seconds]
knowtheory has joined #rom-rb
mbj has joined #rom-rb
solnic has joined #rom-rb
mbj has quit [Read error: Operation timed out]
yawniek has joined #rom-rb
mbj has joined #rom-rb
<yawniek>
hi, seems like the website etc is pretty fresh. whats the current status of rom, can you do basic stuff already and play with it or are the components not working together yet?
mbj has quit [Ping timeout: 246 seconds]
mbj has joined #rom-rb
<solnic>
yawniek: hi
<yawniek>
hey solnic
<solnic>
yawniek: it's coming together nicely, I'm wrapping up first prototype of rom-session today and we're also working on in-memory adapter and new sql generator
<solnic>
so, lots of simultaneous work is happening :)
<solnic>
yawniek: if things go well you'll be able to play with it in about 2 weeks but this will be "only" in-memory adapter
<yawniek>
ok, i was happily using DM for a long time but for my last projects used mongoid. but its crap. so i'd like to toy around with rom
<solnic>
however once in-memory adapter is done we'll be able to quickly wrap up rom-relation/mapper/session because in-memory adapter is basically working just like if it was powered by an rdbms
<solnic>
yawniek: there is a WIP axiom-mongo-adapter
<yawniek>
nice, looking forward to that.ill look a bit into the projects till then
<solnic>
you could talk to mbj about it, he wrotie it
<yawniek>
nice, ill check that out
<solnic>
IIRC he said he could finish it in no-time
<solnic>
I would love to add support for NoSQL asap btw so testing that would be much appreciated
<yawniek>
k, ill try if i can figure out how to assemble everything ;)
kleech has joined #rom-rb
<solnic>
yawniek: oh that won't be hard, I'll prepare a glue-gem called rom that would assemble everything for you, the only extra gem that you will have to add manually will be the adapter you want to use
<solnic>
s/would/will/
splattael has joined #rom-rb
kleech has quit [Remote host closed the connection]
snusnu has joined #rom-rb
lorenzoo has joined #rom-rb
snusnu has quit [Quit: Leaving.]
lorenzoo has quit [Ping timeout: 264 seconds]
lorenzoo has joined #rom-rb
snusnu has joined #rom-rb
mbj has quit [Read error: Operation timed out]
<kalleth>
solnic: is rom-rb ready for real use? have a task that requires my rubygem to connect to an external database to pull some data and considering it
postmodern has quit [Quit: Leaving]
<kalleth>
but its being charged to a client, so if its a bit flaky i might as well just use dm :)
<solnic>
kalleth: no it's not, we haven't released anything yet
<solnic>
I think your use-case will be supported soon though
knowtheo1y has quit [Quit: Computer has gone to sleep]
mbj has quit [Ping timeout: 276 seconds]
knowtheory has joined #rom-rb
kleech has quit [Remote host closed the connection]
solnic has joined #rom-rb
knowtheo1y has joined #rom-rb
knowtheory has quit [Ping timeout: 246 seconds]
splattael has quit [Quit: Leaving.]
mbj has joined #rom-rb
mbj has quit [Ping timeout: 248 seconds]
mbj has joined #rom-rb
<mbj>
solnic: I had some time with your rom-session code and I like your chances
<mbj>
s/chances/changes/
<mbj>
solnic: I have some points to talk about, but will have to prepare my points a littlebit more
<snusnu>
yo mbj
mbj has quit [Client Quit]
mbj has joined #rom-rb
<snusnu>
mbj: i just pushed tweaked failure chains for substation, it' still not completely ready, but here's what it can do now: http://pastie.org/8082696
<snusnu>
mbj: i refactored the evaluator processor, so that now the pivot processor actually is an evaluator too .. which basically means failure chains are available for the pivot too now
<mbj>
snusnu: I like this change!
<mbj>
snusnu: And we can talk a lot, sitting in a train for 5 hours now
<snusnu>
mbj: heh awesome
<snusnu>
mbj: so, here's my upcoming plans:
<snusnu>
mbj: i want to be able to register a default failure chain with the substation environment
<snusnu>
mbj: and use that if no other was registered
<snusnu>
mbj: (that would typically wrap the error response in some Error::InternalError object
<snusnu>
mbj: and then, for the #chain method inside a chain dsl block, i want it to accept a block, that allows me to append to any failure chain defined inside the chain
<solnic>
mbj: hi
<solnic>
mbj: cool
<solnic>
mbj: prepare your points pls ;)
<mbj>
have to show tickets, mom
<snusnu>
mbj: the env gives me names for the processors, so i should be able to do something like this:
<snusnu>
chain App::CREATE_PERSON do
<snusnu>
sanitize { render SomeView } # that would build on top of { wrap SomeError }
<snusnu>
end
<snusnu>
mbj: remember, that's inside a chain definition, where another chain is chained
<snusnu>
hehe
<solnic>
mbj: I have a ton of commits to push btw
<mbj>
snusnu: I have nothing to add / comment on now
<mbj>
Will have to use it :D
<mbj>
So I'll come up with lots of noobish questions
<mbj>
solnic: As a summary, I like your changes and the way you go!
<mbj>
And some meta information, I have LOTS of bufferbloat here!
<mbj>
For some reasons cellphone operators are just stupid, A packet with age of 120K ms livetime just reached me....
<mbj>
Drop that shit, pls.
<mbj>
solnic: nice, I love you finally have more time for rome
<mbj>
s/rome/rom
<snusnu>
mbj: one thing i was wondering .. would you be open to change from Result#{output => data} in both ducktrap and vanguard?
<mbj>
Sadly I'm not as active, but I think I'll continue to polish mutant
<mbj>
This helps also!
<mbj>
snusnu: you'd have to convince me!
<snusnu>
mbj: i actually want to rename Request#{input => data} and Response#{output => data, input => request_data} in substation
<mbj>
snusnu: Conceptually each item is a method object
<mbj>
snusnu: In some domains #request_data, and #data do make sense.
<mbj>
snusnu: I think we should stay with #output #success?, but can alias for domain specific better names?
<mbj>
Such as http request processing?
<snusnu>
mbj: yeah, that's what i'm doing now already
<mbj>
snusnu: So any other argument to switch from #output to #data?
<mbj>
snusnu: The name "data" is so "stateless"
<snusnu>
mbj: i have a specific need, where i need to be able to both access Request#data and Response#data with the same name
<mbj>
It does not imply this is "produced".
<snusnu>
mbj: but i can alias, no worries
<mbj>
Basically the name "data" is the worst name for anything.
<snusnu>
well it depends when you use it
<mbj>
hehe
<snusnu>
like, in substation, i care about the *flow* of data
<snusnu>
nothing more
<snusnu>
but yeah, i'm fine with the alias
<mbj>
Jo, but the "data" has still a role
<mbj>
and a state.
<mbj>
So using "data" anywhere is IMHO a smelly name.
<mbj>
But your code your rules...
<mbj>
I cross some tunnels, dunno if my messages make it
<snusnu>
right, i'll stick with mine for now, heh
<mbj>
Hehe, verifing via irclog.whitequark.org works.
<mbj>
I love his irc logger!
<mbj>
solnic: Anything you need my help with in rom-session?
<mbj>
Else I'd spend my free for opensorce time now on mutants zombification feature
<mbj>
Allowing us to mutate mutant and its dependencies.
<snusnu>
mbj: some nice not need to have feature in mutant would be a score of "nr of mutations" .. maybe some stdev/variance indicator that points out spots with the most mutations, basically indicating that this is the most complex code
<snusnu>
mbj: i would *not* want you to implement that now tho, there are more important things to be done ;)
<mbj>
snusnu: It would be super easy!
<snusnu>
mbj: well, if you feel up to it, i'm not in the position to stop you either :)
<mbj>
snusnu: The new runner infrastructure holds a full object graph with config 1:n subjects 1:n mutations 1:1 kill status
<mbj>
So we can easily add such features. Can you open an issue?
<snusnu>
mbj: yeah, will do so when i thought a bit more about what would be nice
<snusnu>
mbj: as i was looking through mutants output, i immediately saw, ok, more green dots, more complex method .. it's almost like looking at a bar chart, longer bars means more complex code ;)
<mbj>
snusnu: We could also run mutant without killing mutations (very very fast) to use it as a flog replacement.
<snusnu>
mbj: let's stabilize the mutators first (i mean, come up with any missing ones)
<mbj>
I think number of mutations is the *best* complexity score ever, no need to weight anything.
<mbj>
For example flog really dislikes enumerable.something(&:bar)
<mbj>
snusnu: Jo
<snusnu>
but yeah, i agree
<mbj>
snusnu: We still have lots of "uncovered" nodes
<snusnu>
mbj: right, i wouldn't want to maintain new scores, while they're unstable by nature
<mbj>
uncovered => recursion stops, no mutants emitted.
<cored>
quick question
<cored>
how are you guys making constructors private?
<cored>
a good approach
<snusnu>
cored: private_class_method :new
<mbj>
cored: #initialize is our constructor and it is implicitly private.
<mbj>
Foo.new.initialize # raises with out the need for private :initialize etc.
<cored>
snusnu: private_class_method
<cored>
that's from where?
<snusnu>
from ruby
<cored>
oh
<cored>
checking
<mbj>
snusnu: Yeah, it does not make sense to have this flog replacement now
<snusnu>
it's the same as class << self: private; def new(); end end
<cored>
if I make that method private and then override the method in the child classes
<mbj>
snusnu: And later we'll not add so many mutations
<cored>
can I instantiate it ?
<snusnu>
mbj: yeah
<cored>
the child class I mean
<mbj>
snusnu: I thought about NOT measuring absolute complexity, only relative complexity.
<mbj>
So identifing pices of code that are to complex compared to the rest of your domain.
<snusnu>
mbj: yeah totally, hence my idea with stdev/variance .. basically just indicate the "ausreisser"
<cored>
tested
<cored>
doesn't work
<snusnu>
cored: why would you want to make the constructor private in base classes and then make it public in subclasses?
<cored>
I'm guessing you make the constructor private to have a factory method to instantiate the classes
<cored>
right?
<cored>
snusnu: nvm, it was a crazy absurd idea asking myself same question
<snusnu>
cored: yeah, i'd only make it private if the factory method and .new need to differ in signature (basically, that's when you're forced to name your factory method distinct from #new)
<snusnu>
cored: that said, i can't remember many situations when i had to do that
<snusnu>
cored: another nice "pattern" is to use def self.coerce
<cored>
snusnu: so in other cases you just let the .new method, right ?
<snusnu>
cored: which does input value coercion, and then delegates to regular #initialize, only with proper objects already
<cored>
in that case coarce should be part of my dependencies
<cored>
right?
<snusnu>
wdym by dependencies?
mbj_ has joined #rom-rb
<snusnu>
mbj: btw, just a sanity check, if i need the request *name* inside my chains (i.e. the name the dispatcher invoked it with), you also see no other place as to inject it into Request#initialize(name, env, input), right?
<cored>
the body of self.coerce should have initialization code that is part of my own application or are you talking baout the coercer gem from rom-rb?
<snusnu>
cored: no, your own class method named coerce
mbj has quit [Ping timeout: 248 seconds]
<snusnu>
cored: say you get a hash from somewhere, and you need to build an object from that, which you then need to inject into the actual object you coerce to … that changing the hash into the internal object, is better done in .coerce than in #initialize
<snusnu>
cored: coerce is mostly handy when dealing with input on the boundaries of your system
<snusnu>
mbj_: got my last question?
<cored>
snusnu: I see
<snusnu>
cored: if you do it like that, your objects can be simple compositions of other objects, they expect "valid" proper objects .. coercion from outer layers is separated in its own "layer": .coerce
<cored>
maybe the name is what confuse me a little bit, I still sees it as a factory method
mbj_ has quit [Ping timeout: 264 seconds]
<snusnu>
cored: think of .coerce as the method to use when you need to transform "ugly" data coming from the outside, to pretty objects used on the inside of your system
<cored>
snusnu: got it
<snusnu>
cored: which should be your goal imo, try to get rid of the ugly data structures from the outside, as soon as you can
<snusnu>
cored: once they enter your proper object system, ideally, they're already proper objects, coerced by your (various) coerce methods
<cored>
snusnu: I have two libs that I want to rebuild, bugherd-api and bucketface which is another wrapper for another api
<cored>
snusnu: I want to apply some of those principles to it
<cored>
snusnu: need something to drive my development, I think picking the wrong use cases for things leads you also to bad design even if you try to follow the principles
<cored>
SOLID I meant
mbj has joined #rom-rb
dkubb has joined #rom-rb
<cored>
dkubb: hi
<dkubb>
cored: hello
<cored>
dkubb: did you manage to get that spike to make axiom to use axiom-types
<cored>
?
<dkubb>
cored: no, sorry not yet
<dkubb>
cored: I'll have some time tonight for oss
<mbj>
dkubb: hola
<cored>
dkubb: what time do you have now? I want to be here when you start with that
<cored>
?
<mbj>
dkubb: Do you have any unreported problems with latest mutant 0.3 beta release?
<solnic>
mbj: rom-session is at 98.53% mutcovered
<mbj>
solnic: nice!
<solnic>
I'll push to 100% in about an hour or so
<solnic>
I have some feedback re mutant ;)
<mbj>
Love it!
<solnic>
dkubb: ^^
<solnic>
+ hi
<dkubb>
mbj: I have no issues with mutant atm
<dkubb>
solnic: awesome
<mbj>
dkubb: nice, benchmarking some parts to find bottlenecks
<dkubb>
cored: it's 9:14 am where I am now. I'll probably start on oss work around 6 or 7pm tonight
<dkubb>
mbj: ahh interesting. anything obvious stick out? mutant seems fast enough for me, but of course if there's any quick wins I won't complain if you fix them
<mbj>
dkubb: Seems parser itself is slow
<dkubb>
mbj: although zombification is still my #1 request for mutant. the support gems I have are stuck on rspec 1 + heckle and I'd love to get them off
<mbj>
dkubb: But dunno if that has a real effect on mutation runs
<dkubb>
mbj: that's probably not unsurprising
<mbj>
dkubb: I have some examples causing 90% of the unit spec runtime.
<mbj>
dkubb: But caching that ast (it is always the same) will remove this.
<dkubb>
mbj: although it does say this on it's README: "Parser is a production-ready Ruby parser written in pure Ruby. It performs on par or better than Ripper, Melbourne, JRubyParser or ruby_parser."
<mbj>
"performs" IMHO is talking about features/accessiblity/error-reporting and correcectnes.
<mbj>
NOT about speed :D
<mbj>
whitequark is not a native speaker, maybe he should clarify this.
<dkubb>
ahh ok
<mbj>
But I'll not report an issue, lemme benchmark more.
<mbj>
*not now.
<dkubb>
when I see "performs" I think of performance, as in speed
<dkubb>
I would probably change that to "It is as accurate or better than ... "
<mbj>
Yeah me too, but I also misused "performs" like this.
<dkubb>
mbj: I wonder if using a persistent data structure for the AST might help a bunch
<cored>
dkubb: ok, I'll be here
<mbj>
dkubb: Yeah, just adding some instrumentation to allow easy profiling of parts, without having the need to run with the profile lib!
<dkubb>
cored: I can ping you when I get started on it
<dkubb>
mbj: when clone the AST, I wonder if it could reuse the nodes that haven't changed?
<dkubb>
mbj: does it deep copy them now?
<mbj>
dkubb: Jo, but this will not solve the problem I parse the same code 90 times :D
<mbj>
dkubb: I'll just refactor the specs.
<dkubb>
ahh, right
<dkubb>
hmm
<dkubb>
I wish ruby actually had a runtime representation of it's AST that we could modify inline
<mbj>
currently mutant will cause a specific file to be parsed n times, where n is the number of method subjects in that file.
<dkubb>
without having to use eval
<mbj>
I'm adding instrumentation to benchmark the amount of time spend in parsing, to see if caching would really help.
<mbj>
I'd have to pass around more objects, so I'd like to be sure mutant is spending lots of time doing this.
<mbj>
Currently around 90% of mutants runtime is the acutall rspec kill fork.
<dkubb>
mbj: how does mutant perform with rbx or jruby, I wonder if it might have more efficient characteristics w/eval
<mbj>
and 90% of the time spend in the killfork is doing the same stuff as all other kill forks
<mbj>
loading spec/**/*.rb into a fresh rspec world
<dkubb>
mbj: you could also parallelize the killing too
<mbj>
I'm about to search the most low hanging fruit :D
<cored>
dkubb: great
<snusnu>
mbj: is perf really an issue?
<snusnu>
mbj: at this point?
<solnic>
99.51%
<solnic>
:P
<mbj>
snusnu: no
<dkubb>
mbj: forking should be efficient in ruby 2.0
<mbj>
dkubb: jo generational gc
<mbj>
dkubb: And does not cause many COW pages to be cloned
<dkubb>
right
<mbj>
dkubb: But as I said 90% of the work in each killfork is redone for EACH mutation
<mbj>
there isnt lots of mutation specific code inside the fork
<mbj>
I'd love to do more rspec setup outside the fork
<mbj>
to minimize the amount of repeated logic execution inside the fork
<dkubb>
mbj: if you're going to instrument the process I'd suggest coming up with the various points along the timeline you want to measure
<mbj>
dkubb: I know from the 0.2 series killforks take most time
<mbj>
Currently I'm just optimizing unit test runtime.
<mbj>
dkubb, solnic, snusnu: What about a skype meeting tomorrow? Some kind of Face2Face would be fun?
<snusnu>
if i was to vote, i'd vote for new mutation
<snusnu>
:p
<mbj>
s/?/!/
<mbj>
snusnu: Just having fun with optimization sorry :D
<snusnu>
i know :) and it's fine of course
<dkubb>
snusnu: hehe, if I was to vote it's be for zombies!
<snusnu>
dkubb: heh, that too, yeah!
<mbj>
dkubb: I was talking to snusnu about the complexity measurement via mutation count
<mbj>
And he had the idea NOT to measure the absolute amount of mutations and take more care on the relative amount of mutations
<dkubb>
mbj: that's actually a good metric I think, as good as the other complexity metrics
<mbj>
I think it is the best metrics.
<mbj>
More complex statements will have more muations.
<dkubb>
mbj: what do you mean by relative?
<snusnu>
dkubb, mbj: looking at current mutant's output, it's almost a bar graph, longer bars, more complexity .. relative to the others
<mbj>
So identifing how far the most complex method is more complex than the mean
<snusnu>
i'm sure we can come up with meaningful absolute numbers too, but that shouldn't be the priority imo
<snusnu>
something like: 1 stmt per method == 2 mutations (or whatever number it is)
<mbj>
Relative numbers are good as we are still adding mutaitons
<snusnu>
at least as an indication, but yeah, i favor the relative numbers
<dkubb>
mbj: yeah, I've mentioned my theory to you about a metric where you concentrate more on identifying outliers, and try to get the complexity evenly distributed.. I think a healthy code base has complexity evenly distributed first and foremost, then focuses on lowering the overall complexity
<mbj>
snusnu: measuring statements is complex in ruby
<snusnu>
i wouldn't want to do that mbj
<mbj>
snusnu: counting syntax nodes would be an idea.
<mbj>
Lowering the amount of mutations, yeah!
<mbj>
That is my #1 rule with a mutation. Not write a test.
<mbj>
Try to refactor the mutation away!
<dkubb>
yeah
<snusnu>
which tends to add tests at other places maybe, but yeah, with better distributed complexity
<dkubb>
I first try to avoid writing a test by removing code. and if I have to write the test I try to write as little spec setup as possible.
<dkubb>
yeah
<dkubb>
distributed complexity is easier to manage than a few places with extreme complexity imho
<mbj>
It more at more feels tests have to prove code is allowed to exist.
<dkubb>
mbj: I've actually been thinking that there should almost be a 1:1 correspondence between the context blocks and mutations in a method
<mbj>
dkubb: "context blocks" ?
<mbj>
def foo
<mbj>
bar.do |baz|
<mbj>
end
<mbj>
end
<mbj>
two context blocks?
<mbj>
one "main" block and one explicit inner?
<dkubb>
mbj: in rspec.. content 'when it has a foo, but not a bar'
<mbj>
ahh
<mbj>
Yeah, but that 1:1 is more like a 1:1*static_factor
<mbj>
That static factor should be close to 1 :D
<dkubb>
yeah, I guess maybe a better way to say it is 1 context block per logic branch
<dkubb>
since it's possible for a single context to catch multiple mutations I guess
<mbj>
Especially if logic branches are nested, you can end up in powers of 2
<dkubb>
yeah. all the more reason to reduce your branching
<mbj>
I'm sitting in a so called "high speed train", doing 650km in 5 hours.
<mbj>
And all the time I look through the window I see it running at 30km/h
<mbj>
This confuses me :D
<solnic>
mbj: I pushed some commits, I'll add some questions in commit comments
<mbj>
solnic: jo, I'll do the same :D
<mbj>
so what about the skype meeting you guys are interested?
<solnic>
mbj: actually no, it makes more sense to ask here
<solnic>
mbj: sooooo
<solnic>
my experience with mutant was near to perfect
<mbj>
solnic: that skype meeting is more about socializing
<mbj>
solnic: not about tech!
<mbj>
solnic: Just say a hello :D
<solnic>
mbj: it was all great until I had to add some weird specs because of some mutation
<solnic>
mutations
<solnic>
more specifically - removing return values
<mbj>
show me!
<solnic>
I have some methods that do something
<mbj>
I'll pull and remove those specs.
<mbj>
To see the mutations.
<solnic>
but there's no code relying on their return values
<solnic>
to kill those mutations I had to add redundant specs
<solnic>
which as you know I really don't want to do
<solnic>
well, for instance removing "self"
<mbj>
solnic: That happens if a public command method calls another public command method.
<solnic>
which I return in some methods
<solnic>
following our rule of command methods
<mbj>
So the outermost method already returns self "implicitly"
<mbj>
Because its return value is already a command method. I see.
<solnic>
well, I have for instance Tracker#commit which happens to return self
<solnic>
but it is just called inside another object
<solnic>
which delegates call to commit to tracker
<solnic>
return value is completely irrelevant
<solnic>
it's like def commit; tracker.commit; self;end
<mbj>
okay
<solnic>
so, I don't care what Tracker#commit returns, I just call it
<snusnu>
dkubb: btw, if i had a vote on your oss time too, i'd vote for the in memory adapter ;)
<mbj>
How the mutation looks like?
<mbj>
(the mutation that causes problems)
<solnic>
mbj: removes "self" which is being returned by a method
<mbj>
so it looks like:
<mbj>
def commit; tracker.commit; end
<kpwz>
hey.
<kpwz>
so I made another pass at the logo
<mbj>
So where is the problem with killing that mutation? it_should_behave_like 'a command method' doesnot work?
<kpwz>
with Gotham Bold rather than Gotham Rounded
<kpwz>
I think it works better
<solnic>
mbj: the problem is that I don't need tests for that private API :P
<kpwz>
I've also done a few other treatments for dark/light backgrounds in mono.
<mbj>
cored: I educated a newcomer to mutant and metric driven development in 4 weeks
<mbj>
Just showed him on how to run the tools and how to follow the guidiance and told him: Add feature X without raising the bar. (apart flay total score).
<mbj>
Worked :D, 3 weeks later he got it mutation covered and metriced.
<mbj>
But that guy was self educating for years.
<mbj>
And already had a programing background (non ruby).
<dkubb>
snusnu: yeah, I was mostly just going to kick this off so that cored can run with it
<dkubb>
snusnu: but I plan to focus on the in-memory adapter mostly
<snusnu>
dkubb: that's awesome then, thx!
<mbj>
dkubb: I cannot follow all the development you guys are doing, but it is nice I can fully trust the team here.
<mbj>
Hopefully I'll have the time to read *all* and I mean literally ALL the latest source soon.
<cored>
mbj: I see
<cored>
mbj: will try that on this project
<cored>
mbj: let's see where it's takes me; I'm just doing the easiest thing that could work driven by the specs in this case the integration specs
<cored>
mbj: will add devtools, which I suppose have mutant inside
<cored>
right ?
<snusnu>
solnic: tricky shit
<solnic>
snusnu: that's kinda weird I know but you know, otherwise I had unkilled mutation :P
<snusnu>
hehe
<solnic>
mbj: re git, no idea man :)
<solnic>
mbj: I started using git version before you pushed beta
<cored>
bbl lunch
<solnic>
mbj: I just wanted to follow command method convention
<solnic>
mbj: but you know what, you are absolutely right
<solnic>
mbj: I just remove that because explicit self return would indicate return object is relevant
<solnic>
and it's not
<solnic>
!
<solnic>
mbj: thanks :)
<solnic>
mbj: that was my only complaint...
<solnic>
it was a fantastic experience to get through killing those mutations
<snusnu>
solnic: well, nuking might indicate that the method call's return value is relevant?
<mbj>
solnic: nice!
<mbj>
solnic: Feel free to bring up any issue!
<solnic>
snusnu: less than explicit self return
<snusnu>
trudat
<solnic>
brb need to help
<mbj>
solnic: But IMHO that explicit self should stay, and we should have a spec for it.
lorenzoo has quit [Quit: leaving]
mbj has quit [Read error: Connection reset by peer]
<solnic>
dkubb: what do you think?
<solnic>
dkubb: when there's a command method that return's value is irrelevant (as in, there's no code relying on that)
<solnic>
but mutant mutates it by removing explicit self return
<solnic>
reporting unkilled mutation, obviously
mbj has joined #rom-rb
kleech has joined #rom-rb
<snusnu>
mbj: question, i *need* the action name that was dispatched to during a substation chain invocation. i need it, because my authorization scheme relies on that … any objections to passing the name to Request#initialize(name, env, input) ?
<snusnu>
mbj: or suggestions to put it somewhere else? i can't really think of any other place tho
mbj has quit [Ping timeout: 240 seconds]
kleech has quit [Remote host closed the connection]
mbj has joined #rom-rb
<dkubb>
solnic: I dunno, I kind of like command methods that have return values. I usually have all public/protected visibility methods either be commands or queries, and commands always return self, while queries always return something other than self
<dkubb>
solnic: for private visibility methods I almost always have @return [undefined]
<dkubb>
solnic: I almost wonder if mutant could use YARD specifications to augment it's current behaviour. if there's no YARD docs it could fallback to it's current conventions
<dkubb>
solnic: so like if you specify @return [undefined] then mutant can skip mutating the return value since it is irrelivant
<dkubb>
solnic: I would never want to require YARD for mutant to work, but it seems like it could provide extra metadata if it's available
<dkubb>
solnic: we could also treat @api private methods the same way we treat private visibility methods now.. that is they shouldn't require an explicit spec, but they can be covered by any public method's specs
<dkubb>
mbj: actually, on that note, I wonder if we could make it so we *exclude* any same-named specs for private methods to discourage people writing specs for the private methods. right now we kind of just do a glob on all the specs
<solnic>
dkubb: I'm talking about a private class methods, the ones I want to test indirectly
<solnic>
otherwise it'd be testing implementation details
<solnic>
mbj: ^^
<dkubb>
solnic: oh I see. yeah, I think return value mutations should never be done on private methods
<solnic>
dkubb: yes I already suggested to mbj that mutant could make use of yard stuff
<solnic>
dkubb: private classes with public methods ;)
<dkubb>
solnic: private methods have a different contract to fulfill. their responsibility is to do whatever the public methods need. if the return value isn't important, then it shouldn't be required
<dkubb>
solnic: I do think all @api public methods *need* to have specified return values, even if it's just self, because it makes for a more fluid interface
<solnic>
dkubb: I want to write tests only for the things with @api public
<solnic>
that's my point
<dkubb>
solnic: yeah
<solnic>
I currently have a bunch of classes that are not part of public api
<dkubb>
solnic: I think mutant should factor in YARD then, otherwise falling back to what it does now
<solnic>
awesome :)
<solnic>
glad we're on the same page
<dkubb>
I do generally try to minimize @api private methods with public visibility
<dkubb>
but private classes are definately useful
<dkubb>
I think ruby can actually mark constants as private now.. lemme check that
<dkubb>
mbj: is there a way to configure the rspec strategy via the mutant.yml file? I have a rails app I would love to run with --rspec-unit
<dkubb>
mbj: my only other complaint is that the mutant.yml syntax is ruby library specific. afaik there's no way to configure it to work with a rails app without doing things like putting all the models and controllers under a specific namespace
<dkubb>
mbj: like if I have a User model, I don't want to have to put it under SomeNamespace::User .. along with all the controllers, services, etc .. I dunno, maybe namespacing a rails app is good practice. I was just trying to keep this app as standard as possible
zekefast has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<mbj>
dkubb: mutant.yml is devtools
<mbj>
dkubb: Mutant foritself only provides cli, and devtools drives this CLI
<snusnu>
mbj: btw, since you didn't answer my earlier question, i just pushed the change i was talking about … Request#name is now available, and contains the name of the dispatched action
<snusnu>
;)
<mbj>
snusnu: sorry
<mbj>
snusnu: in that train all the time
<snusnu>
heh no worries dude, just joking :)
<mbj>
and having interesting political discussions :D
<mbj>
For some reason I entertain lots of people
<snusnu>
oh, that's even better than talking code
<mbj>
ist interesting yeah
<snusnu>
mbj: btw, i'm thinking about adding another generic Processor::Transformer .. it'd be an outgoing processor, and it would hand on the response by doing sth like:
<snusnu>
mbj: like, for example, constructing a rack response from the output data
<solnic>
dkubb: damn I really need memory adapter now :)
<snusnu>
hehe
<solnic>
dkubb: I can't kill a mutation w/o it :)
<solnic>
and it's THE LAST ONE
<snusnu>
lulz
<solnic>
no really, I'm serious
<snusnu>
it's just what you think now, think harder
<snusnu>
lol
<solnic>
I have a state called "updated" and I can't test it with a real storage
<mbj>
solnic: lol
<mbj>
solnic: mocking the storage away?
<solnic>
mbj: not really an option
<dkubb>
mbj: can you have it work with a base relation? the in-memory adapter works now with straight base relations
<dkubb>
solnic: ^^ sorry I meant this for you
<dkubb>
mbj: I just pushed a change to devtools where if you don't have a config file for mutant it will just act as if it's disabled
<dkubb>
mbj: I can probably add the strategy configuration fairly easily to devtools, which I will do now, but I'm not sure how to configure things so we can test against objects not all under the same namespace
<mbj>
dkubb: nice!
snusnu has quit [Ping timeout: 264 seconds]
<solnic>
dkubb: yes I can, although I just realized I just be able to test with...an array :D
<solnic>
kpwz, kapowaz: which one is current "you"? :)
<dkubb>
solnic: oh those are really nice
<solnic>
totally
<solnic>
it really fits in b/w too
<dkubb>
heh, let's make an ascii version of it to display when the gem is installed
<dkubb>
j/k
<solnic>
luls
<solnic>
dkubb: ah so there's no gateway yet
<dkubb>
solnic: oh right, duh. sorry
<dkubb>
solnic: I'm going to work on a gateway after getting cored kicked off on the axiom-types refactoring
<solnic>
dkubb: sure!
postmodern has joined #rom-rb
<dkubb>
solnic: would you have any objection if I started a branch to add zeus and parallel test support to devtools?
<solnic>
dkubb: man, I thought about doing that today!
<dkubb>
solnic: I have one project I'm working on that uses zeus, and it feels like I have to duplicate this work on every project
knowtheory has joined #rom-rb
<solnic>
yeah that + our dev deps are heavy and guard is...slow
<cored>
dkubb: I'm here btw
<cored>
just in case
<cored>
:-)
<cored>
will stay till get some work done on axiom/axiom-types
<dkubb>
cored: hehe, it'll be a while yet for that
<cored>
talking about zeus
<cored>
isn't using zeus something like using spork
<cored>
a call to fix the design of the app?
knowtheo1y has quit [Ping timeout: 264 seconds]
<solnic>
cored: no, it's a call to stop using rails and write a new framework (partially trololol)
<cored>
solnic: :-P
<cored>
I want to see how that happen
<cored>
Rails is the king and it's seems that it will start to copy stuffs from others frameworks as soon as they start to emerge to stay that way
<dkubb>
oh hehe
<cored>
but I'm starting to feel that the problem is not in fact Rails, I think the problem is the way we are thinking about developing application; talking from my own experience
<dkubb>
zeus is nice because it gets rid of the startup costs
<dkubb>
even when they are tiny they still are non-zero
<cored>
there are some stuffs that I don't feel right, like the way ORM try to be the defacto way to access data from a database
<dkubb>
I see the ORM as just one window into the database
<cored>
for example having something like account.transactions feel cumbersome to me, taking in count that an account do have transactions but they are just id of transactions no need to be actual objects like what AR does
<dkubb>
raw SQL will always be the most basic tool for access. I built axiom to kind of sit in between them on the spectrum
<cored>
dkubb: yes, I want to see it in action/production
<cored>
dkubb: still haven't make my mind around the entire idea but I hope it's success it :-D
<dkubb>
yeah, the real test of anything is real world use
<dkubb>
I won't claim it'll be perfect. it still feels like the right abstraction. there are other tools with similar divisions of labour and they work well
<dkubb>
SQL Alchemy is one such tool that works like what we're going for in ROM
snusnu1 has quit [Read error: Connection reset by peer]
snusnu1 has joined #rom-rb
<dkubb>
yeah, they're pretty awesome
<cored>
nice
<cored>
rom should be there, also :-D
snusnu1 has quit [Client Quit]
snusnu has joined #rom-rb
knowtheo1y has joined #rom-rb
knowtheory has quit [Ping timeout: 260 seconds]
mbj has joined #rom-rb
<mbj>
finally home
<mbj>
dkubb, snusnu, solnic So finally will we have a skype meeting for socilizing? IMHO this is not about tech, more about fun! Would love to see faces once :D
<mbj>
I'll meet snusnu and solnic on eurucamp, so I should know the faces ;)
<snusnu>
mbj: my github profile doesn't give you enough of an impression?
<snusnu>
:p
<mbj>
lulz
<mbj>
This is the last time I'll bug you about this.
<snusnu>
mbj: srsly tho, i'm fine with a skype call
<mbj>
heh,
<mbj>
we need to find a shedule
<snusnu>
tomorrow early evening CEST works for me, if that's difficult for others, i guess my next chances are next week
<solnic>
mbj, snusnu: +1 however I'm certain we're gonna talk about programming
<solnic>
:D
<snusnu>
oh, you think so?
<snusnu>
:D
<solnic>
nah j/k
<snusnu>
hehe
<mbj>
I think dkubbs time is the most significant factor as he is not in our zone!
<mbj>
dkubb: ?
solnic has quit [Read error: Connection reset by peer]
solnic has joined #rom-rb
kapowaz has quit [Ping timeout: 260 seconds]
<dkubb>
mbj: actually it looks like ActiveSupport::Dependencies.autoloaded_constants returns a list of strings, which is cool
<dkubb>
mbj: but when I pass it into Mutant::CLI.run I get an error: ArgumentError: wrong number of arguments (4 for 1)
<dkubb>
mbj: this *does* work though: Mutant::CLI.run(['--rspec-unit', *ActiveSupport::Dependencies.autoloaded_constants])
<dkubb>
snusnu: solnic: mbj: you guys should just spin up a Google Hangout and set the event date at some point in the far future. the hangout will be persistent and always available
<mbj>
dkubb: sorry, you have to pass an array
<mbj>
dkubb: it is build to pass ARGV in
<mbj>
But I like to short circut and use the current VM in rake tasks
<mbj>
This saves some seconds and I like it.
<mbj>
Also mutant does not poison the main VM, it does its stuff in forks as you all probably know!
<dkubb>
nice
<dkubb>
mbj: I just used this inside zeus console, and it was super fast to spin up
<dkubb>
mbj: is there and --rspec-class option in mutant?
<mbj>
snusnu: Apart from naming I'm fine with that change.
<mbj>
Evaluator::Data
<mbj>
I dislike htis.
<snusnu>
i know that, but the thing is … it's a processor that evaluates Request#input
<mbj>
We could name ANY variable or class "data/Data"
<snusnu>
and as you know, i'd like to go with Request#data and Response#data
<snusnu>
right, basically you can assign ANY variable
<snusnu>
lol
<mbj>
Evaluator::Generic ?
<snusnu>
no, that doesn't fit
<mbj>
Evaluator::Custom ?
<snusnu>
not really, imo
<mbj>
mhhh
<mbj>
its your lib and I like the remaining changes.
<snusnu>
the thing is, one evaluator gets passed the complete request instance (because it must access the env)
<mbj>
And it is pre 1.0 so we can change anything once we find a better name.
<snusnu>
the other evaluator gets passed only the actual Request#input .. that is .. SOME DATA
<mbj>
so release it :D
<snusnu>
hence they're named Evaluator::Request and Evaluator::Data
<snusnu>
evaluate data
<snusnu>
what's wrong with that
<snusnu>
what can be better/generic/specific?
<snusnu>
Evaluator::Object ? lol
<snusnu>
everything is an object
<snusnu>
much more than everything is data
<snusnu>
haha
<snusnu>
mbj: btw, the latest Evaluator::Transformer that i've added, opens gates to process serializer, handler, rack response converter, whatever handlers
<snusnu>
mbj: i'm rather happy with that set now, can't think of any other specific usecases atm