jfredett-w has quit [Read error: Connection reset by peer]
postmodern has quit [Quit: Leaving]
dkubb|away has quit [Ping timeout: 245 seconds]
dkubb has joined #rom-rb
snusnu has quit [Ping timeout: 272 seconds]
snusnu has joined #rom-rb
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
skade has quit [Client Quit]
<solnic>
snusnu: hey
<solnic>
snusnu: just read your chat with dkubb, something I want to mention is that I'd love if ROM was also as easy to use as AR if you want...something to keep in mind :)
<mbj>
dkubb, snusnu, solnic: Can we find a better name then develery, I always type it wrong.
<mbj>
Also this time.
<mbj>
devbox?
<mbj>
devutil, devframe, dev....
<dkubb>
cameron ;) j/k
<mbj>
:D
<mbj>
dkubb: I'd love to finish a split gem release today.
<dkubb>
split gem?
<mbj>
dkubb: master gem with code, -deps gem with Gemfile.devtools
<dkubb>
ahh ok
<mbj>
dkubb: So the devtools code is still semversioned
<mbj>
Where the -deps gem can be more simple.
<mbj>
But I need a better name.
<dkubb>
gem naming is hard for me
<mbj>
heh
<mbj>
The new name we agreed on is not optimal
<mbj>
I mistype it far to often.
<snusnu>
:p
<mbj>
Sure we can change it later.
<snusnu>
hey guys
<mbj>
snusnu: hey
<dkubb>
hey guys, I totall forgot about MemoServ. I left snusnu and mbj a message there
<dkubb>
I may use it more since we don't have a memo bot
<snusnu>
i once suggested mddic (pronounced medic, translation: metric driven development in custody) … and mddric (pronounced metric, translation: metric driven development - ruby in custody)
<snusnu>
dkubb: just saw that, fine with me!
<snusnu>
dkubb: also thx for the axiom commit ;)
<mbj>
"MemoServ" ?
<mbj>
That bot we had in #datamapper
<dkubb>
yeah, type in: /msg MemoServ READ NEW
<dkubb>
medic would be an alright name
<dkubb>
alright, maybe not optimal
<snusnu>
yeah
<mbj>
I like medic
<dkubb>
or paramedic
jmorton has joined #rom-rb
<dkubb>
triage
<mbj>
dkubb: I saw your rubysl/mutant tweet
<mbj>
why not
<mbj>
triage is also a nice idea
<mbj>
all I heard is better then develry develery....
<dkubb>
"pay immediate attention to particular priorities"
<dkubb>
also "pick and cull" .. "the action of assorting according to quality"
<mbj>
hehe
<mbj>
I'm okay with triage.
<mbj>
snusnu, solnic: ?
<dkubb>
it's short too. I have no super *strong* opinion on it
<dkubb>
"the process of deciding which patients should be treated first based on how sick or seriously injured they are"
<dkubb>
it seems to fit
<dkubb>
I would love to see it evolve into something that, instead of just shelling out to different tools, it runs the tools and parses the output, and then displays a priority list of stuff that needs to be fixed
<dkubb>
with failure states for certain things based on some configuration
<mbj>
solnic: I'm playing around with mutant and my rename branch
<mbj>
solnic: Close to release.
<solnic>
sweet
<mbj>
solnic: Once that basic infrastructure problem is solved I'll do some sql stuff.
<mbj>
solnic: And we have to port mbj/axiom-sexp to mbj/axiom-ast before ;)
<mbj>
solnic: So we do a whitequark/ast based translation from axiom relations to the sql ast.
<mbj>
solnic: This is not as performant, but saves us some time.
<solnic>
mbj: oh didn't know that was the plan
<mbj>
solnic: Its faster.
<mbj>
solnic: I did so much adpater / AST transformation work I can be very sure it saves me lots of time.
<mbj>
solnic: Sure we translate from Axiom::Relation => ast (axiom) => ast (sql) => string (sql)
<solnic>
sure, I totally trust you with this stuff and I've got zero opinion / experience so can't even comment on that
<mbj>
solnic: :D
<mbj>
solnic: And thx.
<solnic>
I guess that would be a very initial step towards porting axiom to ast (the gem) eventually
<mbj>
solnic: Dkubb plans to refactor axiom a bit to use whitequark/ast internally. What I do is just a first step.
<mbj>
solnic: Yeah, exactly.
<solnic>
heh
<solnic>
right
<solnic>
cool, cool, that's really nice to know
<mbj>
solnic: I'm totally exited
<solnic>
me too
<mbj>
solnic: It will be "easy"
<mbj>
solnic: Also I plan to support nest/unest natively in axiom-arango-adapter.
<solnic>
btw I'm releasing virtus 1.0.0 this week so you won't hear me bitching about anything for at least a month or so after this week ;)
<mbj>
solnic: Still have to talk to Triagens (company behind arango, maybe they'll fund me).
<mbj>
solnic: Heh, somehow I'll miss you ;)
<mbj>
solnic: s/you/that-bitching/
<mbj>
solnic: I'll miss your person also (to make this clear)
<solnic>
mbj: you can't know that but thanks ;)
<mbj>
solnic: Dunno how to say what I mean exactly, english limitation.
<mbj>
solnic: Just wana make sure its not only the "bitching" ;)
<solnic>
mbj: I think I got it no worries :)
mkristian has quit [Ping timeout: 240 seconds]
<dkubb>
mbj: it shouldn't be too hard to make Axiom::Relation has-a ast object, or even be an is-a ast. normally I wouldn't like is-a, but an axiom relation *is* basically an ast, so it's not really a conflict
<dkubb>
I don't mind inheritance if the subclass instance adhere's to LSP, which would be the case here
<mbj>
dkubb: But Axiom::Relation carries behavior, maybe we can use a "pure data" structure internally that is a whitequark/ast
<mbj>
dkubb: Not 100% sure, I'll experiment ;)
<dkubb>
it's ok for a subclass to *add* behavior, you just can't change it
<dkubb>
or rather, function/methods inputs need to be the same or "weaker", and outputs need to be the same or "stronger" .. if that makes sense
<dkubb>
I'm speaking in terms of contracts
<dkubb>
if you adhere to this, then you can substitute any subclass instance in place of a parent class
<dkubb>
most ruby code is generally pretty bad at this, especially stdlib/core.. and really I guess almost all mainstream code
<mbj>
Yeah
<dkubb>
I kind of would like to figure out a pattern that allows me to reuse specs for a parent class for all descendants
<dkubb>
rspec makes it difficult
<dkubb>
I wish I could just inherit an existing spec description/context
<dkubb>
and not have to specify any special syntax for a shared spec
<dkubb>
also, I've asked about this a few places and constructors are generally not required to adhere to lsp
<dkubb>
which fits in with what I thought, but I wanted external validation
<dkubb>
anyway, I guess I'm saying that the addition of #each doesn't break LSP.. but if it's easier to has-a ast object then I'm cool with it
<dkubb>
either way, we should have it so you do #to_ast on the relation to get the ast object
<dkubb>
if we decide to make it has-a or is-a then it won't change anything
<dkubb>
it'll even work nicely for axiom-ast too, where we generate the ast on-the-fly and then memoize it
<mbj>
dkubb: I think I'll come upt with an "mbj-spec" thing
<mbj>
dkubb: I did SO much mutant-covered code, also lots of dsl stuff and "algebra like" work in ruby.
<mbj>
So adding a spec framework to my "stack" shoulnt be too hard.
<mbj>
Also we can reuse lots of infrastructure, filtering => axiom (as an example).
<mbj>
My spec framework will be "rspec-alike" but focus on literal deduplication.
<mbj>
s/literal/terminal/
<jfredett>
mbj: clarify what you mean by that -- because I think we may have the same idea...
<jfredett>
right, but what do you mean be 'deduplication of lterminals' in the sense of rspec? Reducing the number of 'it'/'specify' -- etc's?
<mbj>
jfredett: yeah, and also that whole rspec boilerplate.
<mbj>
jfredett: When testing child classes it should be easy to include invariants from parent classes.
<mbj>
jfredett: Invariant reusage should be most easy.
<jfredett>
yah, I think we're thinking in the same direction
<jfredett>
I've been thinking about ways to build a testing system that was extensible, and better tooled (in the sense of allowing more interactive use from, eg, an interpreter shell)
<jfredett>
in particular something which would let you muck around with tests as first-class objects, which know, for instance, what parts of the code they touch, or how resistant they are to mutation
<mbj>
jfredett: yeah a mutation to killing invariant mapping
<jfredett>
naturally, these ideas poked up about the time I started working on katuv
<jfredett>
again
<jfredett>
:)
jfredett has quit [Remote host closed the connection]
jfredett-w has joined #rom-rb
<dkubb>
I would love to see a spec system that would allow the examples to be executed in parallel
<dkubb>
also one where the setup is done once and shared between examples. this would work nicely for immutable objects
<mbj>
dkubb: +1
<mbj>
dkubb: It would parallelize per default.
<dkubb>
yeah I think that's a better default
<dkubb>
I think it could expose all sorts of interesting bugs when run under something without a GIL
<dkubb>
I would also randomize by default too
<dkubb>
I would possibly consider using something like celluloid to distribute the testing jobs
<dkubb>
that would be fun to work on
<dkubb>
there's that joke in the ruby community where new test frameworks pop up every week, but I still think it's a wide open area
<dkubb>
just like ORM dev
<dkubb>
no one has cracked it yet
<dkubb>
I feel like everything, with the exception of minitest, tries to do too much
<mbj>
heh
<mbj>
Also reporting should be handled like in mutant
<jfredett-w>
dkubb: That would be neat, though you'd need to have a system for managing external resources.
<mbj>
pluggable and non invasive.
<jfredett-w>
like -- there's no reason you *can't* run things in parallel, unless you have a shared external resource (DB, queue, w/e)
<jfredett-w>
maybe an 'exclusive' mode or something, 'These tests must run on their own'
<jfredett-w>
a la celluloid.
<jfredett-w>
actually, it'd be really neat (though probably not used) to have DCell involved -- remote test running machines.
<jfredett-w>
good for netbooks or w/e
<mbj>
jfredett-w: Distribution adds another problem domain. Lets start with a good implementation of local execution.
<mbj>
jfredett-w: If we get primitives *right* adding distribution is not that complex.
<jfredett-w>
*nod*
<mbj>
dkubb: All these frameworks are "ad-hoc". They dont provide a good domain model for testing.
<jfredett-w>
the idea I've been kicking around in my head is just making the runner pluggable, then using Celluloid's pooling facility to create a 'pooled runner'
<jfredett-w>
mbj: That, that's the word I wanted -- I want a good domain model that I have access to programmatically.
<mbj>
dkubb: I'd love to see instances of Framework::Invariant, Framework::Test, with interfaces like Framework::Test#run(invariant).success?
<mbj>
jfredett-w: Yeah because you coud consume that domain model for intermixing with tools like mutant.
<mbj>
*could
<jfredett-w>
or write your own frontend to that domain model
<mbj>
Yes
<jfredett-w>
A la Cucumber/Fitnesse/Rspec/whatever
<jfredett-w>
sort of a testing kernel.
<mbj>
That domain model, should *just* be freestanding and produce a read only / immutable result tree.
<mbj>
jfredett-w: You might be interested how I did this in mutant.
<jfredett-w>
mbj: I've been trolling around in mutant's source off and on for the last few weeks
<mbj>
jfredett-w: Feel free to raise any comment / question
<jfredett-w>
it's an interesting experience, because on the one hand it's very foreign (because I didn't write it), but very familiar (because I tend to write things in a similar style), so mostly I'm just trying to overcome the uncanny valley effect. :)
<mbj>
:D
<jfredett-w>
mbj: I don't know if that's a compliment, but my sense of pride says it probably is, and my imposter syndrome says it's not. :)
<mbj>
jfredett-w: If you wanna get familiar what the mutators do: ruby-parse -e 'some_ruby_here' gives you a lot
<mbj>
this is the datastructure mutant mutates.
<mbj>
ruby-parse is part of whitequarks parser gem.
<jfredett-w>
yah
<mbj>
Its very simple, but I heavily deduplicated mutation emitters.
<mbj>
So it "looks" unfamiliar ;)
<mbj>
AFAIK the mutation emitters are most easy to understand, if you got the AST by whitequark/parser.
<mbj>
jfredett-w, dkubb, solnic: Going to bed, cu tomorrow.
mbj has quit [Quit: leaving]
<dkubb>
yeah, one of my motivations for mentioning celluloid is the distrubutability
<dkubb>
and yeah, I was thinking about an exclusive mode.. where you'd specify the tests need to be run serially
<dkubb>
I suspect if you knew the dependencies between the examples you could automatically serialize/parallelize
<dkubb>
by default the examples would only be dependent on the setup and teardown, and not each other
<dkubb>
in which case they could be run all at the same time
<jfredett-w>
dkubb: I hadn't even considered having the ability to express dependency between tests...
<dkubb>
when you say "these need to be run serially" that's effectively specifying a dependency
<jfredett-w>
One problem I've run into _constantly_ is in integration tests, trying to keep assertions separated (so that I get a 1:1 mapping between assertions and failing tests) but also keep run-time low (ie, don't run the full stack each time, just make the next assertion) and keep the dependency between subsequent tests extant.
<dkubb>
ahh yeah. In dm-core's specs I abused before(:all) to do my setup once per context. I just had to be careful I wasn't mutating the object while asserting something, but it worked alright
<jfredett-w>
being able to have a block of tests that are essentially linearly dependent -- ie, 'do this, if you fail, don't run the rest, put them in some other state'
<dkubb>
ahh yeah
<dkubb>
that's a good point
<jfredett-w>
so instead of pass/fail/pend, it's pass/fail/pend/dependency-failed
<jfredett-w>
so you'd end up with an output like `....F----` ; which gives you some sense of the scope-of-failure, better, perhaps, then what you get now, which is either `....F` or `....FFFFF`
<dkubb>
I sometimes like a fast fail too
<dkubb>
a nice dependency system would allow you to assign weighting too, so you could have more recent tests run first
<jfredett-w>
yah, the dependency-failed state gives you the best of both worlds, I think -- always fail fast, but also show where-abouts you started failing.
<dkubb>
push those older, probably stable tests, to the end
<jfredett-w>
it also let's you not have to rebuild the state if you let the dependency act as a tree
<dkubb>
I typically use tsorting to resolve dependencies, and use a weighting as a "tiebreaker"
<jfredett-w>
yah
<dkubb>
because when you have a bunch of items with low levels of dependency everything kind of ends up at the same weight
<dkubb>
or rather most things
<jfredett-w>
yah
<dkubb>
weighting could be randomized too, which is probably what I would want for the default
<dkubb>
I think what we're describing could be built relatively simply. it sounds complex, but nothing is particularly difficult, it just hasn't been assembled in the right configuration yet
<jfredett-w>
yah, I think mbj has the right idea -- build an internal domain model that expresses the ideas w/ perhaps an entirely programmatic API, then layer on a frontend/formatters/whatever