<dkubb>
mbj: I was having some fun with mutant tonight
<dkubb>
mbj: I have two small PRs for your consideration. I already updated that first one you commented on a few minutes ago with an alternate approach
<mbj>
dkubb: hi
<mbj>
dkubb: still up?
<dkubb>
mbj: about to crash
<dkubb>
mbj: I was just having fun with mutant
<dkubb>
mbj: while thinking about axiom-memory-adapter. I think I have a really nice approach that'll work, but I need to think more on it
<dkubb>
mbj: I fixed one bug with the glob tonight
<dkubb>
the rescue I'm doing is probably better than before, since it won't silence mutant bugs
<dkubb>
unless there's an error right in that method. if we're worried about that I could wrap just that one line in begin
<dkubb>
I could also rescue NameError and ArgumentError, which are the two main ones that are thrown when mutant runs against axiom
<dkubb>
and we can add more over time if others pop up
<dkubb>
mbj: ok, I can get behind that
<dkubb>
let me add that and push it to the PR
<mbj>
Yeah
<mbj>
I'll merge it in!
<mbj>
I think this minimizing of rescued code is what I wanted.
<mbj>
*initially
<mbj>
Maybe we can also log exceptions bubbling through rspec!
<dkubb>
mbj: ok, I made this change: https://github.com/mbj/mutant/pull/56 .. no logging, but I would think for debug logging we might want to log it to a file and keep the runner output clean
<mbj>
dkubb: Yeah, we can add logging there once we have infrastructure for this.
<dkubb>
mbj: only 33 mutations left in axiom
solnic has joined #rom-rb
<mbj>
dkubb: nice!
<mbj>
dkubb: Let me release our latest state as beta5
<dkubb>
mbj: ok, I've got a fix for that benchmark thing coming in a sec
<mbj>
dkubb: no, I'll fix that children bug before.
<solnic>
geeez
<solnic>
good morning
<mbj>
solnic: hola!
<dkubb>
then all the issues I saw will be fixed
<dkubb>
good morning
<solnic>
you still up?
<solnic>
:D
<dkubb>
yeah, just finishing one thing before going to bed
<solnic>
mbj: I found an issue with mutant + bogus
<dkubb>
mbj: when you do release mutant 0.3.beta5 can you make sure to update the shared Gemfile in devtools? I updated it to reference that to make it easier for testing
<solnic>
dkubb: ah ok so it's still depending on relation proxying
<mbj>
yeah
<solnic>
mine is a generic one, it assumes first arg passed to the constructed is the decorated object
<solnic>
implementation could be improved (like *maybe* using a module subclass)
<dkubb>
solnic: yeah, I like that
<dkubb>
solnic: I wonder if we can simply use DelegateClass at some point?
<solnic>
constructed/constructor/
<solnic>
dkubb: I haven't used it :(
<dkubb>
I used DelegateClass in another project and it was nice and simple to work with
<solnic>
dbussink: this is very weird, beyond my imagination :)
<mbj>
Ahh you do not talk about the mutant specific issue.
<dbussink>
solnic: what is the string they feed the compiler?
<solnic>
dbussink: bogus does various trickery to achieve safe stubbing, I talked to the maintainers and they said they used to run their specs against rbx but they were getting random crashes so they stopped :(
<dbussink>
why did they never report that to us then?
<solnic>
dbussink: well...
<dbussink>
if we don't know, we can't fix :(
<solnic>
I dunno :) I can ask?
<solnic>
I work with those guys
<dbussink>
that would be great!
<mbj>
solnic: Tell tem to test rbx intide allowed_failures
<dbussink>
we really want to support libraries etc.
<mbj>
s/intide/inside/
<dbussink>
and report issues if they have them
<dbussink>
the more detail the better, but just failing builds would already help
<solnic>
dbussink: well, that's why we're talking now
<solnic>
:)
<dbussink>
yeah
<solnic>
dbussink: should I switch to rubinius channel?
<dbussink>
it's just that the "oh yeah, it didn't work, we disabled it" doesn't really help to push things forward :(
<solnic>
dbussink: ok so rudy (one of the maintainers) said they didn't report them because they didn't have any detailed info except build failures that were RANDOM
<solnic>
dbussink: I told them it was fine to report that anyway
<dbussink>
yeah, even that is fine
<solnic>
dbussink: they will be working on bogus tomorrow and provide more details
<solnic>
so I'll ping you then or just get you guys in touch so you can work this out
<kapowaz>
like I said before, I doubt I would have time to properly assist with the website, but one thing I could potentially do is create some templates which set out basic styles based on the kind of content you're likely to have on the site (headings, paragraphs, lists, code blocks etc.)
<kapowaz>
then somebody else could implement them.
<solnic>
kapowaz: can I write that you're the author? (dooh)
<kapowaz>
of course :)
<solnic>
kk
snusnu1 has joined #rom-rb
jonhinson has joined #rom-rb
jonhinson has quit [Quit: jonhinson]
jnicklas has joined #rom-rb
<jnicklas>
Hello guys! I'm using Virtus, and I have an attribute which has a type like this: Hash[CamelCaseString => Integer], where CamelCaseString is a custom coercer that I've written, like the README suggests. It seems like the coercer is never called though.
<jnicklas>
solnic: ping ;)
kpwz has joined #rom-rb
<solnic>
jnicklas: hey, I'll be here in a minute
<solnic>
or two
<solnic>
jnicklas: that can't work
<solnic>
jnicklas: with Hash[key_key => value_type] syntax you're supposed to pass in types
<solnic>
you can't pass in coercer classes
<jnicklas>
solnic: agh, can I make a type with similar behaviour? Or is it not possible to make your own types?
<solnic>
jnicklas: you could register a coercer for a custom type and just use Hash[MyType => Integer]
<solnic>
I haven't added any DSLs to simplify this yet
<solnic>
so it's still a bit "low level" plumbing
<jnicklas>
solnic: that sounds good. is it documented anywhere how you would do that?
<solnic>
jnicklas: not really, I must say I haven't done it yet :)
<jnicklas>
solnic: hehe :) seems like I'm on thin ice then. I tried to follow the code and see how it's supposed to work, but it's not easy to figure out how everything fits together.
<solnic>
jnicklas: yes mostly because it's not finished :)
<solnic>
jnicklas: I'll try to make it work and see what's needed and get back to you ~tomorrow. would that work for you?
<jnicklas>
solnic: it seems a bit strange to me that there would be a fundamental difference in how coercion works, between Foo, Array[Foo], and Hash[Foo => Bar], seems like they should all work the same, no?
<jnicklas>
solnic: I have a workaround in place, in the meantime, so it's not the critical.
<solnic>
jnicklas: for 1.0.0 final I'm planning to add a simple do use dsl to introduce new coercers and custom types
<solnic>
there should be no fundamental difference between Array[Foo] and Hash[Foo => Bar]
<solnic>
if there is, then it's a bug
<jnicklas>
Well, the main problem is that there is a difference between `attribute :foo, Foo` and `attribute :foo, Hash[Foo => String]`. That doesn
<jnicklas>
… 't seem intuitive.
<jnicklas>
I think Array and Hash work the same.
<solnic>
jnicklas: actually this just boils down to using embedded values in array/hash member and key/value coercions
<solnic>
I'm pretty sure Array works with embedded values
<solnic>
looks like we've got a problem with hashes
<solnic>
so yeah, you actually shouldn't need a custom coercer if you want to use EV
snusnu1 has quit [Quit: Leaving.]
<jnicklas>
solnic: in my case, CamelCaseString isn't really an embedded value though, it's just a thin wrapper around String, so that I don't manually have to convert stuff to camel case when I send in input.
<solnic>
a-ha
<solnic>
right
<solnic>
yeah that would require a custom type and coercer :/
knowtheory has joined #rom-rb
<cored>
morning all
zirni has quit [Ping timeout: 246 seconds]
snusnu1 has joined #rom-rb
<solnic>
jnicklas: I need to finish this stuff, I looked at the code now and it's not trivial to make it easily work right now
<jnicklas>
solnic: no worries.
<solnic>
jnicklas: basically right now hash key/value coercion can only handle primitive types, which basically is a regression vs 0.5.x
<solnic>
there's also a difference between coercing something from one type into another
<jnicklas>
solnic: agh, okay, we could try to figure it out with 0.5.x then?
<solnic>
and formatting something into some other form but maintaining the type
<solnic>
which is what you are doing
<jnicklas>
we're not really using anything special in 1.0.0.beta so we could just as well downgrade
<solnic>
in 0.5.x hash key/value coercion uses entire attribute instance to do its job, so I suspect if you just created a custom attribute and implement #coerce it would just work™
<solnic>
so basically CameCased = Class.new(Virtus::Attribute::String) { def coerce(input); super.camelcase; end } should work
<solnic>
jnicklas: ^
<jnicklas>
solnic: so simple :) worked perfectly, thanks!
<solnic>
jnicklas: yeah :)
splattael has quit [Quit: Leaving.]
mbj has joined #rom-rb
jnicklas has quit [Quit: jnicklas]
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
yo mbj, around?
<mbj>
snusnu: jo
<snusnu>
mbj: got a minute to talk substation?
<snusnu>
mbj: i pushed initial support for defining failure chains and now i'm wondering, if it even makes sense to define incoming processors and the pivot processor *without* defining a failure chain
<mbj>
snusnu: We can default to a "raise" action?
<snusnu>
mbj: i've thought about that too, but i wonder if it makes any sense tbh
<snusnu>
mbj: what i want, is that if you invoke a chain, you're guaranteed to get a valid response back, it can be an error response, but imo no exceptions should just bubble through
<mbj>
snusnu: gotcha
<mbj>
snusnu: yeah
<mbj>
snusnu: That is the same thing as in ducktrap
<snusnu>
mbj: so by default, we could just wrap it in some InternalError object, but imo that decision should be left to the user
<mbj>
Regardless how malformed your input is, it should NOT raise an exception.
<snusnu>
right!
<mbj>
Just return Result#success? => false
<mbj>
sync
<mbj>
Forgot my own design rule :D
<snusnu>
heh
<mbj>
snusnu: So what you propose?
<mbj>
snusnu: Each element of the chain should have a failure attribute?
<mbj>
Or point to the head of a "failure consumption chain" ?
<mbj>
For me the invoking object receives a #success? => false
<snusnu>
mbj: so what i think of working towards, is that if you don't pass a failure chain to any *incoming* processor and the pivot processor, substation should not allow it
<mbj>
snusnu: If you have a failer in a chain of A => B => C => D
<snusnu>
mbj: outgoing processors (currently there's only #wrap, but #render will likely be added in clients) don't need a failure chain
<mbj>
And you have a failer in B => C it should not invoke D, yeah.
<mbj>
s/failer/failure/
<mbj>
Thought it is already that way :D
<snusnu>
yeah, every processor up to the pivot should have a failure chain attached
<snusnu>
outgoing processors (those after the pivot), not
<snusnu>
well it kinda is that way, but you can still construct invalid chains
<snusnu>
mbj: that's how you define the failure chains
<snusnu>
mbj: so the plan is, to make substation raise an error, if you don't pass the failure chain block to #evaluate and #call
<snusnu>
mbj: but allow it for #wrap
<mbj>
snusnu: Mhhh, cant we pass a noop failure chain per default?
<mbj>
That one that returns the first failed response?
<snusnu>
mbj: yeah i was thinking about that too, but then again, it would somewhat imply that ougoing processors *can* have a failure chain, when imho, semantically, that's bullshit
<mbj>
Basically a failure chain is a failure presenter!
<mbj>
So if you dont want to present anyhting
<snusnu>
mbj: once you've computed the response of a usecase, all you do is "make it look nicer", if something goes wrong in there, it's a *bug*, nothing to rescue
<mbj>
Just say: No, I dont need this input.
<mbj>
I got this.
<mbj>
snusnu: So why we need a failure chain?
<snusnu>
mbj: in that case, we don't need it, in fact, don't want it, that's the point
<mbj>
snusnu: So give me a case we want it!
<snusnu>
mbj: so i'm wondering how sharp i want to make the api … simply not allowing it for outgoing processors would be best imo
havenwood has joined #rom-rb
<mbj>
snusnu: So give me a case I'd use a failure chain!
<snusnu>
mbj: once the response is computed, on the way out, all you do is "make that look nicer" … if you register a processor that makes it nicer (an outgoing one), you won't ever need a failure chain, as those processors imo can't alter the "fail state" of the response, only the "look of it"
<snusnu>
mbj: well, you'd use a failure chain for all incoming processors (like ducktrap and vanguard and the actual action)
<snusnu>
mbj: but you'd never use them for everything "on the way out"
<mbj>
snusnu: I got this.
<mbj>
snusnu: But pls give me a scenario I want to use an failure chain for an incoming request?
<snusnu>
mbj: huh? like i said, every action guarded with ducktrap and/or vanguard
<mbj>
Someting like a chain does foo, bar, than there is a failure baz, but you want to process baz before getting an result.
<snusnu>
mbj: look at the changelog example i linked
<mbj>
Soesnt that action just result in Response#success? => false
<snusnu>
mbj: you eventually want to return a response that the client can consume
<snusnu>
mbj: like, first wrap it in some object, and then render it, or whatever
<mbj>
So basically not EACH item in the chain has a failure chain.
<mbj>
You wrap the WHOLE chain into a failure chain?
<snusnu>
mbj: only incoming processors and the pivot have
<snusnu>
no
<mbj>
If this is my actions code:
<snusnu>
mbj: it's important that every step on the way in has it's own failure chain
<mbj>
response = chain.call(some_cool_input)
<mbj>
if response.success?
<mbj>
send_response(response)
<mbj>
else
<mbj>
send_response(failure_chain.call(response))
<mbj>
end
<snusnu>
right, that's basically what the current evaluator does
<snusnu>
(as linked)
<mbj>
jo
<mbj>
But the problem is you dont know where the error was, so your chain has to detect if it is a ducktrap, or a vanguard error
<mbj>
(your failure chain)
<mbj>
So you associate each action with the head of a failure chain!
<snusnu>
mbj: i should maybe mention: i want my "routes" to *only* call the chain, nothing else, i want *all my fucking logic* OUTSIDE of any http stuff
<mbj>
snusnu: got it!
<mbj>
That concept is really nice (also for logging).
<mbj>
Just add a logger inside the chain, one incoming one outgoing and one just before the pivot or sth.
<snusnu>
yeah, for example
<mbj>
snusnu: So let me iterate on that failure chain
<mbj>
If I have three actions: A, B, C in a chain X
<mbj>
EACH action has ists own failure chain!?
<snusnu>
if by action you mean incoming processors, then yes
<mbj>
So if chain has to stop at A, another failure chain gets invoked as when stopping on B
<mbj>
So what if a failure chain has an error?
<snusnu>
yes
<mbj>
raise IMHO!
<snusnu>
wdym? a bug? is a bug
<mbj>
Yeah, just tried to see if you'd introduce failure chains for failure chains :D
<snusnu>
failure chains are *outgoing* chains
<mbj>
Yeah
<mbj>
Okay, basically you build the heard of a web framework IMHO.
<mbj>
s/framework/lib/
<mbj>
lulzs
<mbj>
Okay for me. Sorry for digging so hard.
<mbj>
But I had the see the full story.
<snusnu>
no, i build a framework/lib that doesn't care wether it's going to be used on the web :D
<snusnu>
i want to structure my code
<snusnu>
lol
<mbj>
Yeah
<snusnu>
and i want guidance, substation is that guidance
<mbj>
So you build a lib that you can use as the core for a web framework
<snusnu>
yeah
<snusnu>
it's about making sure that *all the logic* is in your APP
<mbj>
snusnu: I totally got it, sorry for binding it to the web. I knew it is not bound there.
<mbj>
You talk with MR decoupling, you know.
<snusnu>
i know :)
<mbj>
snusnu: BTW did you had success with mutant-0.3.0 ?
<snusnu>
MR decoupling?
<snusnu>
mbj: haven't yet tried
<snusnu>
mbj: will do so for substation 0.0.9
<mbj>
snusnu: nice!
<snusnu>
mbj: 0.0.9 will be released when mutant 0.3 shows no mutations
<mbj>
snusnu: And the bugs in mutant are fixed that prevent 0.0.9 to show mutations :D
<mbj>
But dkubb did a bug hunt round already!
<snusnu>
mbj: yeah, i've skimmed through the shitloads of commits you guys did while i was away :)
<snusnu>
awesome work
<mbj>
snusnu: I'm still missing to read all stuff that happened in rom-rb/*
<mbj>
TOO BUSY!
zirni has joined #rom-rb
<mbj>
Had to focus on mutant, helps us more IMHO.
<snusnu>
i know how it goes
<snusnu>
yeah
<mbj>
zirni: hola
<snusnu>
mbj: so, re substation once again: do you agree that we should prevent registering failure chains with outgoing processors, but make them *required* for incoming processors and the pivot processor?
<mbj>
snusnu: IMHO we should do a noop default.
<mbj>
snusnu: So if your app at some point invokes the root chain, it should return 500 per default. If you'd like to have more detailed status codes you can always add a failure chain.
<snusnu>
mbj: wdym by "at some point invokes the root chain"?
<mbj>
snusnu: Better 400, unknown serverside error, but client should be blamed. If you have a failure chain that produces sth other, result#success? would return true and the response would be build.
<mbj>
snusnu: WEB-App-Context: You have a router, request comes in and is mapped to an action name.
<mbj>
snusnu: This is the "root chain call" I told about.
<mbj>
snusnu: Now you get a Response object back
zirni has quit [Ping timeout: 255 seconds]
<mbj>
snusnu: Your webapp should default to return a 400 on Response#success? => false
<mbj>
snusnu: But if there was an error from within the chain that was handled by a failure chain you get Response#success and send Response#output (wich is an http response?)
<mbj>
snusnu: So response#success? tells you if you can ouse Response#output or not.
<mbj>
if it is "valid at this stage".
dkubb has joined #rom-rb
<mbj>
This is how I imagine it, feel free to tell me your scenario!
<mbj>
dkubb: hola!
* mbj
is visiting toilet, will take some min
<snusnu>
lol
<dkubb>
good morning
<dkubb>
hah
<snusnu>
good morning dkubb
<dkubb>
snusnu: hey man
<mbj>
lets do a hangout later, I'd love to at least "see" the brains behind the nicks I spend lots of time with :D
<snusnu>
mbj: i for one don't have a googleplus account (or any other social network for that matter, well, apart from github lol)
<dkubb>
I forget that github has a social network built in
<dkubb>
it's funny that so many startups are trying to be "$something + social network", yet I almost never see it done well. github is the only one that comes to mind as being good
<snusnu>
dkubb: yeah, imo the social network aspect in github is closely tied to the "fact" that people registered there really share a common interest, oss
<snusnu>
dkubb: that's narrow enough to work (and be interesting for me too ;)
<snusnu>
dkubb: since it helps its users to communicate about a particular area of interest, "real" social networks evolve (like our small network rom, or larger ones like rails)
<snusnu>
well, that's at least how i see it
<dkubb>
yeah
<dkubb>
it feels so forced in other cases
<dkubb>
the main reason for assembling has to be really strong. the problem is most of these sites try to just tack it on to something faceook-like
<dkubb>
mbj: did you get a chance to release mutant 0.3.beta5? I think we've accumulated enough fixes that we should drop a gem
<cored>
hello dkubb
<cored>
I'm still kinda stuck with making axiom use axiom-types
<cored>
still NoMethodError
<dkubb>
cored: maybe I can do one type as a start?
<dkubb>
then you have an example to work with as reference
<cored>
dkubb: perfect
<cored>
dkubb: don't know if you want to work on the current open pull request
<snusnu>
dkubb: btw, i saw you guys talking about a "web framework" .. i'd love it if you could take a look at https://github.com/snusnu/substation at some point, and tell me what you think about it .. basically, it's a "chain of responsibility" implementation .. it definitely is NO web framework, and it shouldn't be, but a chain of responsibility imo happens to be a nice pattern to "structure" any app with a request/response cycle
<cored>
or just start from scratch
<cored>
?
<snusnu>
dkubb: and btw, it's developed in dm2/rom style, completely immutable + mutation covered
<dkubb>
snusnu: very cool. I'll check it out
<snusnu>
dkubb: basically, it guides you to an architecture pretty much like uncle bob layed it out .. some boundary interface that exposes all your app's usecases, which are implemented as chains "around" your actual usecase, which is implemented in a dedicated object, and works with your business entities
<snusnu>
dkubb: https://github.com/snusnu/substation-demo shows it in use in a simple sinatra app, using ducktrap, vanguard and rom (or rather, the code that was dm-mapper)
<solnic>
mbj: +1 re hangout :) I haven't spoken with you guys for a looooong time
<solnic>
mbjL and *never* talked with you except chatting on irc :)
<solnic>
dkubb, snusnu: and hi :)
<snusnu>
solnic: yo :)
<mbj>
back
<solnic>
snusnu: yeah re shitloads of commits, I rewrote rom-session :P
<solnic>
and actually turned it into a session with state tracking
<solnic>
and just pushed flushing today
<snusnu>
solnic: i saw that dude, very awesome!
<snusnu>
solnic: haven't had a close look yet, but i will do that soon
<solnic>
injecting UoW will be easy (in theory)
zirni has joined #rom-rb
<solnic>
anyhow, dinner time, ttyl
<snusnu>
solnic: njoy
<cored>
going to cook/lunch brb
<mbj>
dkubb: No beta5 did not made it still know a bug that crashes mutant/unparser
<mbj>
dkubb: mutations on (left - right) / other
zirni has quit [Ping timeout: 248 seconds]
<snusnu>
mbj: you have a good point saying that a failure chain should always return a successful response
<mbj>
snusnu: no
<mbj>
snusnu: It does not feel right
<mbj>
mom phone
havenwood has quit [Read error: Connection reset by peer]
lorenzoo has quit [Remote host closed the connection]
<snusnu>
mbj: another "tricky" aspect is this: failure chains for invoking an action that should return HTML, will be different from those that should return JSON, while in fact, the actual action is the same
<snusnu>
mbj: so currently, i construct chains up to the pivot, and then either build HTML or JSON actions on top of those
<snusnu>
mbj: this allows me to reuse my actual business logic, and only alter the "presentation" layer when that business logic gets invoked in a web context
<snusnu>
mbj: so what i'm getting at is this: the "base" chains that have no outgoing processors, probably can't specifiy their failure chains, as they'd need to be specified differently for either html or json actions … hmm
<mbj>
snusnu: You have to kill mutations in #initialize via the singleton public interface.
<mbj>
snusnu: you like the new reporter?
dkubb has joined #rom-rb
<snusnu>
mbj: i don't have any initialize_spec.rb files
<dkubb>
mbj: btw, beta4 wpm
<dkubb>
whoops
<mbj>
dkubb: ?
<dkubb>
beta4 can't kill #initialize mutations
<dkubb>
there's a bug in it that I fixed on edge
<mbj>
I'll release beta5 mow, mom.
<snusnu>
sweet
<snusnu>
heh
<dkubb>
the glob expression was invalid, so it would return [] for the spec files
zirni has joined #rom-rb
<dkubb>
when I see "mom" I keep thinking someone is calling me their mother
<mbj>
dkubb: hehe
<dkubb>
like I'm nagging them about something
<dkubb>
snusnu: so to kill mutations in #initialize you can either rely on the other public instance method's specs to cover the cases, or you can write a spec in ./class_methods/new_spec.rb
cored has joined #rom-rb
<mbj>
pushed!
<dkubb>
sweet
<mbj>
dkubb: The bug with (left - right) / other is still in
<dkubb>
I will update devtools now
<dkubb>
mbj: what does that do?
<snusnu>
mbj: nice! mutant master found one new mutation in substation, everything else works now
<snusnu>
- unless response.success?
<mbj>
dkubb: If mutant tries to mutate that expression unparser will crash
<snusnu>
+ unless false
<dkubb>
mbj: I mean, what kind of error happens.. obviously I know what it does
<mbj>
I'm still no 100% sure if mutant creates an invalid ast, or unparser has a bug.
<dkubb>
ahh ok
<mbj>
It seems mutant is converting this to (- right) / other
<mbj>
so calling "-" on implicit self.
<mbj>
This does obviousely not work.
<mbj>
method operators need a lhs and rhs.
<mbj>
But I could not reproduce this crash from mutator specs, which worries me.
<dkubb>
btw, I think in the future you may want to use the numbering scheme: 0.3.0.beta1
<mbj>
I can repro with a script calling Mutant::Mutator.each(parse("(left - right) / foo"))
<dkubb>
because 0.3.0.beta1 is > 0.3.beta5 according to ruby
<mbj>
woot?
<mbj>
okay
<mbj>
noted.
<mbj>
I just followed whitequark, he did 2.0.beta{1-7}
<dkubb>
I also think the "3 dots.{alpha,beta}n" is more standard
<elskwid>
Hoedy everyone!
<mbj>
elskwid: hi
<dkubb>
elskwid: hello
<elskwid>
or howdy even
<elskwid>
sheesh
<snusnu>
mbj: are you in the process of updating devtools to reference the new beta, or shall i do it?
<mbj>
dkubb: Let me jank that releases, I'll rerelease!
* elskwid
quits before he starts
<mbj>
snusnu: dkubb is doing
<snusnu>
mbj: ok, do your thing then :p
<snusnu>
oh ok
<mbj>
but both stop I'll yank the invalid releases.
<dkubb>
heh
<dkubb>
I would just release this as 3.0.0.beta1 or something
<dkubb>
unless there already is one
<dkubb>
or you can have it be beta5. it doesn't really matter since it'll be out of beta shortly
<mbj>
done, released as mutant-0.3.0.beta1
<mbj>
lulz
<mbj>
I had a mutant-0.3.0.beta1, before I switched to mutant-0.3.beta1 scheme
<mbj>
As we cannot "unyank", I'll now do mutant-0.3.0.beta2
<dkubb>
yeah it's stupid they won't let us do that
<dkubb>
sometimes the maintainer really does know better
<solnic>
+1
<mbj>
done
<dkubb>
ok, updating devtools, one sec
<mbj>
BTW I'll not release mutant-0.3.0 once parser-2.0.0 is still in beta
<mbj>
Its interface can still change.
<dkubb>
yeah, right
<mbj>
Especially he ast received some (needed) changes in the beta phase.
<dkubb>
as long as there are some gems to rely on
<mbj>
As we are all here, should we shedule a skype/g+ meeting?
<mbj>
I'd love to see faces, at least once ;)
<snusnu>
i'm fine with skype, i don't and won't have a g+ account
<dkubb>
skype is fine
<mbj>
okaywith me, but I heard solnic has problems?
<mbj>
solnic: Can you use a *phone ?
<mbj>
It is unlikely we can convince snusnu into g+, I tried :D
<snusnu>
hehe truedat
<snusnu>
mbj: btw, i like the new reporter!
<mbj>
snusnu: nice
<dkubb>
yeah mutant is coming along really nicely
<mbj>
elskwid: You had problems with the new reporter?
<dkubb>
if we get zombie support for 0.4.0 that'll bring it up a long way
<mbj>
elskwid: This is your time to convince me for a change :D
<mbj>
dkubb: Zombie support isnt that hard, I hacked it un 15min in melbourne/to_source days.
<mbj>
dkubb: But this was only for mutant, recursing into deps is a "littlebit" more tricky
theCrab has quit [Quit: Gone Forever!]
<mbj>
But I plan to ease the job via a manual "zombification path"
<mbj>
Vendoring dependencies before dependants.
<mbj>
We dont have a cycle! so [ice_nine, descendants_tracker, equalizer, adamantium, inflecto, mutant].each { |nane| Mutant::Zombifier.zombify(name) }
<dkubb>
yah
<dkubb>
I like just vendoring it to start
<mbj>
Rubies nice "dynamic constant lookup" will make sure vendored adamantium will use vendored ice_nine
<solnic>
mbj: inability to call super in initialize when using Concord - bug or a feature?
<dkubb>
then we can at least get mutant and the deps to a really nice state first
<dkubb>
it's nicer to add features to something already mutation covered imho
<mbj>
solnic: feature
<mbj>
solnic: But if you need it I can add support for this.
<solnic>
thought so
<dkubb>
once you get something fully mutation covered it doesn't feel too hard to keep it there.. it's getting it there in the first place
<solnic>
well yes, I pretty much need it
<mbj>
solnic: I'd add an #initialize_concord that gets called from #initialize, so you are free to call super in initialize but would need to call #initialize_concord by hand in this scenario
<mbj>
solnic: okay?
<solnic>
mbj: blah :(
<solnic>
NO :D
<mbj>
mhhh
<dkubb>
mbj: is there no way to make it work with super?
<solnic>
+1
<mbj>
Question: Who calls super?
<dkubb>
fwiw, when I run into these kinds of issues there almost always is a way
<mbj>
Instance of a subclass?
<mbj>
Should work, ootb
<mbj>
Or "instance of concord infected class" ? concord generates an #initialize, I dont see a way to make it work in this scenario, apart from calling super() per default.
<mbj>
solnic: Doing a super() per default?
<dkubb>
ok, gtg back to work. I just wanted to make sure the next mutant beta was released for my work tonight! ;)
<mbj>
Most concord classes inherit from Object, so doing super would raise ArgumentError
<mbj>
super wo args is called zsuper btw.
<mbj>
so zsuper would not work here.
<mbj>
solnic: You are also free to override #initialize, and store ivars for yourself, in this case you still get Equalizer, and attr_readers for free.
<solnic>
mbj: true
<solnic>
that's *something* ;)
<mbj>
elskwid: Sorry mixed up your nick with envygees, both have an "e" prefix :D, he asked about mutant being to verbose.
<mbj>
solnic: So overriding super is okay for you?
<mbj>
s/super/#initialize/
<mbj>
I have to run, 2min.
<snusnu>
mbj: just pushed a spec fix that makes substation pass mutant 0.3.0.beta2
<mbj>
Gibheer: Mutations must be observable from the specs
<mbj>
Gibheer: So, no
<solnic>
snusnu: it's the first proposal from kapowaz
<mbj>
Gibheer: Also gvars are not affected by any module prefix.
<Gibheer>
so instead of mutating Rom::, you create MutationSpace::Rom
<Gibheer>
that's true :/
<solnic>
snusnu: there were also some 8-bit suggestions but I kinda dislike them
<mbj>
Gibheer: Preloading the rspec tests gives a 5x speedup, but rspec is nitpicking about world reuse.
<Gibheer>
but with the parser you should be able to move everything into a namespace, so that would have been a possibility
<mbj>
Gibheer: It simply does not expect it is NOT the outermost tool to run.
<mbj>
Gibheer: Gvars and mutated metaprogrmaming can stil leak!
<mbj>
Gibheer: Also instances can leak in ObjectSpace, so a killfork is sane.
<snusnu>
solnic: actually, i like it, but i somewhat don't like ROM written out below the logo
<mbj>
Gibheer: I think sandboxing will never be removed!
<snusnu>
bbiab
<mbj>
Gibheer: But for example we could reuse the rspec-world
<mbj>
Gibheer: And reduce parser/unparser use, this would in sum give a 10x speedup.
<solnic>
snusnu: putting it inside the gem looks bad (we tried)
<Gibheer>
mbj: yeah, true
<mbj>
Gibheer: Also we could parallelize mutation kills to keep cores busy
<solnic>
snusnu: I thought about reducing number of colors if possible or making them less vibrant (however I really like them but people complain they are too flashy/vibrant whatever)
<mbj>
Gibheer: I'd spawn a kill fork proactively per core
<mbj>
Gibheer: Pulling mutations via zmq, executing mutation, publishing result and nuke self.
<mbj>
Gibheer: This would also dramatically speedup killing!
<Gibheer>
yeah
<mbj>
Gibheer: At first I'd parralelize only a subjects mutation, later we can go cross subject!
<mbj>
Gibheer: I expect it would be fast enough with world preserving and some parser/unparser reductions.
<Gibheer>
mbj: as we get more and more cores, I would think so too
<mbj>
Gibheer: jo, you could also split the subjects between machines
<mbj>
Gibheer: But TBH I dont have the time to do all that tricky optimizations, I'll do the obvious stuff.
<mbj>
Gibheer: For example we could load the spec/**/*_spec.rb contents before entering the kill fork, without loading the rspec world (if this is possible)
<Gibheer>
hehe, sure
<mbj>
Gibheer: But the stuff in spec/**/*_spec.rb needs to register inside the rspec world.
<mbj>
Gibheer: I read lots of rspec sources and felt I'd have to write my own spec framework to make mutant "really" fast.
<mbj>
solnic: Reached 3.6k yearly opensource contributions, once I have 4k you'll have to tweet again.
<mbj>
Gibheer: If we dont do as much work inside the fork, we'll have the biggest speedups, currently all stuff inside spec/**/*_spec.rb will gets parsed PER FORK.
<Gibheer>
mbj: hehe, yeah
<Gibheer>
no code is still the fastest code
<mbj>
Gibheer: So reducing the amountof "needlessly redone" work is the key.
<mbj>
Gibheer: Instead of improving the parralelism of redoing work.
<mbj>
Gibheer: Especially if the parsing and rspec setup is around 80% of the work per fork.
<Gibheer>
wow, that is much
<mbj>
Gibheer: You expect execution of some stored blocks with some expectations is lots of work?
<mbj>
have to run, already over time, cu laters.
mbj has quit [Quit: leaving]
<snusnu>
solnic: fwiw, i like the colors!
<solnic>
snusnu: me too
<solnic>
snusnu: also there's some nice symbology there
<snusnu>
yeah
<snusnu>
solnic: i wonder, what exactly wouldn't work with putting the name inside the gem
<snusnu>
?
<solnic>
too cluttered, too small font, wouldn't work in smaller sizes
<snusnu>
solnic: but we need the name, right?
<snusnu>
solnic: i for one wouldn't need it btw
<snusnu>
;)
<solnic>
snusnu: yes? :P
<solnic>
snusnu: well, apple doesn't need it but
<solnic>
show a good symbol for RUBY OBJECT MAPPER
<solnic>
LOL
<snusnu>
hehe
<solnic>
it would be a nice riddle lol
<solnic>
"WHAT IS ON THE PICTURE?!"
<snusnu>
bbiab
snusnu has quit [Quit: Leaving.]
kleech has joined #rom-rb
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu has quit [Ping timeout: 256 seconds]
kleech has quit [Remote host closed the connection]
mbj has joined #rom-rb
<solnic>
mbj: getting stack level too deep when running mutant against rom-relation and rom-mapper ;(
<mbj>
solnic: reproducible?
<solnic>
mbj: hmm?
<mbj>
solnic: So can I clone, run and see that error?
<solnic>
mbj: yes pretty much
<mbj>
solnic: okay
<solnic>
mbj: I ran it like that: "mutant 'ROM::Relation*' --rspec-unit"
<solnic>
or --rspec-dm2
<solnic>
doesn't matter
<solnic>
I'm pretty sure it will boil down to bogus again :P
<mbj>
hehe
<mbj>
lemme try
<mbj>
solnic: just released mutant-0.3.0.beta3, fixes last known bug.
<kapowaz>
snusnu1: I kind of agree.
<kapowaz>
an earlier version of the logo had a different, custom typeface which I think worked better. The text at the moment feels a little lost in my view.
<kapowaz>
that said, I don't think it's that important — it's the symbol that will make it distinctive, and you can put text either below or to the side of it depending on context
snusnu1 has quit [Quit: Leaving.]
<kapowaz>
:o
<kapowaz>
outrageous!
snusnu has joined #rom-rb
<mbj>
solnic: What is your workaround for bogus and Class#name ?
<snusnu>
kapowaz: right, i guess that's inline with my feeling that the text actually isn't that important, i find the logo itself very memorable
<kapowaz>
good :)
<kapowaz>
glad to hear it.
<kapowaz>
I've been reading all the comments and critiques
<snusnu>
kapowaz: nice work! very much appreciated!
<kapowaz>
re: similarity to the webplatform.org logo — I think there is *some* resemblance, but not that much. The ruby gem shape is more distinctive, plus it's opaque colours rather than merged transparent ones.
<kapowaz>
and as for the issue with the colours… I resent the notion that Google somehow has proprietary ownership of all shades of red, green, blue and yellow.
<kapowaz>
they're not the same shades, plus there are two other colours there that Google *don't* use.
<kapowaz>
aaaanyway, those are my feelings on the critiques ;)
<kapowaz>
I'm sure there will be more.
<snusnu>
kapowaz: re the similarity to webplatform.org logo .. i don't see any :p
<kapowaz>
they're both comprised of sequences of rounded rectangles
<kapowaz>
each of which is a different colour
<kapowaz>
but… that's about it.
<kapowaz>
that's the thing when working with simple primitives — it's easy for a couple of people to independently have a similiar idea
<mbj>
solnic: I cannot reproduce the crash in rom-relation
<solnic>
I don't have a very strong opinion on this
<solnic>
it's just that many MANY ppl complained about our compact style
<solnic>
including guys from rspec core stating that we're doing it completely wrong
<snusnu>
dkubb: ok, i get how that's nicer, and i'm actually not against using #expect .. what i'm concerned with, is that we will want to switch styles, based on the context .. e.g. i wouldn't want to test an attr_reader using this expect
<solnic>
which was fine, I guess, until I heard complaints from ppl trying to understand our specs
<dkubb>
the other advantage of going this way is that it's lighter weight
<mbj>
dkubb: As you jump in channel and are in sync directly about the topic discussed, you read the logs :D
<dkubb>
there's less magic involved, which probably reduces some of the need for all that rspec weight
<dkubb>
yeah I did read the logs before jumping in
<dkubb>
usually I only read the last few 10-15 lines
<solnic>
and yeah, new rspec syntax must be used in new specs, that's out of the question, otherwise we'll be blocked with upgrading to rspec3
<dkubb>
I'm experimenting with the new rspec syntax for all my new gems
<snusnu>
solnic: so, our way of using rspec isn't supported anymore in rspec3 ?
<dkubb>
solnic: and we know how much we all hate being blocked from upgrading rspec
<dkubb>
I still have rspec 1 gems :(
<dkubb>
mostly because they are mutant deps, and they can't currently be mutated with mutant.. so I have to use heckle with them
<solnic>
snusnu: I think you are confusing things. I used expect there because I wanted to have a description for my example, so no it { should foo } but it('something') { expect(foo).to blah }
<dkubb>
which is why I can't wait for vendoring those gems in mutant, so they can eb mutated
<snusnu>
solnic: really? for that example i linked?
<snusnu>
:p
<solnic>
I think the usage of implicit subject will be still suported in rspec3 so we should be safe
<snusnu>
solnic: btw, that actually was the first (and only) spec i looked at
<solnic>
although I'll better check with rspec guys
<snusnu>
solnic: what is this "implicit subject"? (pardon my stupidity)
<solnic>
snusnu: it { should foo }
<snusnu>
solnic: is it that inside the block, self is subject?
<solnic>
that's implicit subject
<dkubb>
yeah, the subject is implicit, os it's the same as: it { subject.should foo }
<dkubb>
*so
<snusnu>
right, just wanted to make sure
<snusnu>
i really like the conciseness of that btw
<snusnu>
would be a pity to see it go
<dkubb>
ok, just popped in for a sec. about to get lunch now.. bbl ;)
<solnic>
well, the code itself is nice, but rspec output is shitty in many cases
<snusnu>
dude who cares
<snusnu>
i see green dots
<solnic>
that's kinda true
cored has quit [Ping timeout: 256 seconds]
<snusnu>
solnic: i guess you were a bit unlucky, in that i looked at an arity 0 method and you happened to use the expect style :)
<snusnu>
solnic: i totally see how some examples benefit from a descriptive line
<snusnu>
solnic: just, not all of them do
cored has joined #rom-rb
cored has joined #rom-rb
<solnic>
yeah I also hate stuff like that : it { some_mocking_expectation; subject }
<snusnu>
yeah, altho i rarely had to do it
<solnic>
not only does it look silly but it's also hard to follow
<solnic>
well, not in this particular example obviously :P
<solnic>
but I guess you're right about the output
zirni has quit [Ping timeout: 248 seconds]
<solnic>
I mean, I have never ever used rspec output for anything, anywhere
<snusnu>
never ever
<solnic>
if I want to learn how a lib works, I read its docs and/or code
<solnic>
the effort to document your api with rspec > writing docs
<solnic>
also, we neeed docs ANYWAY
<snusnu>
yeah me too, sometimes i look at the spec to see how stuff is invoked, but it's rare
<snusnu>
yeah
<snusnu>
solnic: so, i think we should have some "rules" as to when we use implicit subject and when not?
<snusnu>
solnic: i'd hate it if our specs would be completely mix/match without a specific reason
<snusnu>
solnic: that'd make them even harder to grok for ppl
<solnic>
snusnu: if the goal is to keep specs as short as possible, then we gotta stick to how we were doing it so far
<solnic>
which is setup in before hooks and short one-liner-it-blocks
<solnic>
I'm only saying ppl complained a lot about our specs being hard to read and follow
<solnic>
I'm not making this up
<solnic>
I was used to our style, decided to experiment with a more 'classic' approach now
<snusnu>
solnic: wdym by setup in before hooks? can't we #let them anymore?
<solnic>
making you angry at the same time :D
<snusnu>
hehe
<snusnu>
angry is the wrong word :p
<snusnu>
wary of change maybe. mwhah
<solnic>
snusnu: I meant stuff like stubing something
<solnic>
setup
<solnic>
not building test objects
<solnic>
test objects should be in let{}
<snusnu>
so, here's a question … are we being influenced by people who are used to writing *application* specs?
<snusnu>
we're writing a lib ....
<solnic>
good point
<solnic>
snusnu: well, I kinda want to make it easy to contribute to our code, as you know
<solnic>
that's my motivation
<solnic>
just ask elskwid if it was easy for him to grasp our spec style
<solnic>
I had few cases where ppl would tell sth like "oh hey I thought I could fix it but then I had no idea how to write a spec for it"
<solnic>
which is like...alarming imho
<snusnu>
solnic: well … i dunno
<solnic>
well, if I can have people helping me with bug fixes and adding new features, then I want to make sure it's easy to contribute
<solnic>
I'm not saying that our spec style is discouraging, but it's definitely not helping
<snusnu>
solnic: i guess i just never found our spec style hard to follow .. it was the "clearest" i've seen so far actually … use implicit subject as much as possible, make the subject *exactly* what the "description" says .. i mean, it obviously works very well for testing a method in isolation
<snusnu>
anyone can write the spec the way they want? we could always refactor them ourselves, or motivate the contributors to do so?
<snusnu>
yeah, i'm all concerned about consistency, especially if the problem is contribution barrier
<solnic>
oh because we actually rely on those interfaces there and loader/dumper are tested in isolation
<solnic>
mapper is a simple object composed of the two
<solnic>
the heavy stuff is happening in loader/dumper which are also part of public apis (as in, you can provide your own loaders/dumpers if you want)
<snusnu>
ah ok, that's with bogus right, and it checks if the interface is present
<solnic>
yes that too
<solnic>
which is like, AWESOME
<solnic>
:P
<snusnu>
yeah
<snusnu>
and it only takes the "methods", right? i mean, what you give it in the block, the actual type it's faking, the only assumptions it makes is that the actual object provides the exact same methods, right?
<solnic>
yes
<snusnu>
that's really a good thing
<snusnu>
i guess i'm still kinda on the fence with too many detailed it "foo" {} blocks .. i truly like the implicit subject usage of ours, and i don't care about the output
<snusnu>
imo we should keep on using implicit subject whenever it works, and use more descriptive it blocks when we feel that's needed
<snusnu>
that are 2 rules for every potential spec writer
<snusnu>
also, it's 2 completely different things to test a (typical) (rails) app, or to (mutation) test a library written in a functional/immutable oop style
<snusnu>
i honestly don't care if rspec ppl think we're "doing it wrong" .. if it works, it works
<snusnu>
that said, i hope implicit subject will keep on working :p
<snusnu>
otherwise we really need mbj to write the new test framework
<mbj>
snusnu: It will be a dedicated unit test framework
<mbj>
snusnu: Focusing on testing public interfaces
<mbj>
snusnu: Basically you get all syntactic DSL power to specific the message to send to a specific "subject"
<mbj>
snusnu: And to assert sth on the response..., still planning.
<mbj>
snusnu: And it would support a clean loading / running spearation, so we can reuse the parsed code within the kill-fork
<snusnu>
i have this feeling, that no lib should be afraid of a test framework upgrade .. because test frameworks shouldn't need upgrades :p
<snusnu>
btw, what's up with travis? so slow? so unreliable?
<mbj>
snusnu: I use circleci for commercial projects
<mbj>
And more and more for opensourced also, only once I target a release I'm interested in the travis matrix again.
<mbj>
But maybe we can simulate the matrix via a devtools helper, so we can remove the need for travis.
<snusnu>
lol mbj, that reminds me of dm-dev project i wrote years ago, which basically was a crowdrun travis
<solnic>
snusnu: hah
<snusnu>
solnic: :p
<solnic>
yeah, travis is pretty much broken these days
<solnic>
it's very sad
zirni has quit [Ping timeout: 246 seconds]
postmodern has joined #rom-rb
<snusnu>
i still think that given a large enough community, ci would be fastest if run SETI style, on some arbitrary machine somewhere in the world
<snusnu>
hah, not on some machine obviously, but on multiple machines .p
<snusnu>
and
<snusnu>
i don't care about commercial, or to be more specific, non oss code
<snusnu>
hehe
<solnic>
snusnu: maybe
<solnic>
snusnu: we could try :P
<snusnu>
lol
<solnic>
again
<solnic>
;)
<snusnu>
lol
<snusnu>
i'd be up for it i guess
<snusnu>
hehe
<snusnu>
eventually, we'll be in the position again, to test backends that won't work on travis ...
<snusnu>
just sayin ....
<snusnu>
:D
<solnic>
:)
<snusnu>
that's the really nice thing with distributed ci … if someone runs the tests on their windows box using sql server, it can post results to the ci service
<mbj>
going to sleep, need to get up 04:00 in morning to catch a train :(
<solnic>
mbj: sleep tight
<snusnu>
mbj: yeah, good night
mbj has quit [Quit: leaving]
<solnic>
snusnu: this one-spec-per-method is also so-so
<solnic>
snusnu: like I have two methods
<solnic>
#track and #tracking?
<solnic>
I can totally test both in a single test
<solnic>
with --rspec-dm2 I'd have 2 spec files
<solnic>
one totally redundant
<solnic>
oh actually no
<solnic>
I need to test scenario when sth is not being tracked
<solnic>
but then again, I would miss scenario when something is being tracked
<solnic>
if I had both scenarios + spec for #track + #tracking? then it'd introduce redundant specs anyway
<snusnu>
solnic: yeah, i agree with that, but imo that#s a mutant issue
<solnic>
snusnu: funny, I noticed a small perf improvement :P
<snusnu>
solnic: good stuff, i wonder tho, what does e.g. #save return? https://github.com/rom-rb/rom-session/commit/fb0f4225f2d6b1799391f53682111956c547c3d7 in that spec, since you don't make the call to #save the subject, but immediately call #state on it, i dunno what #save returns … would that be a nice fit for #expect ? i guess i'd spec the return value of #save with an implicit subject, and add additional checks for #state with #expect ?
<snusnu>
solnic: (i haven't looked at the implementation at all)
<solnic>
snusnu: well, I call save(user).state(user) so if save no longer returns self it'll blow up
<solnic>
with implicit subject returning self I'd have to add that stupid it { subject; should be_updated } :P
<snusnu>
solnic: why not just it_behaves_like "a command method" plus it "switches to updated state" { expect(subject.state(user)).to be_updated }
<snusnu>
or something like that
<solnic>
but that's MOAH typing :P
<snusnu>
hehe
<snusnu>
solnic: but if for some reason, #save doesn't return self anymore, the specs will tell you why (because the shared command method examples fail)
<snusnu>
solnic: and, it would've told me that #save actually does return self
<snusnu>
:p
<snusnu>
solnic: i dunno, i'm just not used to seeing describe Foo, "#method" … and then *not seeing* subject { something.method }
<snusnu>
hehe
<solnic>
what the 'a command method' shared behavior would be?
<snusnu>
solnic: what i'd like us to move towards to, is that we write tests for methods in isolation, but only for those methods were we decide that they aren't internal .. basically, the "outermost api" that can kill all mutations in all of a class's instance methods (and methods called on dependencies)
<solnic>
yes
<solnic>
totally
<solnic>
I already do that
<snusnu>
solnic: i like that #save spec
<solnic>
speccing everything that has public methods is terrible
<snusnu>
yeah
<snusnu>
but it's only because of mutant, we must not forget this :)
<solnic>
well, I won't be doing that anyway
zirni has quit [Ping timeout: 256 seconds]
<solnic>
I can run --rspec-unit
<snusnu>
solnic: that runs all of a class's specs for every mutation, right?
<solnic>
no it runs all of the unit tests
<solnic>
snusnu: I think mbj has some ideas how to improve that through some kind of configuration
<solnic>
although I fear configuration maintainance nightmare
<snusnu>
imo what we need are those kill expressions he's talking about
<snusnu>
yeah, config might be tricky
<snusnu>
then again, it would also serve as a nice "documentation" showing *why* we specced only the methods we specced
<solnic>
I think @api private would do too :P
<solnic>
well mutant could parse that I guess
<solnic>
and for every class marked as @api private
<solnic>
it would run all unit tests
<snusnu>
what i'm talking about is, that it'd be cool to be able to say: Foo#foo will kill Foo#{bar, baz} and Bar#bla mutations
<solnic>
but that's exactly the config maintanance nightmare I reffered too
<solnic>
that's not nice at all imho
<snusnu>
i'm not sure, i somewhat like the explicitness
<snusnu>
it leaves no question as to wether why there's a spec for a method or not
<solnic>
as I said, @api private says the very same thing
<snusnu>
no? how would mutant know when to stop then? in my world, mutant would track killed mutations, and never try to run specs for those methods again
<solnic>
it could see which classes are marked as private
<solnic>
I dunno
<solnic>
I'm too tired to talk about this
<snusnu>
i guess i'm talking about more than what mbj talked about so far
<snusnu>
yeah no worries, just say when i should stop :)
<solnic>
snusnu: any thoughts on the shape of rom-session?
<snusnu>
not yet sorry, haven't had time to really read the code
<solnic>
ok
<solnic>
this stuff will be hard, so many scenarios to test
<solnic>
but so far I'm happy with how it's turning out
<solnic>
esp that the api is the same as in rom-relation which was my goal
<solnic>
it's basically another layer wrapping the other one (rom-relation)
<snusnu>
yeah, i always wanted to have the session quack like a relation
<solnic>
which fits nicely with the whole stack concept
<snusnu>
totally
<solnic>
and it does
<solnic>
state tracking and transitions are tricky, I'll be specing the hell out of it tomorrow
<snusnu>
it will allow you to work with sessions almost transparently
<solnic>
it does, see integration spec :0
<snusnu>
i'm glad we arrived there, i remember having a hard time convincing mbj back then
<snusnu>
that session should just be another relation wrapper
<solnic>
snusnu: yeah I always knew something was terribly missing in his session
<solnic>
he thought it could just rely on some interface exposed by mapper/relation
<solnic>
but it wasn't the case
<solnic>
loading stuff from IM is probably the simplest thing here :)
<solnic>
so yeah, wrapping relation was the only good option
<snusnu>
yeah, it works for his handwritten mappers, but those (iirc) aren't backed by axiom relations that much
<solnic>
snusnu: yeah + there were some nosql-ish-only things
<solnic>
for instance his IM was flat
<snusnu>
yeah
<solnic>
assuming all keys are unique :)
<solnic>
which is kinda problematic :D
<snusnu>
it is, altho it would be nice most of the times :p
<solnic>
well, a can come up with at least 100 things that would be nice if they were different from reality ;)
<solnic>
another thing was mapping model constants to mappers
<solnic>
it wouldn't work at all in plenty of cases
<snusnu>
but really, i'm glad that session will now expose relation api .. it will allow us to implement db facing code by simply talking to relations, how awesome is that
<solnic>
I just added Session::Relation#new which builds an object and tracks it
<snusnu>
then yeah, it's awesome :)
<solnic>
so it'd be user = session[:users].new(:id => 3, :name => 'Piotr'); session[:users].save(user)
<solnic>
snusnu: oh btw notice I stopped using model constants
<solnic>
using relation names is better
<snusnu>
i always thought that a session where objects need to register themselves explicitly aren#t that user friendly .. the collections (in our case relations) should know (based on their crud calls) when tuples enter/leave a relation
<snusnu>
solnic: yeah, +1 for relation names
<solnic>
yeah man me too
<solnic>
as I said plenty of times, I'm certain we can build a DM which is EASY to use
<snusnu>
thx to ruby
<solnic>
I was just going to add that :)
<snusnu>
hehe
<solnic>
I want to finish this new incarnation of rom-session
<solnic>
merge it in after getting feedback from you
<solnic>
and then start on UoW
<solnic>
I'm thinking about having state objects exposing prepare/finalize hooks
<solnic>
this would be all we need for stuff like setting a PK returned in a tuple and registering persisted object in IM
<solnic>
or setting FKs on a child object
<solnic>
etc
<snusnu>
i think we should "use" the fact that we don't have relationships yet, and design it in such a way that the actual command sort algo is completely injectable
<solnic>
it will be
<snusnu>
and it must be, because it won't be implemented for a while :p
<solnic>
currently the session builds "a changelog"
<solnic>
which is basically an array of state objects