<postmodern>
snusnu, doesn't < only work on Classes/Modules, not instances?
<postmodern>
snusnu, maybe its(:class) { ... }
<snusnu>
postmodern: thx for picking that up! (un)fortunately it was just me being dumb, trying it on an instances although i was completely sure i was trying on a class ;)
<snusnu>
postmodern: so yeah, of course it behaves just as you said
<postmodern>
also should be_kind_of
<snusnu>
yeah, iirc i ended up using that .. it's just that i was *so sure* that i'm dealing with a class, and only later noticed that i was looking at an instance method spec file heh
<snusnu>
tricky when objects have equally named instance and class level methods
djsell has quit [Ping timeout: 248 seconds]
snusnu has quit [Quit: Leaving.]
mbj has joined #rom-rb
mbj has quit [Ping timeout: 275 seconds]
mbj has joined #rom-rb
splattael has joined #rom-rb
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
snusnu has joined #rom-rb
solnic has joined #rom-rb
zekefast has joined #rom-rb
<solnic>
snusnu: ping
ptico has joined #rom-rb
postmodern has quit [Quit: Leaving]
<mbj>
solnic: hola
<mbj>
solnic: Dealing with maven :D
<solnic>
mbj: hey :)
<solnic>
mbj: maven? why?
mbj has quit [Read error: Connection reset by peer]
mbj has joined #rom-rb
<solnic>
mbj: geez we need to standardize gateway
knowtheory has quit [Quit: Computer has gone to sleep]
knowtheory has joined #rom-rb
<solnic>
mbj: I'm experimenting with in-memory adapter
<solnic>
mbj: not sure if it's a right approach but...the gateway could simply intercept materialize and update data in the adapter's in-memory store...wdyt?
knowtheory has quit [Ping timeout: 264 seconds]
<mbj>
solnic: haha, yeah standard gateway would be awesome!
<solnic>
mbj: ok I must admit I'm kinda stuck with this memory adapter
<mbj>
solnic: I'd love to help, but I'm busy.
<solnic>
mbj: no worries
cored has joined #rom-rb
cored has quit [Quit: leaving]
cored has joined #rom-rb
<solnic>
mbj: why including equalizer causes inclusion of adamantium?
<mbj>
solnic: So you *pass* the relation to the adapter
<solnic>
mbj: yeah I do
<mbj>
solnic: And you'd have to filter the relation there
<mbj>
solnic: But if your relation was created with the correct data you just could use each on the relation.
<solnic>
yes that's the missing part
<dkubb>
hmm, I don't know if I've designed the #create, #update and #delete interfaces on the adapter yet
<solnic>
dkubb: we'll get to that in a minute ;)
<mbj>
solnic, dkubb: I cannot spend my full attention, sorry. Will come back later to this.
<solnic>
mbj: ok ok
<mbj>
Just waste your and my time with not spending full attention on any task.
<dkubb>
solnic: tbh I was probably going to use the same adapter interface as DM1's adapters
<solnic>
I think the trick here is to carry the data in gateway instances
<solnic>
dkubb: wdyt about that inmemory stuff I pushed today? it's broken
<solnic>
but
<solnic>
I need help so I pushed
<solnic>
to show you the code
<snusnu>
solnic: you could keep the data in the adapter, initialize base relations with the tuples stored in the adapter, and then "intercept" #insert #delete on the gateway, guarding it with relations.is_a?(Base::Relation)
<snusnu>
dkubb: hey, comments on that very welcome :)
<dkubb>
would it help at all if I pushed the gateway from axiom-do-adapter into axiom or into an axiom-abstract-adapter ?
<snusnu>
dkubb: yes it would
<solnic>
oh yes
<solnic>
definitely
<solnic>
snusnu: yeah, I started with adapter having data hash
<solnic>
snusnu: but now I need to keep track on the relation name (which is used as they key in that data hash)
splattael has quit [Quit: Leaving.]
<snusnu>
solnic: the key thing seems to be intercepting at the gateway level, but only for base relations (as everything "trickles down" to them)
<solnic>
which gets screwed up once relation becomes sth else, like a restriction or sth
<snusnu>
so you could always check if the proxied relation is a base relation, and if so, intercept the insert, inserting the tuples into the base relation exposed by the adapter
<snusnu>
and then, make sure to actually call "the real thing" too
<solnic>
snusnu: rite, and what about queries? :)
<solnic>
let's say you do a restriction
<solnic>
so gateway's relation is now a restriction
<solnic>
you have access to all the data via adapter
<mbj>
dkubb: The shared gateway should have some kind of a state machine, that controls push-down vs wrap
<snusnu>
solnic: right, inserts always must apply to base relations tho, eventually
<solnic>
and you want to restrict that data using the restricted relation
<mbj>
dkubb: You can initialize it with an adapter, and the adapter returns the "state machine" suitable for making sure only valid relation trees can be pushed.
<mbj>
dkubb: For example you cannot do restriction(sort(restriction)) in mongo
<mbj>
dkubb: Or restriction(sort(offset()))
<mbj>
dkubb: So we can start with a "pushes all stuff apart cross repo joins down" gateway, but we need to make sure we can inject that "can push down or cannot push down" logic.
<dkubb>
mbj: maybe the gateway should ask the adapter what it can handle?
<mbj>
dkubb: the adapter would have to walk the relation tree
<mbj>
dkubb: To the root!
<snusnu>
solnic: do you know what i am saying?
<snusnu>
:p
<solnic>
snusnu: yeah I get the insert/update/delete part
<solnic>
my problem is with reads right now
<solnic>
can't wrap my head around that
<snusnu>
solnic: all relations you operate on will be created from an adapter, and get initialized with the tuples, i guess nothing special is needed for read?
<snusnu>
solnic: also, all data eventually comes from base relations, which you get from the adapter
<solnic>
so, you're saying adapter should return base relations with tuples inside
<solnic>
it currently returns just tuples
<snusnu>
solnic: well, no, lol .. i see the problem
<solnic>
you DO? awesome? :D
<snusnu>
well, no, lol .. damnit, i'm confused, this always happens with that topic
<dkubb>
mbj: you start off with a base relation wrapped in a gateway. each operation applied on the gateway could decide to push-down or not based on the capabilities of the adapter
<solnic>
it is a little bit confusing
<snusnu>
my concern now was that we can't always materialze the complete relation of course
<dkubb>
maybe it would help if I wrote the first version of the in-memory adapter as a reference :)
<snusnu>
dkubb: pretty please! :)
<dkubb>
we have all the pieces for that at least
<snusnu>
it would be SO awesome to have full in memory support
<snusnu>
i would switch our app to ROM immediately
<solnic>
yeah it would
<dkubb>
yeah, then at least ROM can proceed with something usable
<solnic>
yes it's blocking release now
<solnic>
if we can have it at least partially done
<solnic>
we could push it
<solnic>
it'd be a great starting point for others
<dkubb>
it'd be nice for integration tests too, since it'll be fast
<snusnu>
dkubb: i would actually say it's even more important than sql generation
<solnic>
me too
<dkubb>
ok
<solnic>
we could work on so many other things if in-memory adapter is done
<solnic>
like session for example
<solnic>
also other people could jump in and start working on their adapters
<dkubb>
so the main thing is you need create, update, and delete methods added to the adapter, and a gateway that wraps this?
<solnic>
dkubb: yes, I added a dummy #insert
<solnic>
but it assumes integer is the key
<solnic>
READ would be nice too :D
<solnic>
if you could set some foundation for this, I could finish it
<solnic>
i'm very confused right now, it's hard to wrap my head around this
<solnic>
I mean, I know how it should work, but I have no clue how to make it work haha
<snusnu>
solnic: that's exactly how i feel about it too :)
<solnic>
looking at other adapters doesn't help since they have a real database under the hood
<dkubb>
it's ok, I had assumed I would do it because I've already wrapped my head around how it should all work. once we have a few example adapters it'll get way easier
<snusnu>
there's another argument pro in-memory adapter now, while developing an app, you really don't care wether the data actually is persistent, you want to develop the app
<dkubb>
some of the questions like pushdown are still open, but that won't be an issue with the in-memory stuff
<solnic>
dkubb: <3<3<3
<dkubb>
since every operation is already supported
<solnic>
with a well defined way of writing an adapter we should see a ton of adapters from other people
<solnic>
but this has to become simpler and more obvious
<solnic>
otherwise ppl will be as confused as me and Martin are now :D
<dkubb>
snusnu: yeah, when I worked on the DO adapter I also worked really hard to make sure the in-memory relations worked the same as the DO adapter; I literally ran 10's of millions of tests to ensure it was the same. that means people should be confident that if they get their app running with an in-memory adapter it can be swapped out later
<dkubb>
a few finished examples are needed I think
<solnic>
dkubb: that's how I advertise ROM to people btw, good to know about those 10's of millions of tests heh
<dkubb>
I can do an in-memory one, and if someone wants to take over the SQL gen I can work on the do adapter after that
<dkubb>
solnic: why don't we trade.. I'll do the in-memory adapter and you can do some SQL gen stuff?
<solnic>
dkubb: sure
<solnic>
dkubb: I was going to suggest that
<dkubb>
solnic: we also have some nice fuzzer stuff that mbj wrote
<dkubb>
I ran the fuzzer so many times. sometimes for days at a time. it would stop when it found a bug, and I would fix it, and re-run it
<dkubb>
I think I repeated that over a few weeks until I could basically let it run for 10m+ iterations with no errors
<solnic>
nice
<dkubb>
we can do the same thing with this adapter.. although mbj's is more advanced than what I wrote
<dkubb>
it's mostly for reads, but I'm guessing we can probably make one that does writes too
<dkubb>
er rather extend this for writes
<solnic>
yeah this stuff will make us feel much more confident about the adapters
<solnic>
it's pretty awesome I must say
<snusnu>
dkubb: yeah, that's what i was thinking, the nice thing with axiom backed ROM is that once your app works with the in memory adapter, you can be 100% sure it'll work on sql or whatever else too, which is almost unbelievably awesome .)
<dkubb>
when writing an adapter I see this as kind of symbiotic. you write the adapter and get it working the best you can with your tests, then you fuzz it and fix the bugs. then you try to extend the fuzzer to find more problems.. and keep bouncing back and forth between the fuzzer and adapter until you are confident
<dkubb>
if we do that for every adapter, after a couple of them we'll have a bullet proof framework
<dkubb>
then people writing new adapters have this kind of system that can lead them through the process of finding and fixing bugs. they'll have sample adapters to use as reference
<solnic>
snusnu: +1
<solnic>
snusnu: I was just writing the very same thing, but deleted it since you were first lol
<snusnu>
hah
<solnic>
dkubb: yes this sounds great
<solnic>
so, let's do this :D
<cored>
mornng all
<cored>
solnic: did you see the pull request?
<dkubb>
combing fuzzing with mutation testing once mbj's new mutant is ready should be sweet too
<solnic>
cored: which one?
<solnic>
cored: oh and morning
<cored>
solnic: the common module
<cored>
solnic: :-P I rename it to ConstMissingExtensions
<cored>
don't know if it's better or worst
<solnic>
cored: awesome, merging
<cored>
neat
<cored>
checking the issues
<solnic>
cored: actually no
<solnic>
cored: build is broken :) can you take a look?
<cored>
solnic: checking
<dkubb>
mbj: btw, github now supports repository renaming with redirects. so you could redirect aequitas to vangaurd
<mbj>
dkubb: thx, my problem is the vanguard is not related to aequitas in any way. It is 99.95% my code.
<mbj>
solnic, snusnu, dkubb Was on phone the last min and still busy. Will catch up later.
<mbj>
dkubb: My idea is to have *one* gateway to rule all adapters. So we inject adapter specific push down or push not behavior with some kind of a control object.
<dkubb>
mbj: I'll probably do this after an in-memory adapter though, since I won't need it for that, but we will need it for other adapters
zekefast has quit [Read error: Operation timed out]
<mbj>
dkubb: Maybe we can make this control object to return a new state each call.
<mbj>
dkubb: So if you "branch" a relation tree (reuse a root twice) you dont get extra work, or race conditions when sharing between threads.
<mbj>
dkubb: state = state.advance(new_relation); and deal with state.relation
<mbj>
dkubb: not well thought, but I'd like it.
<cored>
solnic: checking
<dkubb>
mbj: yeah, I'll think about how to do it. chances are whatever I do will have me telling the object to return a new relation/gateway based on some inputs, rather than asking it which kind of object to create and then doing the work in the gateway
<dkubb>
mbj: that way the adapter specific object can do whatever it needs to do, and the gateway is just a dumb container for the adapter and relation
<mbj>
dkubb: Yeah, but it should also return a new "decider" object.
<mbj>
dkubb: so we have a nice state machine :D
<dkubb>
mbj: if it creates a gateway it can always inject a new "decider" object
<mbj>
solnic: Tuple; def dispatch; write("(");v visit_delimited(children); write(")"); end
<solnic>
mbj: now that's kinda enlightening :)
<mbj>
solnic: Tuple is a composition of primitives.
<mbj>
solnic: That stuff is SUPER easy.
<solnic>
hey I know
<solnic>
but you need some level of knowledge
<solnic>
to do it
<mbj>
solnic: If we'd have money already to distribute, I'd say: Give me 1 working day and I'm through.
<solnic>
mbj: working on that :P
<mbj>
solnic: yeah, enough sql we need.
<mbj>
solnic: This is the 4th time I write emitters
<mbj>
It becomes kinda boring :D
<snusnu>
guess what, and i ***totally not want to bitch about it*** .. but somehow, just somehow .. money changes oss dynamics :p … i'm *fine* with that change, as the oss we do, is directly beneficial for companies … but yeah, it changes dynamics ...
<mbj>
solnic: You can reuse the tuple thing for selects like "SELECT (1 as integer, 2 as float)"
<mbj>
solnic: That thing in () is also a tuple...
Gibheer has quit [*.net *.split]
Gibheer has joined #rom-rb
<solnic>
snusnu: I know what you mean
<mbj>
snusnu: It is differend when you have a child, trust me.
<solnic>
mbj: +1
<snusnu>
mbj: child or not, it also changes for me, and i have no child :)
<snusnu>
mbj: but i DO KNOW what you mean
<snusnu>
believe me
<snusnu>
and i understand
<mbj>
snusnu: Before my child I could spend *hours* workgin on such stuff. But now I have to take care I dont fuck up clients.
<mbj>
Before it was possible to backpack russia for month.
<mbj>
Before I just said: Hey cool, lets do a 250km bike ride, start in 10min?
<snusnu>
mbj: as i said, i'm fully aware, and i'm not bitching at all, it's just an observation, and tbh, one that doesn't surprise me … in fact, show me ONE THING, where money doesn't change the dynamics behind it
<mbj>
Sure :D, I know you are not bitching!
<snusnu>
:)
<mbj>
snusnu: The problem isnt money by itself, it is the regular demand for money.
<snusnu>
which boils down to, well, money
<snusnu>
lol
<solnic>
:)
<mbj>
It is more the regular aspect IMHO.
<mbj>
I need "value" to exchange, and that each month.
<mbj>
No interruption allowed, or I'll run into a backlog.
<mbj>
I'd be totally happy if OSS funding is just: "Hey guy, I pay your bills, make the project happy, you have 6 month".
<snusnu>
if it weren't for money, you wouldn't need money regularly .. but i guess now i am starting the bitching ;)
<mbj>
haha
<mbj>
GF is calling, I wanted to be home 20:00
<snusnu>
hehe
<mbj>
so have to run, cu laters.
<snusnu>
have fun
<snusnu>
mbj: btw, could you tell me how to run mutant master?
<snusnu>
mbj: i tried it for substation, and yeah, it picked up nothing …