solnic changed the topic of #rom-rb to: Ruby Object Mapper | Mailing List: https://groups.google.com/forum/?fromgroups#!forum/rom-rb | Logs: http://irclog.whitequark.org/rom-rb
mbj has joined #rom-rb
gnoll110 has quit [Ping timeout: 252 seconds]
gnoll110 has joined #rom-rb
mbj has quit [Ping timeout: 246 seconds]
<gnoll110> Hi all
vsorlov has joined #rom-rb
vsorlov has quit [Ping timeout: 245 seconds]
<dkubb> gnoll110: hi
<gnoll110> hi dkubb
<gnoll110> just discovered dm has been renamed to rom. Looking around.
<dkubb> gnoll110: yeah, we decided that DM2 was going to be *so* much different from DM1 that it'd be confusing to keep the name the same
<dkubb> not just different code, but different from the ground up
<gnoll110> still keeping to the Fowler pattern?
<dkubb> yeah, well, actually following it this time :)
<dkubb> DM1 was basically an Active Record with some minor mapping thrown in
<gnoll110> Good
<dkubb> ROM is an actual Data Mapper, where the objects and persistence are managed by a mapper, but each of those pieces doesn't know about the other
<gnoll110> sinatra & dm got mentioned at a SIG I was at last month. rails/AR vs sinatra/md where made. Q&A show that most didn't realise their were patterns behind both AR & DM
<gnoll110> was thinking about a talk, with refs back to fowler patterns
<dkubb> oh interesting. I'm not sure if PoEAA is very well known. it should be. it's given me so many ideas beyond just the work I've done on DM/ROM
<gnoll110> and AR and MVC...
<dkubb> you were thinking about giving a talk about it?
<gnoll110> yes. But not nailed flag to mast yet
<dkubb> yeah, *so* much of what we do these days is influenced by fowler's patterns. I can still pick up the book, choose a random chapter on just about any topic in it and learn something
<dkubb> and I've probably read it a dozen times
<gnoll110> I did pick a ranbon chapter often enough. Truth be told I'd rather pick a randon pattern from Alexander :P
<dkubb> Christopher Alexander? or someone else?
<gnoll110> your observation about ROM being closer to DM patten WILL be included. Starting point will be Fowler cheat sheet from back of PoEAA. Yer Christopher Alexander, have 8 of his books so far.
<dkubb> much of the inspiration for ROM is coming from Python's SQL Alchemy
<dkubb> there's an awesome chapter about it's design here: http://www.aosabook.org/en/sqlalchemy.html
<dkubb> I'm reading through the paperback verison of that book and it's pretty awesome
<gnoll110> << COBOL programmer who self lernt Java then Ruby. Not done any Python
<dkubb> some of the things that make ROM stand out are: at it's core, there's something called Axiom which is a relational algebra library. it's similar in concept to what ARel 1 was, but diverges greatly from ARel 2 which is basically just an SQL generator.. Axiom attempts to provide a database API as powerful as SQL, but more consistent
<gnoll110> paperback of what book?
<dkubb> http://aosabook.org/en/index.html (v2 specifically)
<dkubb> I haven't read v1 yet, but I think I'll get it once I finish with this one
<dkubb> actually v1 and v2 aren't good designators.. it's more like book 1 and book 2
<dkubb> book 2 is the one with the SQL Alchemy details
<gnoll110> thank for lead. LOL thought SQL Alchemy was a language module ;)
<dkubb> ahh heh
<dkubb> it's probably one of the more popular Python ORMs. I'm not sure if it's #1 or #2 behind the one included in Django
<gnoll110> ok
<gnoll110> I'm also about to start of a project, want to use sinatra and rom. Any skels & example anywhere you know of?
<dkubb> I should warn you that ROM is still in development, it may only be useful for playing around with
<dkubb> I don't know of any skeleton sinatra projects using ROM
<gnoll110> cool, will start with sinatra/dm and change over laster then
<dkubb> sure
<gnoll110> I'm head off now. Do want to start the business logic of this project, even if I don't have a sinatra dir structure yet
<gnoll110> ... today
<dkubb> k, ttyl
<gnoll110> cya
dkubb has quit [Quit: Linkinus - http://linkinus.com]
dkubb has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu1 has quit [Ping timeout: 264 seconds]
zekefast has joined #rom-rb
travis-ci has joined #rom-rb
<travis-ci> [travis-ci] dkubb/memoizable#58 (master - c77b8ab : Dan Kubb): The build was broken.
<travis-ci> [travis-ci] Build details : http://travis-ci.org/dkubb/memoizable/builds/14758623
travis-ci has left #rom-rb [#rom-rb]
<gnoll110> opps
gnoll110 has quit [Ping timeout: 252 seconds]
gnoll110 has joined #rom-rb
mbj has joined #rom-rb
gnoll110 has quit [Ping timeout: 252 seconds]
gnoll110 has joined #rom-rb
mbj has quit [Ping timeout: 240 seconds]
mbj has joined #rom-rb
<mbj> dkubb: hi
<mbj> dkubb: I have multiple libs out there that do:
<mbj> def lookup(object)
<mbj> current = target = object.class
<mbj> while(current != Object)
<mbj> handler = registry[current]
<mbj> return handler if handler
<mbj> current = current.superclass
<mbj> end
<mbj> raise "No handler registred for: #{target}"
<mbj> end
<mbj> # Disclamer: This is just a sketch, but you get the idea.
<mbj> So it looks up a handler for a given objects class, while walking up the superclass chain.
<mbj> I'd love to "centralize" this in a type lookup gem, I think you also have something like this in axiom-types?
<mbj> Than we could also add explicit caching of lookup results and DRY up axiom, morpher, mutant, ...
<mbj> I use this type lookup stuff for mutant reporters, and for morpher pretty print.
<mbj> Not to solve the acutal domain problems in morpher / mutant. Just for reporting.
kleech has joined #rom-rb
zekefast has quit [Ping timeout: 272 seconds]
zekefast has joined #rom-rb
vsorlov has joined #rom-rb
zekefast has quit [Ping timeout: 240 seconds]
zekefast has joined #rom-rb
gnoll110 has quit [Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/]
kleech has quit [Remote host closed the connection]
mbj has quit [Ping timeout: 246 seconds]
mbj has joined #rom-rb
zekefast has quit [Quit: Leaving.]
vsorlov has quit [Read error: Connection reset by peer]
vsorlov has joined #rom-rb
vsorlov has quit [Ping timeout: 245 seconds]
vsorlov has joined #rom-rb
zekefast has joined #rom-rb
jgaskins has joined #rom-rb
snusnu has joined #rom-rb
<mbj> snusnu: hi
<mbj> snusnu: you should be very happy to see mbj/morpher arriving in the public ;)
<mbj> snusnu: Split it from ducktrap some min ago.
<mbj> snusnu: Also working heavily on mutation cover my morpher spike.
<mbj> snusnu: The *core* features of ducktrap are already working.
<mbj> snusnu: Apart from singalling in tracking mode.
<mbj> snusnu: *signalling transform abort
<mbj> snusnu: Once mbj/morpher is 100% mutation covered I'll release 0.1. And use that 0.1 release to implement filters in mutant.
<mbj> snusnu: This will allow me to support the "kill expression" feature I was talking about. So you can add as many "kill rules" you want to mutant.
<mbj> snusnu: For example solnic can go implicit coverage, dkubb/me can do explicit, and you can do whatever mixture you like ;)
<mbj> snusnu: Also the kill expressions will allow to use domain specific test selection strategies.
<mbj> snusnu: Unparser would be very uneasy to mutation covered via the explicit pattern.
<mbj> snusnu: But writing a 20loc dispatch scrip to select from these (https://github.com/mbj/unparser/blob/master/spec/unit/unparser_spec.rb) will allow "minimal tests set selection"
<mbj> snusnu: that dispatch script will use the kill expressions from above.
<mbj> snusnu: I expect we'll have a config/mutant.rb with some DSL.
mbj has quit [Ping timeout: 246 seconds]
lgierth has joined #rom-rb
snusnu has quit [Quit: Leaving.]
jgaskins has quit [Quit: Leaving]
snusnu1 has joined #rom-rb
kleech has joined #rom-rb
mbj has joined #rom-rb
<dkubb> mbj: how do I add memoizable and thread_safe to mutant so they are zombified?
<dkubb> mbj: I'm unclear on how mutant figures out they need to be zombified
<dkubb> *how they
mbj_ has joined #rom-rb
kleech has quit [Remote host closed the connection]
<mbj> dkubb: Mutant implements a very simple interpreter for zombification.
<mbj> dkubb: It picks up all transitive reachable requires from lib/mutant.rb
<mbj> dkubb: But only the requires that are done via literals as children of the top level node after parsing.
<mbj> dkubb: Mutant can also only zombify sources that are in the $LOAD_PATH as .rb files. C exts canot be zombified.
<mbj> dkubb: So theoretically thread_safe (given it is pure ruby) and memoizable should be piched up automagically.
<mbj> dkubb: *picket
<mbj> dkubb: That "simple" interpreter was a "ad-hoc" thing, if there is lots of room for improvement: https://github.com/mbj/mutant/blob/master/lib/mutant/zombifier.rb
<mbj_> test
mbj_ has quit [Quit: leaving]
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
zekefast has quit [Quit: Leaving.]
snusnu1 has quit [Quit: Leaving.]
mbj has quit [Ping timeout: 245 seconds]
snusnu has joined #rom-rb
mbj has joined #rom-rb
lgierth has quit [Quit: Ex-Chat]
jgaskins has joined #rom-rb
zekefast has joined #rom-rb
vsorlov has quit [Ping timeout: 246 seconds]
lfox has joined #rom-rb
mbj has quit [Ping timeout: 252 seconds]
zekefast has quit [Ping timeout: 246 seconds]
zekefast has joined #rom-rb
jgaskins has quit [Quit: This computer has gone to sleep]
lgierth has joined #rom-rb
lfox has quit [Quit: ZZZzzz…]
lfox has joined #rom-rb
<dkubb> lgierth: what does promise.rb do?
<dkubb> lgierth: I saw that you just submitted it to mutant as 100% covered
<lgierth> right, would be good to have at least a bit of documentation :]
<lgierth> it's an implementation of promises/a+
<dkubb> ahh ok, it's what I assumed
<lgierth> it came out of my frustration with EventMachine::Deferrable and EM::Synchrony
zekefast has quit [Quit: Leaving.]
jgaskins has joined #rom-rb
lfox has quit [Quit: ZZZzzz…]