<solnic>
mbj: /home/vagrant/.gem/ruby/1.9.3/gems/mutant-0.3.0.beta16/lib/mutant/reporter/cli/printer.rb:101:in `sprintf': malformed format string - %h (ArgumentError)
<solnic>
mbj: morning ;)
<Gibheer>
evening
<mbj>
solnic: morning
<mbj>
solnic: stacktrace?
solnic has quit [Quit: Leaving...]
mbj has quit [Remote host closed the connection]
mbj has joined #rom-rb
mb14 has joined #rom-rb
mbj has quit [Quit: Lost terminal]
mb14 has quit [Client Quit]
mb14 has joined #rom-rb
<mb14>
hello
<mb14>
I was wondering, what is the current status of this project ?
<mb14>
Is it ready to be use or is still in development ?
<mb14>
nobody?
<mongrelion>
mb14: it's under heavy development and they encourage to wait
machuga|away is now known as machuga
_whitelogger__ has joined #rom-rb
<mb14>
ok, I"ll wait then, Thanks
mb14 has quit [Quit: Page closed]
mbj has joined #rom-rb
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
zekefast has quit [Quit: Leaving.]
snusnu has quit [Ping timeout: 246 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
zekefast has joined #rom-rb
solnic has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
postmodern has quit [Quit: Leaving]
snusnu has quit [Quit: Leaving.]
solnic has quit [Quit: Leaving...]
snusnu has joined #rom-rb
solnic has joined #rom-rb
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
<snusnu>
yo mbj
<mbj>
snusnu: jo
<snusnu>
mbj: got a minute to talk substation?
<snusnu>
mbj: i'm thinking about a refactoring that makes it easy to do the kind of merge/split scenarios you were talking about
<mbj>
snusnu: shoot!
<snusnu>
mbj: basically, i want to support registering a new kind of object, called a "Selector" with every processor .. it'd respond to #call, receive either request or response, and would return a "projection" of request or response … i.e., it'd return something like request.data
<snusnu>
mbj: so it allows you to "dig into" the current input, and select only the value that the processor is concerned with
<snusnu>
mbj: that'd nuke the current Evaluator::Data class (you didn't like the name of that)
<snusnu>
mbj: and leave us with just Evaluator::{Request, Pivot}
<snusnu>
mbj: Evaluator::Request::Data would be just Evaluator::Request plus some DataSelector
<snusnu>
mbj: where DataSelector does def call(request); request.data; end
<snusnu>
mbj: the typical input i receive contains two things: session and input_data
<snusnu>
mbj: the selector concept allows me to project away what i don't need, and only pass, say, input_data to ducktrap or vanguard
<snusnu>
mbj: so that'd be "split"
<snusnu>
mbj: for merge, i will add an incoming transformer (currently there's only an outgoing one)
<snusnu>
mbj: hmm, it all sounds a bit confusing, right? i hope you get the gist of it
<snusnu>
mbj: the Transformer::Incoming you see here isn't yet present in substation
<mbj>
snusnu: Nice deserializer, will "steal" it :D
<snusnu>
hehe
<snusnu>
mbj: so after #deserializer i have Input#{session, data} .. when i need to sanitize and evaluate that, i only want to pass on Input#data to ducktrap/vanguard .. so that's when that selector concept kicks in
<snusnu>
mbj: s/evaluate/validate
<mbj>
snusnu: I'll name it dto
<mbj>
data is to arbitrary
<snusnu>
mbj: one other thing i currently do, is adding an :accept processor right before invoking the pivot
<dkubb>
mbj: I am working with rabl on a project, and I was thinking that it would be nice if the template that is used to generate the JSON could also be used to define a parser for that same JSON
<dkubb>
mbj: I thought I'd mention it because I saw your transformer in the log history
zekefast has quit [Client Quit]
<dkubb>
mbj: rabl's not quite the ideal format since it does not allow you to specify any constraints, it's more structual. a "proper" implementation of this idea would be a way to define the structure and constraints
<mbj>
dkubb: my transformer? Wich one? ducktrap?
snusnu has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu1 has quit [Client Quit]
snusnu has quit [Ping timeout: 246 seconds]
<dkubb>
mbj: the example you just pasted for snusnu
<dkubb>
yeah, I was thinking that a templating system like rabl could be written using virtus. it could then be used to generate output as well as make a parser that can reverse it
<dkubb>
for JSON apis anyway
<mbj>
dkubb: Ducktrap is sort of such a thing from your description
<mbj>
And it has inversible properties.
<mbj>
If you only use nodes that does not loose information you get an inverse transformer for free.
<mbj>
you define a transformation AND constrains
<mbj>
dkubb: Why not use ducktrap?
<mbj>
It allos you to define a structure to map to a dto
<mbj>
And you can describe that structure very detailed.
<mbj>
Granted the last ( or first, depends on your POV ) is using a json parser/unparser
<mbj>
But at this stage you have a prefiltered/structure-sanitized object tree of hash/array/string/float
<mbj>
*last stage
<dkubb>
I'll have to check it out. tbh I haven't really known what it does
<dkubb>
next time I have to do a JSON api where the request and response use the same body, I'll look at something like this instead of rabl
<dkubb>
I really like rabl, but if I can get something that goes in both directions it can cut down some of the boilerplate code I had to write
<mbj>
Just looking into rabl
<mbj>
It is somehow like ducktrap
<mbj>
But it seems to be only *one* side, (generating)
<mbj>
ducktrap does both
<mbj>
For that reason I call it "data transformation algebra"
<mbj>
You'll love ducktrap :D
<mbj>
The DSL is still the most boring point of ducktrap. The OO-Nodes are really nice.
<mbj>
I could translate all their examples from the README to ducktrap DSL
<dkubb>
mbj: I think having some examples would be nice. I think I've scanned the README for examples before, but I was too lazy to actually read and see you pointed people to the specs
<mbj>
dkubb: I'll add examples, but I'm very lazy with polishing readmes.
<dkubb>
heh
<mbj>
snusnu: You are my README hero! Can I convince you to PR some of your ducktraps into the ducktrap README?
<dkubb>
hehe
<mbj>
s/PR/push/
<dkubb>
I'll try to pitch in more on the READMEs
<dkubb>
I haven't gone through the process of using ducktrap, but I have with some of the other gems
<mbj>
dkubb: Just read the substation README, snusnu is our doc hereo.
zekefast has joined #rom-rb
postmodern has joined #rom-rb
<elskwid>
Hi everyone!
<elskwid>
You guys are machines. I just needed to say that.
<elskwid>
:)
<mbj>
elskwid: hi
<dkubb>
elskwid: thanks ;)
<dkubb>
mbj: would it be too opinionated if there was a mutation like object.send(*args) -> object.public_send(*args)
<mbj>
dkubb: No
dkubb|away has joined #rom-rb
<dkubb|away>
mbj: I'll log an issue to add this in the future
dkubb has quit [Ping timeout: 245 seconds]
dkubb|away is now known as dkubb
<dkubb>
mbj: aside from the normal mutations, like flipping true -> false I can see there being semantic mutations like send -> public_send being used
<dkubb>
there's probably a large number of those
<mbj>
dkubb: I'd love to add such mutations
<mbj>
dkubb: But maybe we should wait still we got all "structural" mutations.
<snusnu>
mbj: hey, btw, don't use that deserialize example, it's srsly broken :D .. i got sidetracked this afternoon, will work on that thing now
<mbj>
snusnu: I dont use it :D
<snusnu>
mbj: also, i will try to polish the readmes, but don't expect anything very soon, i'll get around to it, if nobody else beats me to it
<snusnu>
mbj: s/use/steal
<snusnu>
lol
<dkubb>
mbj: I think if there are structural mutations in the queue they should always take precedence, but if we ever run low or only have a short time, adding semantic mutations are fine
<dkubb>
mbj: do you think most of those will have valid mutations?
<mbj>
dkubb: yes
<mbj>
dkubb: I think *all*!
<mbj>
Think about them this way, all nodes carry ruby semantics and all semantics are mutatable :D
<mbj>
dkubb: In case they wont have valid mutations, they wount be part of ruby.
<mbj>
for example zsuper => super()
<dkubb>
interesting
<dkubb>
mbj: I wonder if there should be a strict mode where mutant blows up when it encounters a generic node
<dkubb>
mbj: we could run it against our own code and then fill in the blanks when we find them, allowing the nodes that occur in our code to drive where we spend our time
<mbj>
dkubb: Easy to add via some ENV variable snooping.
<mbj>
raise "add a mutator for #{node.type}" if ENV['WANNA_IMPROVE_MUTANT']
therabidbanana has joined #rom-rb
<dkubb>
hehe
<mbj>
dkubb: But granted, we use 60% of these nodes :D
knowtheo1y has joined #rom-rb
knowtheo1y has quit [Client Quit]
knowtheory has quit [Ping timeout: 260 seconds]
<dkubb>
mbj: each one of these problems exposes lots of new mutations.. I need to carve out a bit more time to help add one
<dkubb>
mbj: if, as a group, we could add a couple each week we'd probably expose lots of uncovered code and it would only take a month or two to add all these
<mbj>
dkubb: Faster! Adding mutators is very easy if you use the present infrastructure.
<mbj>
I stared with a "just as in the books visitor" but realized it is still far to complex.
<mbj>
My "emitter" design, that registers for node types is far more elegant, IMHO.
<dkubb>
mbj: I was about to read that
<mbj>
dkubb: I was about to tweet about, but could not make a 160char message :D
knowtheory has joined #rom-rb
<mbj>
snusnu: any news on split/join chains?
<snusnu>
mbj: working on it, slowly getting there, too many interruptions till now, but night has finally started it seems :p
<snusnu>
mbj: fwiw, my goal is to have an integration spec that starts with accepting an arbitrary hash (i.e. a "mocked" rack env), selects 'session' and 'body' from that, assumes that both have json encoded data .. and spits out the appropriate response
<snusnu>
mbj: that should cover all typical split/join cases
<mbj>
snusnu: ack
<mbj>
would help me a lot
<mbj>
I'm about to workaround this one tomorrow.
<mbj>
snusnu: Maybe an outer chain fetching session could call an innser chain where session is part of the env?
<snusnu>
maybe i'll get it to work by then .. i assume that i will be somewhat productive in the next 3 hours or so ;)
<snusnu>
mbj: i guess i don't get what you mean by that
<mbj>
snusnu: Creating a new env for calling the inner chain
<mbj>
snusnu: So the inner chain (that does not deal with session explicitly)
<mbj>
snusnu: can access the session via env.session
<snusnu>
mbj: btw, i'm pretty sure my concept of selectors will do the trick … hmm, dunno if i get you right/wrong, but my plan is to read the session from rack env initially, then provide a session abstraction carried through the chain within Actor#session .. and some output handler will write that back to the rack session (if necessary, like, logout or whatever)
<snusnu>
mbj: there's no such concept (in my world) like an "inner" chain
<snusnu>
mbj: it's just a chain, nothing inner, nothing outer
<snusnu>
mbj: the object i carry around in Request#input will initially be Concord.new(:session, :data) which then gets turned into Concord.new(:actor, :data) before it hits my action .. an actor instance contains my domain specific actor instance (i.e. it wraps an Employment instance in my case) .. and it contains a "proxy" to the session, like described above
<cored>
I think that guy beat you on the contribution numbers
<cored>
:-O
<snusnu>
mbj: to be clear, i don't actually mean a proxy .. but something that initially got wrapped from the session, and is then used to write back a new one if need be
elskwid has quit [*.net *.split]
dkubb has quit [*.net *.split]
ChanServ has quit [*.net *.split]
snusnu has quit [*.net *.split]
shingara has quit [*.net *.split]
mbj has quit [*.net *.split]
kalleth has quit [*.net *.split]
stormwin1 has quit [*.net *.split]
xargoon has quit [*.net *.split]
machuga|away has quit [*.net *.split]
xybre has quit [*.net *.split]
kpwz has quit [*.net *.split]
dbussink has quit [*.net *.split]
Gibheer has quit [*.net *.split]
knowtheory has quit [*.net *.split]
postmodern has quit [*.net *.split]
zekefast has quit [*.net *.split]
cored has quit [*.net *.split]
therabidbanana has quit [*.net *.split]
pdswan has quit [*.net *.split]
indrek has quit [*.net *.split]
therabidbanana has joined #rom-rb
Gibheer has joined #rom-rb
dkubb has joined #rom-rb
kpwz has joined #rom-rb
snusnu has joined #rom-rb
ChanServ has joined #rom-rb
xargoon has joined #rom-rb
kalleth has joined #rom-rb
pdswan has joined #rom-rb
stormwin1 has joined #rom-rb
zekefast has joined #rom-rb
mbj has joined #rom-rb
machuga|away has joined #rom-rb
shingara has joined #rom-rb
dbussink has joined #rom-rb
indrek has joined #rom-rb
knowtheory has joined #rom-rb
postmodern has joined #rom-rb
xybre has joined #rom-rb
cored has joined #rom-rb
elskwid has joined #rom-rb
<snusnu>
hehe
<dkubb>
mbj: I could create issues for each of those generic nodes, and then start to make todo notes about which mutations can be done
<mbj>
dkubb: pls do so!
<mbj>
dkubb: But writing that issue might be harder thant writing the mutator, word of warning.
<dkubb>
hehe
<dkubb>
mbj: yeah, I just need something to track it for myself. a place where we can also add new mutations without needing to write code
<mbj>
dkubb: So just the issues with "Add dedicated mutator for $node" is enough
<mbj>
OMG, 01:00 localtime
<mbj>
And I have to take a train at 04:00
<mbj>
should I sleep?
<mbj>
Or "try to sleep"
<cored>
dkubb: sometihng that I don't get Attribute.infer_type will return an Axiom::Types object
<cored>
but I can't see the .coerce method on any of those types