dkubb changed the topic of #datamapper to: Datamapper v1.2.0 | Mailing List: http://is.gd/aa9D | Logs: http://is.gd/qWAL7V | DataMapper 2 Renamed to ROM, see #rom-rb for development
northrup has joined #datamapper
jeremyevans has joined #datamapper
northrup has quit [Quit: northrup]
ckrailo has quit [Quit: Computer has gone to sleep.]
rsim has joined #datamapper
rsim has quit [Ping timeout: 240 seconds]
northrup has joined #datamapper
<dkubb>
!memo mbj I just tested the --warnings switch in rspec 2.14 in axiom-types. I've got a bunch of work to do to make it warnings safe.. ideally I would like for all my gems to run with warnings turned on
<Cinchy>
dkubb: Memo recorded for mbj.
northrup has quit [Quit: northrup]
northrup has joined #datamapper
zombor has quit [Remote host closed the connection]
zombor has joined #datamapper
zombor has quit [Remote host closed the connection]
zombor has joined #datamapper
zombor has joined #datamapper
zombor has quit [Ping timeout: 260 seconds]
zombor has joined #datamapper
zombor has quit [Ping timeout: 256 seconds]
rsim has joined #datamapper
rsim has quit [Ping timeout: 240 seconds]
\_pol has joined #datamapper
\_pol has quit [Remote host closed the connection]
<Cinchy>
mbj: [6h 18m 5s ago] <dkubb> I just tested the --warnings switch in rspec 2.14 in axiom-types. I've got a bunch of work to do to make it warnings safe.. ideally I would like for all my gems to run with warnings turned on
<mbj>
.
ckrailo has quit [Quit: Computer has gone to sleep.]
northrup has quit [Quit: northrup]
mbj has quit [Ping timeout: 276 seconds]
mbj has joined #datamapper
solnic has joined #datamapper
<mbj>
solnic: morning!
<mbj>
solnic: mutant has --fail-fast now.
<solnic>
mbj: morning
<solnic>
that's really cool
<mbj>
solnic: So we can finally push a stable mutant-guard
<mbj>
*guard-mutant
<mbj>
Together with the new strategy I think mutant can be adopted by many more teams.
<solnic>
the one with narrowing the scope?
<mbj>
The new strategy is the one with the selection by rspec description and inverse narrowing the scope, yeah.
<mbj>
Starting selection with most narrow scope, if found specs execute, else wide the scope, till executing equivalent of --rspec-unit.
<solnic>
that's realy awesome. cannot wait
<mbj>
So you have a very fine grained spec-layout <=> execution-time trade off.
<mbj>
And dont have to go into the extreme with optimizing leafes of the spec-tree :D
<solnic>
yeah that would be a maintenance nightmare
<mbj>
Also as a side effect the most low hanging performance fruit will be eaten :D
<solnic>
mbj: have you started working on the new strategy?
<mbj>
Nope, only planning.
<solnic>
gotcha
<mbj>
But it should be simple, I need to unburry some old gists for the rspec world preserving
<mbj>
I hope rspec was improved in the meantime.
graph has quit [Read error: Connection reset by peer]
rsim has joined #datamapper
graph has joined #datamapper
graph has quit [Ping timeout: 260 seconds]
zombor has joined #datamapper
mikecmpbll has joined #datamapper
zombor has quit [Remote host closed the connection]
rsim has quit [Quit: Leaving.]
<kpwz>
hey guys
<kpwz>
I'm looking into using eventmachine as part of a project I'm working on, but I'm curious what the situation is with using DM in such an app? There doesn't seem to be much info out there about that.
<mbj>
kpwz: ola
<kpwz>
I know ROM is the new hotness and all, but I think I'm going to still want to use DM for the meanwhile in this
<mbj>
kpwz: Eventmachine should also "manage" database interactions?
<mbj>
There was discussions about such a setup in the past, but I dont remember details.
<mbj>
You can search the logs and the mailinglist.
<kpwz>
well, the EM app will need to interact with the same datastore, and presumably in order to make sure EM doesn't end up blocking any database calls need to be done the right way
<kpwz>
ok, I'll take a look
<mbj>
Why do you need EM, I track it as "a pre 1.9 solution for efficient parallel IO".
<kpwz>
what would be a good alternative?
<kpwz>
I'm open to suggestions if there are other preferred ways of getting to the same end
<mbj>
I thought rubies 1.9 Thread is powerfull enough
<mbj>
There was the joke about a guy was aliasing SomeFancyName = Thread
<kpwz>
I've very little experience with threaded programming, so this is somewhat new to me
<kpwz>
I think about the most comparable experience I can say I have is with asynchronous callbacks in the browser JS domain
<mbj>
kpwz: So what is the "domain requirement" for increasing complexity?
<mbj>
My rule with threads is: Only use with a good reason.
<kpwz>
well, the app started off as more or less a simple web application, but it's become apparent that I'll need it to process stuff asynchronously, both on a timed basis, and as a result of events
<kpwz>
it's a gameserver, in effect, that will maintain the state of the game world, update things as time passes, schedule and run tasks as needed etc.
<kpwz>
that doesn't really fit well with a traditional web app architecture which is more about serving up responses to specific requests
<kpwz>
I obviously would like to share as much domain object logic between the two though, and since I'm already using DM, it would have to work with that
<mbj>
Interesting, never deald with that (gaming) omdain
<kpwz>
the event loop is more or less the standard model for games, apparently
<kpwz>
although they're becoming increasingly multithreaded for performance reasons
<mbj>
Your state is only in the database?
<kpwz>
ideally
<kpwz>
I'd been considering maybe going with a redis backend, but I don't know as that choice is necessarily that important
<kpwz>
are you at all familiar with EVE Online?
<mbj>
What about adding a "cron" process that calculates next event on a 1s basis and requests the event processing via issuing an http request against the normal stack?
<mbj>
conceptually, they use stackless python.
<kpwz>
well, the cron method is possible but it sounds a bit messy compared to having it all as a nice ruby app (but I could be assuming too much there)
<kpwz>
less to do with the architecture; more the game (EVE) — they have a skill training system which is time-derived
<mbj>
So you have one process calculating when next event happens, sleeps maybe (this is optimization) and than fire-and-for-get http request against your "normal" frontend.
<mbj>
I'm not talking about the unix cron, I'm talking about a poro, domain specific cron.
<mbj>
Yeah, your character improves while you are NOT gaming.
<kpwz>
exactly
<kpwz>
I have something similar in mind here, where it would effectively need to constantly ‘tick’, updating things every n ticks
<kpwz>
I suspect (I could be wrong?) that firing up a ruby process periodically would be too slow for that
<mbj>
Get my point, instead of doing all the crazyness with managing asynchronous actions, you have a "tick" process requesting http resources.
<mbj>
No that one would be persistend.
rsim has joined #datamapper
<mbj>
Dont looping events, looping event sources.
<kpwz>
so, you'd still have a persistent ruby process, but it'd be firing off requests to other applications via HTTP?
<mbj>
And instead of doing the work for itself, it *just* triggers one of your gazillions of workers waiting for http requests.
<mbj>
So no work "queues" up at the "ticker".
<kpwz>
that might work
<mbj>
A typical problem of such ticker processes is "what if a job takes longer than a typical tick".
<kpwz>
I guess the problem I have is I know I'm stepping out of my comfort zone here.
<mbj>
Work and ticks queue up.
<kpwz>
sure, but then that's the problem EM solves isn't it?
<mbj>
Yeah, I think celluloid is a better foundation for modelling this domain problem than EM.
<mbj>
kpwz: So my main idea is, Instead of duplicating moving state with a complex "ticker and ticker-specific-worker" setup. The ticker just pings http endpoints.
<mbj>
http-endpoints your app typically does not trigger. (Needs auth for sure)
<mbj>
So you "only" have to add that "ticker" process, and dont have to leave the comford zone.
<mbj>
Just do plain http request processing as always. But some http requests are from the ticker.
<kpwz>
it would certainly be architecturally simpler, but I'm not sure it'd necessarily be very efficient. HTTP requests have quite a bit of overhead.
<mbj>
I dont know the details.
<mbj>
You can also call directly in your domain if you have a good domain command abstraction.
<mbj>
But dont call from the ticker process.
<mbj>
Make sure the ticker process does minimum amount of work per tick.
<mbj>
So let me repeat it *sounds* not like a problem EM would helpfull for.
<mbj>
Ideally your game "enqueues" events at a specific date, and the ticker process can select the next event periodically.
<mbj>
So the ticker process does not scan your full domain for next events
<mbj>
But I might be ultra naive here :D
<kpwz>
well you're certainly giving me food for thought on different approaches
<kpwz>
my gut feeling though is that HTTP is just too slow
<mbj>
kpwz: Test it.
<mbj>
Your stack should already be prepared for massive parallel http handling?
<mbj>
So why dont reuse that achitecture?
<kpwz>
yeah…
<mbj>
http is only a thin layer *ideally*.
<mbj>
Also you dogfood your own work, this is generally a good idea.
<mbj>
If your http layer is to slow already, adding a fast event producer/consumer system does not help.
<kpwz>
well, that's fair enough
<kpwz>
I shall chew on it, maybe write something to test it out.
<mbj>
And you only have to "scale" one api!
<mbj>
the http one.
<mbj>
Adding an http worker, directly adds an event backend worker.
<mbj>
If there are more events than http request you reuse your resources.
<mbj>
*and vice versa.
<mbj>
Also I *love* it if all workers run the same code
<mbj>
And are capable of doing the same stuff. A single deployment.
<mbj>
So if you dont have a distinction between http or event worker you collapse complexity.
<mbj>
If you need to scale the ticker you can partition the event selection.
<mbj>
Or you can "lock" an event while beeing processed (should not scale that well).
<mbj>
kpwz: If you have a decision, pls tell me.
<mbj>
I like to think/solve/elaborate on such stuff.
<g0bl1n>
I have a string property for a model that marshals an array of values. It writes ok to the model. But how can I unmarshal it back to the property so that I can regain access to the array data ?
<g0bl1n>
DM 1.2
zombor has quit [Remote host closed the connection]
solnic has quit [Quit: Leaving...]
<g0bl1n>
done
snusnu has joined #datamapper
zombor has joined #datamapper
g0bl1n has quit [Ping timeout: 256 seconds]
brianpWins has joined #datamapper
mbj has joined #datamapper
_pol has quit [Remote host closed the connection]
dkubb has joined #datamapper
brianpWins has quit [Quit: brianpWins]
brianpWins has joined #datamapper
brianpWins has quit [Quit: brianpWins]
brianpWins has joined #datamapper
zombor has quit [Remote host closed the connection]
mbj has quit [Ping timeout: 240 seconds]
mbj has joined #datamapper
rsim has quit [Quit: Leaving.]
zombor has joined #datamapper
zombor has quit [Remote host closed the connection]
\_pol has joined #datamapper
\_pol is now known as _pol
_pol has left #datamapper [#datamapper]
postmodern has joined #datamapper
rsim has joined #datamapper
rsim has quit [Ping timeout: 240 seconds]
v0n has quit [Ping timeout: 260 seconds]
brianpWins has quit [Quit: brianpWins]
mbj has quit [Quit: leaving]
lnormous has quit [Read error: Operation timed out]
zombor has joined #datamapper
zombor has joined #datamapper
zombor has quit [Remote host closed the connection]