<mbj>
snusnu: And release in case of mutation coverage :D
<snusnu>
mbj: heh, that's what i wanted to ask, those new kill expressions, they're still a bit off, right?
<snusnu>
mbj: btw, can we have both ducktrap and vanguard result objects support: #success? and #output please?
<snusnu>
mbj: i want to unify the Sanitizer and Validator handlers into one Evaluate handler
<mbj>
snusnu: Yeah, will do that changes this day.
<mbj>
snusnu: Feel free to PR an alias, I'll clean it up.
<snusnu>
mbj: which would basically support any object that responds to #call and returns an object that supports #success? and #output
<snusnu>
mbj: ok will do
<mbj>
snusnu: And yeah, kill expressions are still *planned* but not implemented
<snusnu>
mbj: hm thought so, ok then i'll stick to current mutants rules
<snusnu>
mbj: also, i'm tempted to just add that Evaluator, Wrapper and Pivot handler objects to substation proper (no substation-stack)
<snusnu>
mbj: they don't depend on anything specific, only an interface
<mbj>
snusnu: do so
<snusnu>
mbj: next thing i need to do is make it so that incoming handlers can have another chain, that gets invoked of failure
<snusnu>
s/of/in case of/
<mbj>
snusnu: I'd only add a backup chain.
<snusnu>
mbj: yeah something like that
<mbj>
snusnu: That presents the 500 :D
<snusnu>
mbj: hm yeah, i'd also want to have something that can return a useful response to the client in case any of the typical incoming handlers fail (sanitization, validation, etc)
<snusnu>
mbj: from substation's pov it will just be another chain i guess, nothing app specific obviously
<snusnu>
mbj: i'm not totally sure yet, but i definitely don't want to stick anything specific at the end, that interrogates the response error type and acts accordingly
<snusnu>
mbj: and i definitely don't want to let it bubble up into the http layer either
<snusnu>
mbj: i'd imagine to have a piece of code that wraps a ducktrap error into something usable for the client, and same for vanguard errors etc .. i'd just register those handlers to further alter the response, if any of the specific failure cases occured
<mbj>
snusnu: Got your point!
<mbj>
snusnu: I appreciate your work in this area, something I can sonsume, withtout thinking to hard!
<snusnu>
mbj: heh cool
<snusnu>
mbj: i like how it still absolutely doesn't feel like substation gets in my way, it just guides along nicely, enforcing/supporting an app design i like
<snusnu>
mbj: and that new env object + dsl is less than 100loc
<snusnu>
mbj: so it's worth it imo
zekefast has quit [Quit: Leaving.]
solnic has quit [Read error: Connection reset by peer]
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
solnic has joined #rom-rb
<mbj>
solnic: Congraz on that bountysource thing!
<mbj>
solnic: You think it would also work for mutant?
<mbj>
snusnu: Also I'd love your voice, will a bountysource backed mutant fundraiser work?
zekefast has joined #rom-rb
<mbj>
dkubb: Some time to discuss axiom writes?
<dkubb>
mbj: a bit. I'm just about to get ready for a Father's day brunch
<dkubb>
mbj: what's up?
<dkubb>
mbj: by axiom writes do you mean insert/update/delete, or something else like writing the code in axiom?
<mbj>
dkubb: I'm talking about write propagation in a specific scenario
<mbj>
dkubb: If an adapter pushes down some, but not all nodes
<mbj>
dkubb: And the not pushed down node receives an #insert, or whatever.
<mbj>
dkubb: We'll get an in-memory insert and nobody realized this.
<mbj>
dkubb: The in-memory relations return a new Axiom::SomeNamespace::Insert node when you call #insert(tuples) on them.
<dkubb>
mbj: hmm, that's interesting, I hadn't thought about that use case. in the case of, say, insert, you should be able to materialize all the nodes in-memory until you get to the #insert on the base relation
<mbj>
dkubb: I thought about an alternative approach. Just dont provide an #insert, #update, #delete node. Just transform the tuple and push it down. If there isnt an adapter receiving the operation: raise.
<mbj>
dkubb: If we provide a real mutable in-memory adpater!
<dkubb>
mbj: I think that's sort of what it does, isn't it?
<dkubb>
s/isn't/doesn't/
<mbj>
dkubb: Users of in-memory functionallity without backing by an adapter could use #union, #intersect that does not imply a write.
<mbj>
dkubb: That is the case, just down provide implementations for "actions" that should have side effects inside the relations.
<mbj>
dkubb: TBH I have to check it if this issue really exists.
<mbj>
dkubb: Just remembered there are scenarios where a "Delete/Insert" node gets returned.
<dkubb>
mbj: yeah, I think my intention was something along those lines. of course once the adapter is hooked up it could change, but that was my original thought on how it should work
<dkubb>
mbj: so you tell the relation to delete a set of tuples, and since it's an operation it needs to almost apply a reverse of itself on the tuples, and then the next operation under it does the same thing, until it gets down to the base relation
<dkubb>
mbj: I had assumed all of those operations would be performed in-memory
<mbj>
dkubb: Yeah, but I think you assumed it to "delete" the tuples in a "functional style", so instead of pusing the mutation down, it returns a node that filters the tuples on #each
<mbj>
dkubb: But this is what I remembered, let me check before continuing this. You opened my eyes for a possible misreading of axiom code on my side.
<dkubb>
mbj: I was going to make it so you call #materialize on the insert relation to get the list of tuples to insert
<dkubb>
inside the adapter I mean
<dkubb>
it should evaluate to a set of tuples that can be applied to the base relation
<mbj>
dkubb: Why add #materialize of #each or #to_a return the same stuff?
<dkubb>
mbj: materialize returns a relation
<mbj>
dkubb: I plan to add write support to aql / arango-adapter soon.
<dkubb>
mbj: which can have further relation ops applied to it
<solnic>
morning
<mbj>
dkubb: Okay, but why I need more ra ops to do the mutation?
<dkubb>
mbj: actually, I wonder if I should do a spike in axiom-do-adapter that adds insert support using an ugly-ish approach like in dm-cassandra-adapter. we can refactor it to use the sql generator too
<dkubb>
mbj: I suppose you could just call #to_a on it
<mbj>
solnic: I realized axiom-arango-adapter is the only adapter where I could add write support with rom-* soon!
<dkubb>
mbj: it depends on whether you're cool with losing the header, keys and other metadata .. I'd do whatever is simplest
<mbj>
dkubb: TBH, it is easier to add a real cql ast, and copy axiom-arango-adapter to axiom-cassandra-adapter, and write a generic dm-axiom-adapter
<solnic>
yeah I want to tackle in-memory adapter tomorrow
<mbj>
solnic: I'd love to spend time on an in-memory adaper also.
<dkubb>
mbj: I think I could spike out writes for axiom-do-adapter if we wanted a reference
<solnic>
but I'd prefer to start simple w/o such weird cases like mbj mentioned
<mbj>
haha, know we have 3 options!
<mbj>
I'd love to rewrite my aql gem on top of whitequark/ast style ASTs. Need to ping triagens if they'd sponsor write support.
<dkubb>
mbj: btw, I'm sure you know this but not all operations are writable.. most are
<dkubb>
mbj: some stuff, like writing to a union, don't really make make a ton of sense.. thankfully in most real-world cases it shouldn't be an issue
<mbj>
dkubb: I see it this way: All "mutation" operations such like #insert, #update, #delete can change the tuples returned of an already exsiting RA tree.
<mbj>
dkubb: So first = tree.to_a; tree.mutating_opreation; second = tree.to_a; first is allowed to be unequal to second
<dkubb>
at some point I also need to refactor axiom to use axiom-types
<mbj>
Yeah, there is lots of stuff to improve in our stack.
<dkubb>
I was thinking this morning about writing something to explain why we prefer small single purpose libs vs monolithic libs. I'm almost certain people will nitpick the libs based soley on the number of gem dependencies
<solnic>
dkubb: yeah I already see that
<dkubb>
I think it comes down to the fact that these monolithic libs are unusable outside of their ecosystem
<mbj>
Yeah, such a document will help with self marketing. I typically say: The ruby stlib is crap, and we rewrote quality libs to depend on.
<dkubb>
things like AS don't help the ruby community. peolpe actively avoid it
<solnic>
I already see people screaming OMG GO TO NODE IF YOU LIKE SMALL LIBS
<solnic>
:D
<solnic>
there are a lot of people in our community that like small libs
<solnic>
I'm not super worried about that
<dkubb>
aside from rails specific libs, AS doesn't really appear in many high quality libs. threrefore it's benefits are not felt by the community.. it's reliance on monkey patching doesn't help either
<solnic>
although it will be an issue, not a huge one though
<solnic>
tru dat
<dkubb>
it also doesn't encourage small releases.. they have to release everything when there's an AS fix
<dkubb>
solnic: mbj: not sure if you guys celebrare it over there, but Happy Father's day! :)
<solnic>
dkubb: haha thanks man, we will have it in 10 days
<solnic>
have fun with kids :)
<solnic>
dkubb: btw I will be working soon on a website promoting small libs
<dkubb>
I will. I'm going to sign off for now, but I'll be back later
<dkubb>
solnic: oh cool
<solnic>
microrb.com <= me has the domain
<dkubb>
k, bbiab
<solnic>
ok ttyl
<mbj>
dkubb, solnic: I did not realized this Fathers day!
<mbj>
so wish you both the best!
<solnic>
mbj: in Poland it's on 26th (I think)
solnic has quit [Quit: Leaving...]
snusnu has quit [Quit: Leaving.]
djsell has joined #rom-rb
djsell has quit [Client Quit]
djsell has joined #rom-rb
<dkubb>
I was thinking last night that some of axiom's in-memory operations could be parallelized
djsell has quit [Quit: Leaving.]
<mbj>
dkubb: yeah
<dkubb>
mbj: some operations like projection, renaming, extension, restriction, etc could be parallelized.
<dkubb>
mbj: summarization would be a bit harder since it does need to see each tuple to get an answer.. however, since I designed relations like a stream and used online algorithms (http://en.wikipedia.org/wiki/Online_algorithm) I think I can use map/reduce to process the tuples in parallel
<dkubb>
anything that requires an ordered relation can't be, since it uses ruby's built in sorting algo
<dkubb>
and limit, offset, etc need to have the entire ordered relation as input before they can slice off what they need
<mbj>
dkubb: I dont think we need this for regular rom operation. But Yeah, it could be very handy for reporting jobs, or even some real time stream filtering!
<travis-ci>
[travis-ci] dkubb/axiom#23 (adamantium-flat - 66cfb5c : Dan Kubb): The build has errored.
<dkubb>
mbj: should mbj/mutant master work? I just tried it with axiom-types and first I got ambiguous option: -r .. when I removed that option from the rake task in devtools I got an error "No mutator to handle: :const" when it tried to mutate Axiom::Types.finalize:/Users/dkubb/Dropbox/Home/Programming/open-source/axiom-types/lib/axiom/types.rb:55
<dkubb>
mbj: I'm guessing it's not ready, but I figured I'd let you know in case you didn't know about those errors
<travis-ci>
[travis-ci] dkubb/axiom#25 (master - e775140 : Dan Kubb): The build was broken.
mbj has quit [Ping timeout: 276 seconds]
snusnu has joined #rom-rb
mbj has joined #rom-rb
<mbj>
!memo dkubb I need to add noop mutators for some nodes that are reachable in the parser based ast.
<mbj>
!memo dkubb Also master is missing reporting of mutations (the diffs). Adding noops is very easy (list them in the handle macro in lib/mutant/mutator/node/noop).
<mbj>
dkubb, I need to add noop mutators for some nodes that are reachable in the parser based ast.
<mbj>
dkubb, Also master is missing reporting of mutations (the diffs). Adding noops is very easy (list them in the handle macro in lib/mutant/mutator/node/noop).
<mbj>
We need a memo bot here :D
zekefast has quit [Quit: Leaving.]
<dkubb>
mbj: yeah, I think it's a cinchy bot. we need to get a vm somewhere and run the bot from it. I think it's possible to run cinchy from a free heroku vm