<mbj>
dkubb: I'm not 100% sure these is a valid mutation that will be uncovered ever.
<dkubb>
mbj: if you had a bare self would it be triggered?
zekefast1 has joined #rom-rb
mbj has quit [Read error: Connection reset by peer]
zekefast has quit [Ping timeout: 264 seconds]
mbj has joined #rom-rb
langitbi1u has quit [Ping timeout: 248 seconds]
<mbj>
dkubb: Merged, see comment.
langitbi1u has joined #rom-rb
<dkubb>
mbj: ahh ok
<dkubb>
I wonder if statement deletion will always catch it
<dkubb>
oh wait, I guess it probably would
<mbj>
but stuff like "self.object_id" => "nil.object_id" is totally valid IMHO.
<mbj>
(valid mutation)
<dkubb>
yeah I suppose it is
<dkubb>
mbj: this is a simple one for zsuper: https://github.com/mbj/mutant/pull/73 .. I thought about combining it in the named_value/access mutation, but I wasn't sure
<dkubb>
(this one actually caused a few new mutations in axiom-types)
<dkubb>
ok, I've got to hit bed, but will be online later
<kapowaz>
that worked pretty well — I just installed IRCCloud's iPhone app yesterday, so I got a push notification of your message :)
<kapowaz>
sup?
<solnic>
kapowaz: can we have a logo for github and website pretty please?
<solnic>
I want to set it up on gravatar
<kapowaz>
absolutely
<solnic>
fantastic!
<kapowaz>
any specific dimensions?
<solnic>
kapowaz: whatever looks good on github?
<kapowaz>
I suppose if we're pretty much certain it's final I can make some resizeable .ai/.psd versions for you too
<kapowaz>
I think for gravatar I just tend to go big and let them resize it
<solnic>
that would be lovely
<mbj>
solnic: +1 for logo!
<solnic>
and yes we are all very happy with it
<kapowaz>
no problem, I shall sort that now
<kapowaz>
cool :)
<solnic>
sweeeeet
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
solnic has joined #rom-rb
<kapowaz>
solnic_: do you want the avatar to include the ROM text or not?
<kapowaz>
my suggestion would be to exclude it for avatars, since it'll have text beside it (and it'll be small anyway)
<kapowaz>
but I can do it either way
<solnic_>
kapowaz: I agree, no text on avatar should be better
<solnic_>
but we want full name for logo on website
<solnic_>
#{logo} Ruby Object Mapper <== there was something like that IIRC
<kapowaz>
yeah
<kapowaz>
you just want something to stick up on the current site for now?
<kapowaz>
I'll size it appropriately for that if that's the case
<solnic_>
yeah I want something :)
<kapowaz>
I did make a start on a basic site design but I got distracted by my own stuff I'm afraid
<kapowaz>
so I didn't get very far
knowtheory has joined #rom-rb
<kapowaz>
HAI TED
<kapowaz>
solnic_: I'm thinking I'll create a github repo for the PSDs etc. and then once I've pushed stuff up I can transfer ownership to the rom-rb account?
<kapowaz>
changed it down to Gotham Medium and added 10px of vertical padding to the header
<kapowaz>
solnic: I've pushed all this stuff to github as a private repo, so if you're ready I'll make it public and transfer ownership. If you can add me as a contributor once that's done, I'll be able to push further changes as needed.
mbj has joined #rom-rb
<snusnu>
yo solnic, this might be a stupid question, but how do i get the gems bundled into the vagrant vm?
<snusnu>
solnic: i never used vagrant before, but accidentally imploded rvm yesterday :p
<solnic>
kapowaz: yeah that's cool, please transfer and I'll add you as contributor
<kapowaz>
I think you have to bundle install within the VM if you're using vagrant
<solnic>
snusnu: you ssh to the vm and run bundle :)
<kapowaz>
that's how I've always done it… I imagine you can automate that with puppet
<solnic>
snusnu: the vm uses synced folders, so your clones should be inside ROM_ROOT (or something)
<solnic>
on your HOST system
<kapowaz>
You don't have admin rights to rom-rb
<solnic>
which is OS X
<solnic>
in your case
<kapowaz>
heh, I don't have permission to transfer to you, solnic
<kapowaz>
I think you'll have to make me a contributor first, or maybe an admin temporarily
<solnic>
kapowaz: lemme add you to rom-rb
<kapowaz>
ok
<solnic>
kapowaz: ok I added you to contributors team with admin rights
<solnic>
kapowaz: ok I managed to set ROM's avatar on github
<solnic>
kapowaz: and twitter
<solnic>
and tweeted about it just now
<kapowaz>
I saw the tweet :)
<kapowaz>
nice one!
<solnic>
thanks again!
<solnic>
I think it looks fantastic
<kapowaz>
you're welcome — happy to help
<kapowaz>
great :)
_whitelogger has joined #rom-rb
<kapowaz>
I've just forked the rom-rb.org repo so I can create a patch with that newer header image in-situ. Now I will have to install ruby 2.0.0 for the first time ;)
shingara has joined #rom-rb
<solnic>
kapowaz: oh I can just give you access
<solnic>
no need to fork
<kapowaz>
that's cool, but I didn't want to force the change upon you unless you were happy with it
<kapowaz>
although I suppose there's nothing to stop me just pushing to a branch
<solnic>
kapowaz: branch then
<kapowaz>
:)
<kapowaz>
how do you run the site locally anyway?
<solnic>
kapowaz: bundle
<solnic>
kapowaz: middleman s
<solnic>
localhost:4567
<kapowaz>
it generates static files?
<kapowaz>
ah cool.
<solnic>
kapowaz: for deploy only
<solnic>
kapowaz: I'm sorry, I should've put info in README
<kapowaz>
no worries
<solnic>
brb
<kapowaz>
looks like installing ruby-2.0.0p0 is taking a while… I shall return to this task after lunch
solnic has quit [Quit: Leaving...]
mbj has joined #rom-rb
solnic has joined #rom-rb
solnic_ has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
solnic_ has quit [Read error: Connection reset by peer]
<mbj>
solnic: yeah, dont forget tweet!
<mbj>
solnic: ahh you already did! nice.
snusnu has quit [Quit: Leaving.]
solnic has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
cored has joined #rom-rb
<cored>
morning people
<mbj>
snusnu: hola
<snusnu>
mbj: yo
<mbj>
snusnu: Im fucked with compose-decompose
<mbj>
:D
<snusnu>
mbj: lol why?
solnic has joined #rom-rb
<snusnu>
yo solnic, rom-vagrant doesn't work like that, at least not in its current state
<mbj>
snusnu: dunno getting more confused over the time.
<snusnu>
solnic: bundle doesn't work, no bundler is installed
<snusnu>
solnic: the synced folder .dotfiles should be ~/.dotfiles (i will push that)
<snusnu>
mbj: well, what can i do to help you?
<mbj>
snusnu: dunno
<mbj>
:D
<snusnu>
mbj: have you maybe forgot to look at the integration spec app?
<snusnu>
:p
<mbj>
snusnu: I'm looking there.
<mbj>
getting more and more confused :D
<solnic>
snusnu: ok, so install bundler
<solnic>
snusnu: did it install rubies?
<mbj>
snusnu: Maybe I can come up with some more exact question :D
<snusnu>
mbj: please do so ;)
<snusnu>
solnic: yeah it installed rubies
<solnic>
snusnu: ok, so just install bundler yourself
<snusnu>
solnic: if i do gem install bundler it requires me to sudo … when i think that it should have bundler installed (with the recipe)
<solnic>
dotfiles stuff isn't finished yet so it may require manual plumbing
<solnic>
snusnu: chruby ruby-1.9
<solnic>
looks like chruby isn't setup automatically either
<solnic>
brb food
<mbj>
snusnu: Executor composer does not get run if handler returns failure?!
<mbj>
snusnu: (I expect it this way)
<snusnu>
mbj: i think it currently does get run if the handler returned a failure .. it doesn't get run if the handler raises an exception
<mbj>
snusnu: Can you change this?
<snusnu>
mbj: i guess not
<mbj>
It does not make sense to compose an object from invalid result?
<snusnu>
mbj: because i actually want to have the input available in the response, up till when it failed
<snusnu>
mbj: i want to know the exact request (as far as it could be processed)
<snusnu>
mbj: what's the problem you have with that?
<snusnu>
mbj: think about it this way, i deserialize, sanitize, authenticate, authorize and then validate .. after authorize, my Input object contains #actor and, say, #person
<snusnu>
mbj: if validation fails, i want to have the Input object available
<snusnu>
mbj: so that i know the actor, and the already converted input data
<snusnu>
mbj: it's the whole point of decompose/compose .. to be able to construct an object that *wraps* the actual input data .. and adds sth like, the actor
solnic has quit [Quit: Leaving...]
<mbj>
snusnu: okay
<mbj>
mom
<snusnu>
mbj: you can of course still get at the failure reason, i.e. the error output from say ducktrap/vanguard
<mbj>
snusnu: jo
<mbj>
snusnu: I changed to --rspec-unit locally 3 mutations left.
<mbj>
snusnu: Maybe you can do the same and help me killing the last mutations.
<mbj>
BTW I streamlined my brain again.
<mbj>
works.
<snusnu>
mbj: heh ok, so you think decompose/compose will help you with your usecases?
<snusnu>
mbj: ok, so what's our take here wrt rspec-dm2 or rspec-unit
<mbj>
snusnu: --rspec-unit
<snusnu>
mbj: tbh, i like how fast mutant is with rspec-dm2 .. and i don't like how many specs it makes me write
<mbj>
snusnu: So lets take --rspec-dm2
<mbj>
snusnu: I need that release :D
<snusnu>
mbj: but i wonder, if i actually want to change to rspec-unit with a dedicated effort, not intertwined with this pr (which already is out of scope
zekefast1 has quit [Quit: Leaving.]
<mbj>
snusnu: So can we team up to --rspec-dm2 cover that stuff?
<snusnu>
mbj: yeah
<snusnu>
mbj: i have time in, say 10minutes
<snusnu>
mbj: otoh, you could work on the mutations, and i work on the changelog and readme updates?
* snusnu
ducks
<snusnu>
:p
<mbj>
snusnu: okay
<mbj>
snusnu: I can also do a beta release NOW
<mbj>
And use this.
<mbj>
okay for you?
<snusnu>
mbj: as you please
<snusnu>
mbj: i guess you won't be killing the mutations then, NOW .. ;)
<snusnu>
mbj: which is fine, just tell me *if* you work on it :)
<mbj>
snusnu: I'll not kill mutations now and do a beta release.
<mbj>
I need this feature for clients work.
<snusnu>
mbj: ok, then i'll get at those remaining mutants
<mbj>
snusnu: big thx!
<snusnu>
mbj: no worries
zekefast has joined #rom-rb
<cored>
/j RubyOnRails
<cored>
ups
<snusnu>
kapowaz: huge thx for the logo and the branding repo! awesome work! looks really really nice
<kapowaz>
Glad to help out!
<snusnu>
:) great
<mbj>
kapowaz: Yeah, now explicit from me too! Thx!
<snusnu>
mbj: btw, how are we going to handle devtools (gem release)? .. i'm asking, cause i switched to chruby/ruby-install/chgems yesterday (don't ask why) .. and i found that with chgems, i still have to rely on bundle exec because there's no devtools gem
<snusnu>
mbj: that obviously isn't a big deal, but yeah, i wanted to bring it up
<cored>
wow great addition
<cored>
rom-vagrant
<cored>
snusnu: why not just add the url line inside the Vagrantfile
<cored>
?
<mbj>
snusnu: relesed substation-0.0.11.beta1
<mbj>
snusnu: (yanked substation-0.0.11.beta I released before, accidentally forgot the "1" suffix) sorry!
<snusnu>
mbj: no worries
<snusnu>
cored: tbh, i dunno much about vagrant, i only tried it today, because i pretty much nuked my work env yesterday night :p
<cored>
ok
<cored>
I just did that addition
kleech has joined #rom-rb
<cored>
testing it and then will submit a pull request
solnic has joined #rom-rb
<snusnu>
mbj: heh, did that change from #detect to #find actually silence the rubocop warning?
<snusnu>
mbj: if it does, a rubocop bug must've been fixed in the meantime
<snusnu>
cored: nice
<snusnu>
bbiab
<cored>
snusnu: are you sure that the Vagrantfile is working for you with ENV.fetch
<cored>
?
kleech has quit [Remote host closed the connection]
<mbj>
snusnu: yeah it silenced rubocop
<snusnu>
mbj: ok, but we actually want to use #detect .. and that seems to be a rubocop bug .. you can't configure it to allow #detect
<snusnu>
cored: what ENV.fetch do you mean?
<snusnu>
mbj: also, did you have any reason to skip 0.0.10 ? i'm asking cause you pushed 0.0.11.beta1 and the last release was 0.0.9
<mbj>
snusnu: sorry
<mbj>
snusnu: I saw 0.0.10 in VERSION constant and blindly incremented it.
<snusnu>
mbj: heh, i always bump the version right after the release
<snusnu>
mbj: which is the proper thing to do imo
<mbj>
snusnu: We need to be consistend, I'd love to follow it.
<snusnu>
mbj: if you're fine with that, you could yank the 0.0.11.beta1 and make it 0.0.10.beta1
<mbj>
snusnu: Will do so later.
<snusnu>
mbj: ok
<cored>
snusnu: I just fixed it, trying to add another mechanism for global configuration
dkubb has joined #rom-rb
<dkubb>
good morning
<cored>
snusnu: also don't you think is better for initial configuration to have the sycned dir inside your user home directory
<cored>
snusnu: is easier to handle permissions that one
<cored>
dkubb: hi
<dkubb>
cored: hello
<solnic>
morning dkubb
<snusnu>
cored: as i said, i never worked with vagrant, or any vm for that matter … i trust others to configure it properly, i only made changes that seemed necessary (and feasible) to me
<solnic>
dkubb: we have the logo for ROM on github and twitter :)
<solnic>
had to go through pain of setting up wordpress.com account in order to set a stupid avatar for github but oh well
<snusnu>
cored: i accidentally did rvm implode ree yesterday ……. needless to say, rvm implode doesn't take params, at least not a specific ruby … so next time i looked, all my rubies were gone lol
<snusnu>
good morning dkubb
<solnic>
snusnu: switch to ruby-install and chruby
<solnic>
so much nicer than rvm
<snusnu>
solnic: did that already
<solnic>
nice
<snusnu>
chgems is ruining my bash prompt tho
<solnic>
I don't use that
<solnic>
I work in VMs for projects with shit load of weird deps
<snusnu>
i tried it to get around bundle exec
<snusnu>
which doesn't work, because of devtools anyway
<cored>
snusnu: got it
<cored>
snusnu: I will try to get a good configuration
<cored>
snusnu: but it will change the way you are using that vm right now
<snusnu>
cored: best talk to solnic and the others, i don't really have an opinion on how it should work
<snusnu>
cored: i just want it *to work*
<snusnu>
;)
<cored>
he
<cored>
solnic:
<cored>
?
<snusnu>
dkubb: if i specify allow(foo).to receive(:bar).with(baz).and_return(bam) … can i simply do expect(foo).to receive(:bar) or do i need to do: expect(foo).to receive(:bar).with(baz)
<solnic>
snusnu: why you no want to try bogus?
<snusnu>
solnic: i want to, but not right in the middle of a large refactoring cycle
<solnic>
I see
<snusnu>
solnic: in fact, i want to do it soon tho
<snusnu>
solnic: hopefully while switching away from rspec-dm2 to rspec-unit (or whatever it's successor would be)
<snusnu>
solnic: so btw, do you happen to know the answer to my question? ;)
<solnic>
snusnu: nope
<snusnu>
ok
<snusnu>
solnic: i already somewhat dislike the fact that the rspec change came right in the middle of that topic branch, but oh well
<mbj>
snusnu, solnic: The successor of --rspec-foo is plain "--rspec" :D
<dkubb>
snusnu: oh, I'm not sure if the with() part carries over to the expectation. you may want to test that. I suspect it doesn't.
<dkubb>
mbj: what I would love to see is a way to specify the specs explicitly instead of a strategy
<snusnu>
dkubb: ok, i'll go with the more explicit thing, just add the with clause
<snusnu>
dkubb: even if it were to pick it up, it would still be somewhat confusing
<mbj>
dkubb: The whole strategy concept will be dropped.
<mbj>
And yeah I plan to support "explicit" kill syntax.
<mbj>
via the matcher
<dkubb>
snusnu: I think it kind of acts as a way to match.. like you could have two allow statements with the same receiver, and depending on which with() matches the and_return can be different.. at least that's what I thought, but I should test that
<mbj>
rspec:Foo::Bar::Baz#bar:spec/unit/**/*_spec.rb if you like.
<snusnu>
dkubb: ah yeah, that might be the case
<solnic>
cored: ???
<solnic>
cored: you pinged me but I have no idea what was the question
<cored>
he
<cored>
I'm making some changes to the rom-vagrant
<cored>
solnic: and snusnu asked me to ask you about it
<cored>
snusnu: you can check the pr now
<solnic>
cored: ok thanks! I will check it later because I'm hitting the road in a minute :)
<cored>
sure
<dkubb>
mbj: wdyt about having devtools just reference edge mutant instead of the gem?
<dkubb>
mbj: at least until we're in "maintenance" and it's not changing daily
<snusnu>
dkubb: mbj needs released gems ;) … at least that's what stopped me from asking him the same question
<dkubb>
snusnu: I'm going to try committing something small to mutant every week, or possibly every few days, so I'd expect that if others do the same mutant will be constantly updating for a few months anyway
<dkubb>
snusnu: there's still a ton of really simple, low hanging fruit .. like yesterday 10 minutes of work exposed a few new mutations in some of my gems
<snusnu>
dkubb: yeah i saw those new mutators you added, awesome … i guess they will find new mutations for substation too
solnic has quit [Ping timeout: 276 seconds]
<mbj>
dkubb: okay for me
<snusnu>
even better then ;)
<mbj>
dkubb: I'll continue to release gems
mbj has quit [Ping timeout: 264 seconds]
mbj has joined #rom-rb
<dkubb>
I'm going to remove those Installation sections from the README
<dkubb>
it'd be nice to have a standard README template for ROM gems
zekefast has quit [Quit: Leaving.]
dkubb|away has joined #rom-rb
dkubb has quit [Read error: Connection reset by peer]
dkubb|away has quit [Client Quit]
mbj has quit [Ping timeout: 246 seconds]
solnic has joined #rom-rb
dkubb has joined #rom-rb
<snusnu>
dkubb: just killed all substation mutations using rspec-dm2 … now running mutant master
<dkubb>
snusnu: nice!
<snusnu>
dkubb: i'm especially "thrilled" wether it recognizes my specs for the constants i introduced ;)
<dkubb>
snusnu: I know you were talking about rspec-unit, but I think there may be an alternative with YARD reflection that would be the best of all worlds
<snusnu>
dkubb: by recognizing, i mean, find mutations in them :)
<dkubb>
:)
<dkubb>
yeah, I added some really simple mutations
<snusnu>
dkubb: and i added some specs for consts proactively ;)
<dkubb>
I'm going to continue adding a few simple ones for the next few days as I work on mutable axiom relations
<snusnu>
nice!
<dkubb>
I want to get familiar with everything before I go depper
<dkubb>
*deeper
<dkubb>
it only takes about 10 mins or so to add a new simple mutator
<snusnu>
i might get my hands dirty with one at some point
<dkubb>
I'm gonig to try to go and make it so the Generic mutator is not needed
<dkubb>
it's actually not too hard
<dkubb>
and it was really neat bouncing back and forth between axiom-types and mutant as it found new mutations
<dkubb>
so I used that as a todo list.. popping off the top one and adding a mutator for it
<snusnu>
dkubb: hmm .. so, mutant still passes, but, the amount of mutations hasn't changed
<dkubb>
hmm
<snusnu>
i was running against beta20 … has mbj maybe released the latest changes already?
<dkubb>
not sure
<snusnu>
dkubb: lemme try again, if nothing changed, i'm still happy ;)
<dkubb>
snusnu: I was talking to someone yesterday about mapping, and they were mapping the standard "oauth Hash" that you get to an object, and I was looking around at mapping DSLs .. and I didn't find anything good, then I wondered if ROM's mapper will only act on a collection, or if it can act on one entry in the collection?
<snusnu>
dkubb: want me to update devtools to use mutant master? since mbj said he's fine with that, i do agree that we should do it
<snusnu>
dkubb: rom's mapper will explicitly only work on one entry in the collection!
<snusnu>
dkubb: that's the important design change we made, when ditching dm-mapper
<dkubb>
snusnu: yeah, go for it. we can keep it that way until things stabilize
<dkubb>
snusnu: oh I see, that's awesome. so the relation is responsible for using the mapper, right?
<snusnu>
dkubb: rom-relation will use its injected mapper to invoke it for every tuple
<dkubb>
the ROM relation I mean
<dkubb>
awesome
<dkubb>
that's good to hear
<snusnu>
yeah, i'm glad we did it, meant a lot of code nuking, but feels good
<dkubb>
is the DSL design still in flux?
<snusnu>
yeah, the DSL is in flux
<dkubb>
I was looking at some of the declarative SAX parser DSLs, and it reminded me of what I'd seen on ROM
<snusnu>
i only know SAX parsers back from my java days (which now is almost a decade ago heh)
<dkubb>
you basically would declare named attributes, and then define the mapping to the structure within each node
jessekempf has quit [Quit: Leaving.]
<snusnu>
yeah, only recently, for whatever reason, i skimmed through some hibernate docs, and even those look familiar :)
<snusnu>
dkubb: ok, so substation is fully mutation covered using mutant master
<snusnu>
fyi
<snusnu>
Nodes handled by generic mutator (type:occurrences):
<snusnu>
blockarg : 10
<snusnu>
kwbegin : 1
<snusnu>
rescue : 1
<snusnu>
block_pass: 10
<snusnu>
and : 1
<snusnu>
resbody : 1
<snusnu>
or : 1
<dkubb>
snusnu: I was thinking, if we get the DSL working with ROM then we may be able to use it in other contexts, like this
<dkubb>
mapping is such a common thing, I was surprised there's no standard approach
<dkubb>
in ruby anyway
<dkubb>
snusnu: awesome!
<snusnu>
dkubb: yeah, solnic and i were talking about that too .. it's an explicit goal that rom-mapper will be useful without rom-relation .. and particularly, without any axiom code
<dkubb>
snusnu: I think I want to add "and", "or" and "not" mutators soon
<snusnu>
dkubb: rom-mapper should be able to map a "nested" tuple to an object (with ev/ec)
<snusnu>
dkubb: i.e. it should work on a raw hash too
<dkubb>
snusnu: if the mapping structure can be reflected on, then we could even look at doing two way mappings.. so for example, you define a mapping from a data structure that is created from a JSON document, you could then build an "as_json" method that goes in the other direction
<snusnu>
dkubb: no idea how we'd do the ev/ec mapping without axiom's group/ungroup tho .. might be that we either need a separate implemnetation, or make it depend on axiom
<dkubb>
snusnu: yeah, that was my intention with the axiom design, that an Array of Hashes could stand in in many cases.. for easier testing, and to make interfaces more generic
solnic has joined #rom-rb
<snusnu>
dkubb: you really should get familiar with ducktrap ;)
<dkubb>
I know
<snusnu>
dkubb: i have that feeling, that we will use it *a lot*
mbj has joined #rom-rb
<snusnu>
dkubb: it can already do that
<dkubb>
it's an interesting idea
<snusnu>
lol speaking of ducktrap makes mbj appear ;)
<dkubb>
snusnu: I think mbj heard us talking about ducktrap
<snusnu>
heh, i wouldn't be surprised :)
<dkubb>
ducktrap ducktrap ducktrap
* dkubb
poof, mbj appears
<snusnu>
mwhaha
<dkubb>
yeah, the idea of DSLs that can be defined to handle two way transformations is really appealing
<snusnu>
dkubb: the thing with ducktrap, is that the dsl is kinda ugly'ish … and not at all "mapper ready" .. but the core can do the mapping we want already
<snusnu>
dkubb: it'll be interesting to see how to marry both concepts, maybe we can just plug 2 different dsl layers on top
<snusnu>
dkubb: the current dsl is targeted mostly at sanitizing user input if i got it correctly … so you describe how user input should look like, and it will turn that into your DTO or show detailed errors
<snusnu>
dkubb: that same ducktrap, can then be used to turn the DTO into the original input
<mbj>
lol
<mbj>
looool
<snusnu>
:D
<mbj>
dkubb: It performs really well for sanitizing inputs to DTOs and vice versa.
<mbj>
my so called "domain objects" are nothing more than dtos.
<mbj>
and IMHO a database record is nothing more that must be (de)serialized to a DTO
<dkubb>
that's interesting
<mbj>
At my clients ducktrap, they love the current DSL.
<mbj>
We need to polish it a bit.
<mbj>
But I'm not a perfect DSL person.
<dkubb>
functionality is most important
<dkubb>
better DSLs fall out of real-world usage
<mbj>
dkubb: Ducktrap has a really nice property: Context and history tracking.
<dkubb>
the best DSLs don't just appear, they're usually the result of continual small improvements
<mbj>
you can see what history a DTO (and more important) an error has.
<mbj>
ducktrap internally maintains an ast like structure
<dkubb>
with axiom for example, my very first DSL was too raw for usage, it's a bit better now, but I suspect it'll get much better once we start prettying up ROM::Relation and then pushing down the interface changes to axiom
<mbj>
And that "tree of transformation" nodes gets walked (executed on input) building a similar transformation history tree.
<dkubb>
hehe
<snusnu>
dkubb: from a quick look at sax-stream .. i'm pretty sure rom-mapper will be a good fit for it once it's ready
<mbj>
And ducktrap is fast!
<mbj>
I dont have speed issues anymore.
<mbj>
(even with that context tracking)
<snusnu>
mbj: btw, decompose-compose passes mutant master now
<mbj>
I'd love to plug coercible to leaves.
<mbj>
snusnu: thx!
<mbj>
snusnu: BIG THX.
<snusnu>
:) no worries
<snusnu>
it's not like i don't need it myself :)
<snusnu>
mbj: fwiw, i didn't have to change any code, so your beta1 release should be safe
<mbj>
will appear later in channel again, just say the magic words :D
<snusnu>
mbj: but speaking of which, it'd be cool if you could nuke it at some point soon
<snusnu>
mwhaha
<dkubb>
mbj: snusnu and I were talking about mapping before you logged in
<dkubb>
haha
<mbj>
dkubb: Yeah, just read the backlog.
<mbj>
What we have to say till solnic appears?
<snusnu>
rspec-dm2
<snusnu>
lol
<dkubb>
hah
mbj has quit [Read error: Connection reset by peer]
<dkubb>
I still love it
<dkubb>
I like tiny small spec files
<dkubb>
I don't like having to specify the non-public APIs though
<snusnu>
yeah, i do like it too .. but i would *love* to have it recognize yard public @api
<dkubb>
if I could reflect on YARD to eliminate those, then that would be the perfect strategy for me
<snusnu>
yeah
<dkubb>
I don't like the idea of writing specs that test more than one public method, and relying on incidental coverage.. because the internal implementation may change, and a public method may not be used internally
<snusnu>
yeah, that's sound reasoning .. you can't control how people use your public api .. so you should have specs that truly make sure that every public api method works as specified
<dkubb>
when you rely on incidental coverage, you're moving closer to integration tests imho
<snusnu>
yup
<dkubb>
plus people using a public api come to expect certain behaviour, and if that behaviour is unspecified because you never tested it directly, then you can break the interface unintentionally
<dkubb>
exactly
<solnic>
who summoned me?
<dkubb>
haha
<snusnu>
lol, i knew it
<solnic>
:P
<dkubb>
"let's use rspec-dm2 everywhere"
<solnic>
:)
<snusnu>
hehe
<snusnu>
speaking of which … isn't it time to find a new name for that sucker?
<solnic>
would love to chime in but I gtg
<solnic>
sooo ttyl
<solnic>
snusnu: it's going away, strategies go away
<snusnu>
or do we not care and wait till mutant ditched the whole concept of strategies
<snusnu>
right
<solnic>
so, no need to change something that's gonna be removed :)
<snusnu>
right
<dkubb>
you can summon me by saying "raise the bar"
<snusnu>
i even tried downloading that file manually, and it works
<snusnu>
dkubb: rubocop warns about: allow(handler_result).to receive(:success?).with().and_return(handler_success) … specifically it warns about calling a method with () if it has no parameters
<snusnu>
dkubb: do you know of another way to make sure that the method should be called with no params?
<mbj>
snusnu: ignore travis and ruby-head
<snusnu>
dkubb: sry for the noise, i guess i should simply skip the call to #with
<snusnu>
mbj: i do, i'm just curious what's up with travis
<dkubb>
snusnu: I usually have a 1:1 relationship between my allow() statements and expect() statements, so I allow the expect() to assert the arguments to the method and allow the allow() statement to be somewhat dumb.. sometimes if it's a command method then I'll just use as_null_object and skip doing allow()
<dkubb>
snusnu: that's one way to reduce brittle overmocking and overstubbing
cored has quit [Ping timeout: 256 seconds]
cored has joined #rom-rb
<snusnu>
dkubb: btw, why do we need #allow in the first place?
<snusnu>
dkubb: seems like #expect alone always works too
<snusnu>
mbj: yeah, but it works if i do that with a normal double .. no need to stub anything on that
<dkubb>
snusnu: I try not to use expect in my before blocks because when it fails, it fails for every spec and it's hard to trace. if part of the contract of the method is to forward a specific message to some other object, I use an explicit example block for that and try to keep my setup as minimal as possible
<solnic>
dkubb, mbj, snusnu: wdyt about wrapping things up for the first release and pushing it when we're at EuruCamp?
<dkubb>
I don't think I'm going to call it a DO adapter. I don't like the idea of binding it to a specific DB driver
<mbj>
1) mutant (obvious, we need that tool) 2) axiom-arango-adapter 3) whatever needs help
<mbj>
I think I can help a lot with sql gem.
<dkubb>
I'll probably do with axiom-sql-adapter (or the base adapter) and then axiom-postgresql-adapter, axiom-mysql-adapter, etc. we may even want to pull up some stuff between the adapters into ana axiom-abstract-adapter, even if it just provides shared specs and stub interfaces
<dkubb>
mbj: yeah, I'm looking forward to that. axiom-fuzzer would be nice to run against all the adapters as we make them
<dkubb>
snusnu: solnic: what are your guy's main priorities before EuruCamp?
<snusnu>
i hope that i'll be able to return to rom-relation or rom-mapper before that, but i'm afraid i can't really promise that yet … if i find time, i'd love to think more about the schema, and DSLs, and potentially how we could approach relationships this time
<mbj>
dkubb: Yeah, I totally forgot axiom-fuzzer
<snusnu>
altho as i said, i wouldn't want to prioritize relationships currently
<mbj>
dkubb: Also updating axiom-sexp to use whitequark/ast would be handy.
<mbj>
And to transform from this ast back to relations.
solnic has quit [Quit: Leaving...]
<snusnu>
mbj: i just merged decompose-compose
<mbj>
snusnu: thx!
<mbj>
snusnu: I'll take a coffee and do my part
<snusnu>
mbj: sweet, thx!
solnic has joined #rom-rb
<dkubb>
mbj: at some point, maybe 6 months down the line, we can discuss what it would mean to use ast underneath axiom. I know some of the transformations will become easier, but I want to make sure that we retain the abilities we have now
<solnic>
dkubb: my priority is session and whatever is needed on the relation/mapper side
<solnic>
I'm gonna work on integrating session with an UoW soon too
<solnic>
for that to work I need memory adapter :)
<dkubb>
I'd like to help out with the DSL design stuff too
<dkubb>
I think we all would
<mbj>
dkubb: yeah
<solnic>
and yes, relationships is totally not prioritized on my list
<dkubb>
by far the user interface is my #1 priority. it doesn't matter how clean the internals are, if the interface sucks no one (including us) will want to use it
<dkubb>
for the most part I think we've been happy with the interfaces though
<mbj>
dkubb: I love the idea to use that ast where possible.
<dkubb>
I have a few small tools I would like to build, like a graphviz visualization of axiom relations, as well as a way to represent the relation data in a tabular format
<dkubb>
but those could probably be delegated to someone who wants to contribute
<mbj>
dkubb: Those tools will greatly benefit by ast based axiom!
<mbj>
dkubb: I think axiom-sexp can be the scratch pad for that future ast format.
<dkubb>
mbj: I've spiked both of them out with the existing axiom and they're mostly trivial
<mbj>
dkubb: sure
<dkubb>
I would probably make the graphviz thing work with axiom-sexp
<mbj>
BTW we could and should ping companies about adapter sponsorship
<mbj>
Just pinged triagens about our plans and how I plan to update axiom-arango-adapter.
<dkubb>
along with the axiom-tabelizer (or whatever we call it) I'd like a way to read/write csv
<dkubb>
mbj: we could try riak.. elight, someone who is interested in ROM dev, just started work there
<dkubb>
riak is made by basho
<mbj>
dkubb: yeah
<mbj>
I know
<mbj>
My current client feeds me well, but that job will be done at some time in future. Would love to do adapters again. Somehow I like to do transformations...
<mbj>
ducktrap (a transformation tool), mutant (a special kind of transformation tool), ...
<mbj>
But we all like to do this, as programming is to define how to create an output from an input.
<mbj>
Nothing special with me :D
<snusnu>
dkubb: i wanted to run a thought i recently had (again) by you … it's about structuring code for public/private api
<snusnu>
dkubb: so basically, in the java world, i remember people having "internal" packages, i.e. packages named "internal" .. and all private api ended up in those
<snusnu>
dkubb: so i was wondering, if i should maybe try a code layout like this in ruby … having an internal namespace .. so the public api would live, say, under Substation .. and the private api under Substation::Internal
<snusnu>
dkubb: i guess it doesn't fit too well with classes that expose both private and public api .. but i wonder, and that's just a wild thought, if that may be considered a smell anyways
<snusnu>
dkubb: i have this feeling, that with the immutable design, and the resulting small/simple objects, this case is actually very rare
<snusnu>
mbj, solnic ^^^^
<mbj>
snusnu: Not my preference.
<mbj>
snusnu: All our "private" APIs should be that sharp and usable an external person could use them. Without stability guarantee.
<snusnu>
mbj: yeah, no idea if it makes sense, i guess i need to hear arguments against it tho, in order not to just try it
<mbj>
snusnu: It does not make sense :D (If you like to hear that)
<snusnu>
hehe, well, i guess i wouldn't buy it just like that
<snusnu>
then again, i'm totally not saying i *want* to do it, i was mostly interested in your thoughts .. and you've already started expressing them ;)
<mbj>
snusnu: I love to structure code for minimal duplication
<solnic>
snusnu: meh me no likey, extra module sounds bad
<mbj>
I dont think an Internal namespace would reduce code complexity or duplication
<solnic>
I don't think it's rare to have an object composed of some collabolator objects that are treated as private part of the API
<snusnu>
not everything is about complexity and duplication tho .. it's also about accessibility
<solnic>
doesn't matter if you have immutable objects or not
<snusnu>
solnic: that alone is no problem
<snusnu>
solnic: it'd just mean that one of the collaborators comes from the internal module
<solnic>
isn't @api private not enough?
<snusnu>
solnic: the public api exposed can be different, and if it exposes the collaborator, it's not an internal one
<snusnu>
ok guys, bad timing, need to switch places, will read the logs .. bbiab
<solnic>
kk ttyl
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<snusnu>
okback
<dkubb>
snusnu: yeah, I'm not sure how many of our interfaces will be fully private. I would guess most classes are a mix
<dkubb>
snusnu: in YARD there is the @private keyword, not to be confused with @api private, where you can mark a class, constant or whatever as private
<dkubb>
on the off chance we have private classes, we could use that to document them
<dkubb>
I know in my own code I sometimes do write private classes, but it's usually rare, at most a few percent of the whole project
<mbj>
"our api should be nice enough to be usable regardless of @api tag"
<dkubb>
yeah
<dkubb>
a private api is no excuse to have something be ugly or not usable
<mbj>
but we mark that API we plan to retain with @api public.
<snusnu>
that's not a matter of nice enough imo .. it's a matter of do i want to do that
<dkubb>
after all, we are the users of that
<dkubb>
it should almost be nicer than what we expose to the public ;)
<snusnu>
hehe
<dkubb>
because we'll be the ones to feel the pain of bad internals
<dkubb>
I'm kidding, but it should be on the same level of quality as public interfaces
<dkubb>
I think there's a tendency for peolpe to cut corners with private apis
<dkubb>
and do things like primitive obsession, violate srp or demter, or have methods with lots of arguments. we need to audit our private stuff as toughly as everything else
<dkubb>
when I code review I don't even look at the @api tag
<snusnu>
fwiw, my thought comes from the "fact" .. that when i (as a user) browse, say, substation … i actually don't care about lots of the classes
<snusnu>
and it somehow feels weird that those "internal" classes are "intertwined" with the ones i care about
<snusnu>
not intertwined as in collaborator, but as in directory layout
<mbj>
My brain does not separate in public or private API for ages.
<mbj>
specially with rom* code.
<snusnu>
i'm not talking about rom* specifically here btw
<snusnu>
in fact, i would NOT want to do it with rom
<dkubb>
I usually try to keep @api private to only methods with private visibility
<snusnu>
at least not before i found it to be worthwhile, which i myself am still doubting a lot, it was just an idea
<snusnu>
dkubb: that's my reasoning, there are private/internal classes (builder objects, etc) which an end user doesn't care about…. and there are private methods, which help do the job, and obviously aren't public api anyway
<solnic>
I don't think definition of @api private is "that lower level uglyness"
<snusnu>
mbj: btw, are you planning to release 0.0.10.beta1 from upstream, or are you fine with your (not uptodate) fork ,)
<solnic>
it's not how I approach it
<snusnu>
solnic: i agree, it's not
<solnic>
I do think though that there's quite often a need to wrap up some complex piece of logic inside a small private object
<snusnu>
i think about if it makes sense for a client of the lib to use it or not, i.e. if it represents a *use case*
<solnic>
and delegate to it from another object that does expose a public interface
<mbj>
snusnu: Didnt I released your latest stuff
<mbj>
snusnu: ?
<mbj>
snusnu: git pull --rebase before releasing.
<solnic>
and my point with not writing direct specs to cover those private parts is because those are...private parts
<solnic>
they are a subject to change
<snusnu>
and that's exactly my "reasoning" for putting them somewhere special
<solnic>
what I found really terribly wrong in virtus is that almost every time I changed a line of code somewhere some tests would fail
<mbj>
snusnu: Seems I released the latest and greatest :D
<solnic>
forgot to add "(..) without changing behavior"
<snusnu>
mbj: your decompose-compose branch has 242 commits, upstream master has 269
<snusnu>
mbj: also, your latest commit isn't my latest one
<snusnu>
....
<mbj>
snusnu: I released from master after you merged.
<solnic>
I just don't want to write specs for every object in my lib that has public methods, that's just testing implementation details and makes things very hard to refactor because of a massive amount of brittle tests
<mbj>
will delete my branch
kalleth has quit [Quit: No Ping reply in 180 seconds.]
pdswan has quit [Quit: pdswan]
<snusnu>
solnic: right, but that's kinda offtopic ;)
kalleth has joined #rom-rb
<snusnu>
mbj: i guess you should just release from my master
<solnic>
snusnu: I'm an op here, I'm allowed to change topics lol
<snusnu>
!
<mbj>
solnic: I hear you
<mbj>
solnic: Once I finished that client stuff I'll work on flexible rspec with world preloading
<mbj>
than we can release 0.3 stable.
<snusnu>
mbj, solnic: i just don't see how that relates to the code layout .. i mean, obviously, that internal code would mostly be the code you don't want to explicitly test .. but yeah, apart from that .. offtopic :p
<dkubb>
solnic: you're talking about public visibility methods. you do agree that methods in the public interface should have tests and that we should not rely on incidental coverage?
<snusnu>
what i'm thinking of, is that we have a set of classes that only contain @api public methods and (@api) private helper methods
<snusnu>
and another set, that only contains classes that support the private api, and are of no interest to the user of a lib, because they are, well, not public api
<snusnu>
and obviously they also support the public api ...
<solnic>
dkubb: yes of course
<dkubb>
solnic: kk, I think we're on the same page then
<solnic>
dkubb: I just don't want to have tests for internals, that's all
<dkubb>
solnic: I know you don't like spec-file per-method though
<snusnu>
the point is, those internal classes DO NOT contain @api public stuff
<solnic>
and we did have tests for internals in dm-mapper btw
<dkubb>
yeah, that was probably a mistake
<solnic>
I hated those specs
<dkubb>
see, with axiom, very little of the code is actually private
<snusnu>
rightfully so
<dkubb>
if it's private most of the time it was also private visibility
<solnic>
that's why now I try as hard as possible to figure out what's internal and what's public
<snusnu>
dkubb: yeah, i wanted to mention that already .. it always depends on the nature of the lib too
kalleth has quit [Client Quit]
<dkubb>
otherwise there's almost no code that isn't part of the public interface
<solnic>
yeah I guess axiom is special :)
<dkubb>
I could be wrong though.. it's been a while since I worked heavily on it
<dkubb>
I thought about making a simple tool to check to make sure there was a 1:1 correspondence between the tests and the @api public methods
<solnic>
dkubb: I don't like mutant's rspec-dm2 strategy
<snusnu>
so here's my thought .. with simple/small/dedicated/immutable classes …. most of them will either be public public .. or helper/internal stuff
<dkubb>
and to flag any private method tests
<solnic>
I like spec file per method
<dkubb>
oh you do?
<dkubb>
I didn't know that
<solnic>
well, I experimented with spec per object but meh
<solnic>
short spec files are really nice
kalleth has joined #rom-rb
<dkubb>
the only thing I dislike is that sometimes I have to share context setup
<dkubb>
I like that too
<solnic>
yes context sharing is extra work
<solnic>
and adds even more files
<dkubb>
I think spec per object is probably the most common approach people use. it's rails' default, kinda
<snusnu>
that should not be of interest to us
<snusnu>
(rails default i mean)
<dkubb>
I know
<solnic>
atm rom's libs are so small that I don't feel like test suites will be hard to maintain
<dkubb>
i was just stating that it's common, so we kind of all know what it's like
<snusnu>
yeah ok, thought so anyway ;) just wanted to state my dislike for that spec layout again
<dkubb>
we all have that as a frame of reference to measure the spec file per-method approach
<dkubb>
snusnu: oh hehe. so it's you who doesn't like it :)
<snusnu>
i'm all for one spec file per method, and i want those to only be necessary for @api public methods
<snusnu>
dkubb: nono ;)
<dkubb>
hehe
<dkubb>
I actually want a tool to scream at me if I write a spec for an @api private method, or a method in a @private class
<snusnu>
yeah
<dkubb>
not only should it discourage me, it should smack my hand
<snusnu>
right
<dkubb>
maybe even exit with 1 if I'm feeling strict
<snusnu>
lol
<dkubb>
what do you guys feel about enabling the new --warnings flag in the .rspec file?
<dkubb>
it'll help our libs become warning safe
<snusnu>
+1
<dkubb>
at least allow us to work towards it
<dkubb>
I enabled it on a few libs as a test and it wasn't too bad
<dkubb>
our style of coding is relatively good wrt warnings
<dkubb>
it took me like 5 mins to fix ice_nine for example
<snusnu>
interesting, i'm gonna fix the warnings for substation, there are some
<snusnu>
mbj: here's one for you: .gem/ruby/1.9.3/gems/concord-0.1.2/lib/concord.rb:72: warning: `*' interpreted as argument prefix
<snusnu>
;)
<snusnu>
dkubb: how do you go about warnings like this: warning: method redefined; discarding old ...
<snusnu>
dkubb: they happen when i redefine a method that concord generated protected, to be public
<snusnu>
dkubb: i actually did that, because otherwise i loose the ability to document them
<mbj>
snusnu: It should be interpreted as argument prefix :D
<mbj>
snusnu: just add parens to silence it.
<snusnu>
mbj: haven't even looked at concord yet, it simply was the first warning i saw for substation
<dkubb>
snusnu: I think there are ways with YARD to document generated methods
<snusnu>
dkubb: ah right, i remember … i wanted to avoid having to look at those tho ;)
<solnic>
dkubb: my vim setup shows warnings so I write warning-free code by default ;)
<dkubb>
oh nice
<snusnu>
dkubb: in fact, only recently i said, i can *never* remember more advanced yard syntax … which makes me think i'm dumb, or it's too complex ;)
<dkubb>
I need to do that
<dkubb>
snusnu: I think it's just unfamiliar. we tend to use only a small part of YARD for most things
<mbj>
mutant --rspec-dm2 ::Mutant* # would not work
<solnic>
in your vimrc?
<mbj>
jessekempf: zombie --rspec-dm2 ::Mutant* # would work
<mbj>
jessekempf: we use "zombie" mode also for adamantium, anima and concord, direct dependencies
<mbj>
jessekempf: Also for inflecto, descendants_tracker, ....
<cored>
solnic: checking
<mbj>
jessekempf: If you'd like to contribute, pls ping :D I'm very happy to help in code diving :D
<cored>
solnic: yeap
<cored>
solnic: I have that
<jessekempf>
mbj: I understand the significance. I'll probably need your help determining how to express certain tests — I'm branching off from the 0.3.0.beta20 Mutant::Killer::Rspec to have it inline rspec failure output when given a noop test.
<mbj>
jessekempf: pls realize Mutant::Killer:Rspec is executed via Mutant::Killer::Forking
<mbj>
jessekempf: So you'd have to do "cross process" propagation of that error.
<mbj>
jessekempf: Also I'm refactoring the rspec killer to preload the world
<mbj>
jessekempf: For starting with mutant development I'd suggest a lower hanging fruit.
<mbj>
jessekempf: See TODO :D
<jessekempf>
mbj: Oh, I'm talking even more basic than passing exceptions from one process to another. I just mean not swallowing stdout/stderr.
<mbj>
jessekempf: Ahh okay
<mbj>
jessekempf: You can reintroduce the --debug flag it got lost in 0.3
<mbj>
jessekempf: And patch Killer::RSpec not to pass in a StringIO
<jessekempf>
mbj: did —debug used to emit *everything* from rspec?
<mbj>
jessekempf: jo
<mbj>
jessekempf: It caused to see all rspec output (a lot)
<jessekempf>
mbj: got it
<mbj>
jessekempf: "jo" is yes in north german slang
<jessekempf>
mbj: kk. It seemed like it was halfway between "no" and "ja", so I was confused for a sec.
<snusnu>
mbj: hah! seems like mutant caught something that smelled fishy when i did it in the first place ;)
<snusnu>
dkubb: ah what the heck, happy birthday from me too! you'll get plenty of wishes in "your tomorrow" anyway ;)
<snusnu>
dkubb: which btw reminds me, i smiled when you sent me birthday wishes on twitter, on may 1 … my birthday's actually on jan 5 … but i *always* forget that my osx is english/american .. so all dates i enter are in your format :D