<postmodern>
wasn't there some talk about a .js tld
<mbj>
postmodern: never enter domains you'd like to register yourself into scammy forms :D
<postmodern>
mbj, lol right newb mistake
<solnic>
damn :)
<postmodern>
if this is real, i bet they are using punycode domains to fake .rb
splattael has joined #rom-rb
<solnic>
postmodern: thanks :)
<solnic>
postmodern: btw that graph isn't used at the moment :D
<solnic>
it will be once we re-add relationships
<postmodern>
seems straight forward
<postmodern>
i like how you use methods to return base-classes
<mbj>
postmodern: heh
<solnic>
postmodern: this will be actually removed, we no longer need node/edge subclasses :D
<postmodern>
ah interesting
<solnic>
I also tend to avoid injecting *classes* this days and prefer to inject instances
<solnic>
s/this/these/
<mbj>
solnic: +1
<postmodern>
so you'd have a new_node method
<solnic>
not sure how I'd approach this in the graph case
<solnic>
it'd be probably completely different
<solnic>
we'd probably have some node/edge instance provider
snusnu has joined #rom-rb
ptico has quit [Remote host closed the connection]
snusnu has quit [Ping timeout: 240 seconds]
snusnu has joined #rom-rb
cored has joined #rom-rb
cored has joined #rom-rb
postmodern has quit [Quit: Leaving]
ptico has joined #rom-rb
<solnic>
snusnu: morning
<solnic>
snusnu: seen my question re relation dsl?
knowtheory has joined #rom-rb
knowtheo1y has joined #rom-rb
knowtheory has quit [Read error: Connection reset by peer]
<cored>
morning
<solnic>
hi cored
<cored>
hello
<cored>
solnic: was a long weekend for me I wasn't around that much
<cored>
still thinking in the name for the share functionality
<cored>
between classes and modules const_missing
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
Guest76576 is now known as mongrelion
mongrelion has quit [Changing host]
mongrelion has joined #rom-rb
zekefast has quit [Quit: Leaving.]
snusnu has quit [Ping timeout: 260 seconds]
snusnu has joined #rom-rb
splattael has quit [Quit: Leaving.]
<dkubb>
good morning
<solnic>
dkubb: hi
<mongrelion>
high
<solnic>
snusnu: you there?
<snusnu>
solnic: yo, kinda
<snusnu>
mbj: you there?
<snusnu>
;)
<solnic>
snusnu: ah ok, I wanted to ask about schema
<solnic>
why do we need base_relation instead of just relation?
<snusnu>
mbj: if i see Killed: rspec:noop:Substation::Environment::DSL#register, that's not a good thing, right? i mean, why does it kill the noop ?
<snusnu>
solnic: from a dsl pov, only base relations should expose the #repository
<solnic>
snusnu: but do we want to have just "relation" then?
<snusnu>
solnic: yeah, it registers something like a join relation, or a view or whatever?
<solnic>
hmm ok
<mbj>
hi
<solnic>
I guess it's just a proper thing to do to have this distinction
<mbj>
snusnu: Killing the noop means eigher: Your specs are not passing, or mutant/to_source has a bug!
<mbj>
snusnu: Most likely to_source!
<dkubb>
mbj: you added that noop test to catch those kinds of bugs, right?
<mbj>
snusnu: Feel free to report, but most likely it was fixed already in master
<mbj>
dkubb: yeah
<snusnu>
mbj: yeah, my specs are passing, that's why i "reported" it
<mbj>
dkubb: Noop is a "neutral" mutation, just inject the unparsed source to see if mutation does not get killed.
<dkubb>
mbj: a self-test like that is a nice approach. better than proceeding with the assumption that it's perfect and raising errors for all sorts of other buggy mutations
<snusnu>
mbj: i'll kill the remaining mutations, and then push it to a branch and link that to a bug report
<mbj>
dkubb: in 0.3 I have two classes Mutation::Evil, and Mutation:Noop, both implement #success?(killer). Noop returns success if the killer did not killed the mutation, evil other way round.
<mbj>
I like this design a lot :D
<snusnu>
mbj: but, are you saying mutant master is usable?
<dkubb>
mbj: that's pretty cool
<mbj>
snusnu: jo, it lacks an important feature: Reporting failed mutations with the diff.
<snusnu>
mbj: so if i haven't got any, i shouldn't care? ;)
<mbj>
snusnu: Maybe master is broken than :D
<dkubb>
I tried it with axiom-types yesterday and it was a bit broken still
<snusnu>
mbj: i'm not sure if you got me right, i meant that if my code has no mutations, thus mutant passes, i basically don't need to care about the fact that it doesn't report mutations with a nice diff
<mbj>
snusnu: yeah
<mbj>
snusnu: But maybe mutant master is broken if it does not find uncovered mutations in newly written code.
<dkubb>
axiom-types has no mutations reported by mutant 0.2.x, so I was curious to test it with master
<mbj>
snusnu: With all release I have to fix older, already mutation covered libs.
<mbj>
Yeah, it makes nervous NOT to see mutations.
<mbj>
*uncovered
<solnic>
mbj: can I try mutant from master?
<mbj>
solnic: jo, but it will not report mutation details.
djsell has joined #rom-rb
<solnic>
mbj: oh ok
<mbj>
solnic: You'll only see amount of mutations, kill ratio etc.
<solnic>
so I guess it's too early
<dkubb>
mbj: in sql.rb, for the DATE and DATETIME literal nodes I may render them as: "DATE '2013-01-01'" .. apparently that keyword is valid in SQL, and I tested it out in MySQL. I think it coerces the literal string
<dkubb>
it's a bit weird because I haven't seen it in the wild, but it's how you represent a literal DATE/DATETIME
<mbj>
dkubb: Ideally we find a literal that behaves the same across all implementations.
<mbj>
dkubb: Or at least works like in postgresql.
<mbj>
I'd prefer to stick to postgres than to the "desing by comitee" thin nobody really implements.
<dkubb>
mbj: it looks like MySQL and PostgreSQL both implement it
<mbj>
dkubb: okay, I'm not really sharp in reading your messages, sleept only 3-4 hours this night. My child woke us up all 30min :(
<snusnu>
mbj: btw, i realized that in essence, substation is just an implementation of a "Chain of responsibility" combined with a facility that allows to register chains with a given name
<snusnu>
mbj: and means to invoke them by name
<mbj>
snusnu: jo, I sell it as "domain command abstraction"
<mbj>
snusnu: Regardless how we name it. It is NICE!
<snusnu>
mbj: yeah, i was thinking about exactly that, imo a chain of responsibility is "more clear", people might know that
<mbj>
snusnu: not for me, but I'm not a native speaker
<snusnu>
mbj: imo the chain of responsibility is SUCH a nice fit for representing the typical (http) request/response cycle
<snusnu>
mbj: i was thinking more in "patterns" terms
<snusnu>
mbj: people might be familiar with the pattern
<mbj>
snusnu: ack
djsell has quit [Ping timeout: 240 seconds]
djsell has joined #rom-rb
cored has quit [Ping timeout: 256 seconds]
djsell has quit [Ping timeout: 248 seconds]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
djsell has joined #rom-rb
solnic has quit [Read error: Connection reset by peer]
<snusnu>
mbj: can you add me to ducktrap and vanguard so that i can make direct PRs without forking the repos?
lorenzo_ has quit [Quit: Lost terminal]
elight has joined #rom-rb
<elight>
Ohai
<elight>
solnic_: Stupid question. Any idea why the '0.0.0'.freeze in rom-mapper version.rb?
<elight>
Bundler hates it.
<snusnu>
elight: hey, i pushed a fix
<elight>
snusnu: Cool. I just removed the freeze call in my local version FWIW
<snusnu>
elight: we like to freeze all our consts, and for some reason, bundler or rubygems need to modify the version string, for whatever reason
<elight>
Odd, right?
<elight>
;-)
<snusnu>
totally :)
<elight>
Funny. I'd never thought to freeze consts. But it makes sense. Strings are mutable in Ruby...
<elight>
Just like consts pointers aren't mutable in C++ but what they point to is.
<elight>
IIRC
<elight>
(ugh C++)
<snusnu>
elight: yeah, i guess it's a matter of style, but with our general preference towards immutability (deep) freezing seems right, and if it's just to make sure we don't accidentally modify stuff
<mbj>
elight: Somtimes someone will try to mutate an argument in a function to do processing.
<elight>
I'm not complaining but for the VERSION barfage from bundler
<mbj>
elight: rubygems/bundler for example uses String#gsub! to prepare parsing!
<mbj>
:D
<mbj>
So if you define a version in your code, rubygems/bundler MODIFIES it while parsing.
<elight>
i've gathered. odd.
<mbj>
It is totally bundler/rubygems fault, "do not modify argument unless this is the purpose of the method".
<snusnu>
mbj: so after streamlining ducktrap/vanguard result api, i ended up noticing that my ducktrap/vanguard processors behave *slightly* different: http://pastie.org/8052868
<snusnu>
mbj: so, i'm looking for more generic names
<snusnu>
mbj: imo the ducktrap could be a "Transformer", and the vanguard could be something like a "Check"
<snusnu>
mbj: the ducktrap processor needs to pass on the object that ducktrap successfully transformed
<snusnu>
mbj: while the vanguard processor needs to return the input unaltered, in case the validation check was successful
elight has quit [Remote host closed the connection]
<mbj>
snusnu: You see the duplication...
<snusnu>
mbj: tbh, i totally overlooked that difference initially, and wanted to "collapse" both processors into just Evaluator, obviously that isn't going to work tho
<snusnu>
mbj: of course i see it
<mbj>
snusnu: It should be solvable
<snusnu>
mbj: i'm now looking for better names ..
<mbj>
snusnu: BTW feel free to push your changes.
<snusnu>
mbj: i already have
<mbj>
snusnu: I'm up to long, cannot think well.
<mbj>
talking about ducktrap and vanguard
<mbj>
you have access now!
<snusnu>
mbj: i'm not concerned with (how to remove) duplication atm, i'm looking for names that reflect the semantic difference between those 2 kinds of processors
<snusnu>
mbj: thx!
<mbj>
snusnu: Me neighter (duplication)
<mbj>
lets wait a bit
<snusnu>
mbj: ducktrap clearly transforms its input, and thus needs to pass on result.ouput .. whereas vanguard *checks* the input, and needs to pass on request.input if it was successful
<mbj>
BTW it is really nice all that duplication got collapsed to this part.
<mbj>
snusnu: BTW I'd just return the input as output for vanguard, to it passes the input through
<mbj>
snusnu: If there is an error the output is the validation error.
<snusnu>
mbj: that's exactly what i'm talking about, that's the difference
<mbj>
snusnu: So lets remove the difference with modifying vanguard.
<snusnu>
mbj: hm, i thought about that too, but is it really right?
<mbj>
snusnu: I have a 36day strike of opensource activity... 3500 yearly commits.
<mbj>
snusnu: Yeah, vanguard returns the input, or an error object as output.
<snusnu>
mbj: i mean, those 2 processors just don't have the same semantics, it probably isn't right to collapse it into a single class?
<mbj>
snusnu: Ducktrap does the same!
<mbj>
snusnu: You decide, I'm not into the mental position.
<mbj>
snusnu: Waiting is okay, I dont fear to adjust anything in my code.
stormwind has quit [Ping timeout: 248 seconds]
<snusnu>
mbj: would you be fine with vanguard returning either the unaltered input in result.output, *OR* the violations? based on wether validation was successful or not?
<snusnu>
mbj: cause atm i can't think of another way to support the same api between ducktrap and vanguard
<snusnu>
mbj: and it smells somewhat fishy
<mbj>
snusnu: ducktrap does the same
<mbj>
snusnu: It returns an error object in Result#output
<mbj>
snusnu: if #success? is false
<mbj>
snusnu: Or the actual output if #succes? is true.
<snusnu>
mbj: right, ok, so we could change vanguard to do the same i guess
<mbj>
snusnu: It is okay for me, because it is binary and "central". Not an edge case we can forget.
<snusnu>
mbj: yeah
<mbj>
snusnu: BTW you push the #successful? => #success change?
<mbj>
snusnu: Can you add #successful? as an alias, with deprecation message?
<snusnu>
mbj: one moment (also, i only added alias_methods)
<snusnu>
mbj: no deprecation warnings currently, still fine?
stormwind has joined #rom-rb
<solnic>
snusnu: can I continue on the dsl? :)
<snusnu>
solnic: sure
<snusnu>
solnic: what's missing btw?
<solnic>
snusnu: moving stuff around :D
<snusnu>
solnic: feel free to do whatever :) i currently don't have time for it anyway
<mbj>
solnic, snusnu: I'm out, cu later.
<snusnu>
mbj: without pressure (but looking forward to it): could you check mutant's noop fails in the chain-dsl branch of subsstation?
<mbj>
snusnu: Can you ping me late, I still try to move home.
<snusnu>
mbj: no worries, will ping you later :)
<mbj>
snusnu: jo
<solnic>
snusnu: sure! I do consider it as almost done
<solnic>
just wanted to clean it up a bit and merge to master
<solnic>
there's one thing which puzzles me though
<solnic>
it builds axiom relations
<solnic>
but
<solnic>
repository/adapter build axiom relations too
<solnic>
snusnu: any thoughts on that?
mbj has quit [Ping timeout: 256 seconds]
<snusnu>
solnic: not really, i mean, when i wrote it, i did so by knowingly discounting anything that's already present
<snusnu>
solnic: i have this feeling that our current repository/adapter code needs to be somewhat rewritten anywa
<solnic>
snusnu: yes I had that feeling too :)
mbj has joined #rom-rb
postmodern has joined #rom-rb
<solnic>
snusnu: don't you think that schema should be built via env? it would inject repositories so that definition can use them to build relations?
<mbj>
solnic: Can you give me a brief overview what the role of the schema is?
<snusnu>
solnic: dunno, to me, schema feels very basic, so that other stuff builds on top of it
<solnic>
mbj: it defines all relations
<snusnu>
solnic: but my mind isn't deep into that shit atm
<solnic>
snusnu: gotcha
<solnic>
well, I thought schema is supposed to be used to define...well, schema
<solnic>
so that you don't have to do anything else
<solnic>
to get working env setup
<snusnu>
solnic: right, but it's so basic, it should be usable without anything ROM related
<solnic>
if it's meant to build "just" axiom relations then we're still missing stuff
<snusnu>
solnic: an env could be built using the schema, but not the other way round it seems
<solnic>
ok, so you want it to build the schema and then have something on top of it
<snusnu>
solnic: or maybe, both ways could be possible, dunno .. but it feels wrong to need a ROM env in order to build a schema
<solnic>
which basically goes through defined relations and builds gateways for established repositories?
<mbj>
solnic: Lets summarize it as "information_schema on the ruby side"?
<solnic>
mbj: yes this sounds right
<mbj>
solnic: okay. thx. sync.
<solnic>
no gateways, no adapters, just relations
<solnic>
snusnu: ok I think we're on the same page now
<solnic>
I'll finish it tomorrow
<snusnu>
solnic: great!
<solnic>
gotta run now
<solnic>
ttyl
djsell has quit [Read error: Connection reset by peer]
djsell1 has joined #rom-rb
<snusnu>
mbj: how can i check if a class inherits from another
<solnic>
snusnu: A < B?
<snusnu>
mbj: something i build with Class.new(Foo), how can i check its actually not a Foo class
<solnic>
just use < operator
<snusnu>
mbj: yeah, for some reason it doesn't work
<solnic>
ok going now for real ttyl
<solnic>
hey it's me not mbj :P
<solnic>
cya
solnic has quit [Quit: Leaving...]
<snusnu>
mbj:
<snusnu>
Failure/Error: it { should be < Chain::DSL }
<snusnu>
NoMethodError:
<snusnu>
undefined method `<' for #<#<Class:0x0000010291e508>:0x0000010291e1e8>
djsell1 has quit [Quit: Leaving.]
<mbj>
snusnu: kind_of
<mbj>
snusnu: nope
<mbj>
snusnu: I'll got to sleep now!
djsell has joined #rom-rb
<snusnu>
mbj: nope, doesn't work
<snusnu>
mbj: i'm gonna change locations, maybe you're still around then, if not, good night :)
snusnu has quit [Quit: Leaving.]
ptico has quit [Remote host closed the connection]
djsell has quit [Ping timeout: 252 seconds]
snusnu has joined #rom-rb
<snusnu>
mbj: i have no idea why it { should be < Chain::DSL } doesn't work when clearly "it" is a Class.new(Chain::DSL)
mbj has quit [Ping timeout: 264 seconds]
<snusnu>
mbj: says that the anonymous class doesn't respond to <