<solnic>
my thinking is that once you created an object and persisted it
<solnic>
you don't initialize it later
<solnic>
you retrieve its state from the db
<cored>
hi
<solnic>
so it should appear in the memory again w/o the need to call initialize
<solnic>
it kinda makes perfect sense to me
<solnic>
I do know that some people disagree :P
<snusnu>
solnic: hmm .. so it's kind of "philosophical"?
<solnic>
yes it is
<solnic>
cored: hi
<cored>
solnic: I need some direction with issue 173 for virtus
<snusnu>
solnic: in an immutable context, it probably doesn't make much sense?
<snusnu>
solnic: i see the reasoning behind it tho
<snusnu>
solnic: but i guess it's a matter of how you look at it
lorenzo__ has joined #rom-rb
<snusnu>
solnic: if you say, ok, previously, my process didn't know about an object, after fetching from db, it knows, hence, it initializes a new object
<snusnu>
solnic: i dunno, to me, #allocate has a somewhat mutable smell to me
<solnic>
snusnu: yeah we can have different strategies
lorenzo_ has quit [Ping timeout: 240 seconds]
<solnic>
cored: ok?
<solnic>
snusnu: if we want to support immutable objects then I do need to add different loading strategies NAU
<solnic>
that's ok, I'll be adding loaders so it'll be a good moment to do that
<cored>
solnic: oh I thought you were watching the comments on the issue
<theCrab>
solnic: just looking at devtools tasks. Rspec 2 changed the top namespace :rspec but devtools defines :spec for :unit and :integration. Am I missing something?
<cored>
the wrapping of header/attribute from axiom
lorenzo__ has quit [Ping timeout: 252 seconds]
<cored>
solnic: but the issue seems in the reading
<cored>
because I just set the attribute and it's blows up
<snusnu>
solnic: yeah, looks good so far, the direction is definitely right
lorenzo_ has joined #rom-rb
<snusnu>
solnic: one thing that comes to my mind, is that i think we should write the mapper in a way that it already expects grouped tuples
<snusnu>
solnic: and have that group/ungroup implemented in a dedicated object until axiom supports it
<snusnu>
solnic: basically that's code from dm-mapper's Relationship::Iterator::Tuples
<snusnu>
solnic: what i actually mean is this: when reading, it should delegate to the object that implements the #group and instantiate a properly nested model instance, and when dumping, it should delegate to the object that implements #dump and "explode" the grouped object to multiple tuples … that must be configurable tho, because not all backends need that expansion
<solnic>
it receives type with :writer => :private somehow
<solnic>
whereas it should be just { Integer => String }
<solnic>
so, something along the way merges those options incorrectly
lorenzo__ has joined #rom-rb
<solnic>
snusnu: yes I know, that's the plan
<snusnu>
solnic: sweet
<solnic>
I'm not going to do the mapping with prefixed names
<solnic>
we want to rely on grouping from the start
<snusnu>
absolutely
<snusnu>
re working on the in memory adapter/gateway .. i'd love to get that done asap, but i guess i won't find time today .. maybe on sunday, but monday might work good
lorenzo_ has quit [Ping timeout: 264 seconds]
<solnic>
snusnu: can I start then? you could join me when you have time
<snusnu>
solnic: of course dude :)
<cored>
solnic: on it
<snusnu>
solnic: i'm happy to discuss it with you .. i finally want to understand that bastard
<solnic>
snusnu: ok cool
<cored>
solnic: in fact I started from there the other night, but I will recheck
<solnic>
cored: it happens only with value objects?
<solnic>
cored: well ok so look at value_object.rb - it overrides .attribute method forcing writers to be private
<solnic>
it probably does it in an incorrect way
<solnic>
yeah this code is broken
<solnic>
it checks if last arg is a hash assuming it's OPTIONS
<solnic>
which can be TYPE
<solnic>
add a guard statement checking if args.size > 2 and last arg is option hash
<solnic>
cored: do you see this? :)
<solnic>
it's fairly simple
<solnic>
I need to go, lunch time here, I'll be back in 15 minutes or so
<cored>
solnic: yes
<cored>
will keep checking
lorenzo__ has quit [Read error: Operation timed out]
<snusnu>
theCrab: there's nothing special to using concord and devtools in a project
<snusnu>
theCrab: all that devtools does is give a set of rake tasks, a few shared specs targeted towards immutable objects, and a spec_helper that sets things up
<snusnu>
theCrab: include Concord.new(:foo, :bar) is equivalent to class C; include Equalizer.new(:foo, :bar); def initialize(foo, bar) @foo, @bar = foo, bar; end attr_reader :foo, :bar; protected :foo, :bar; end
<snusnu>
theCrab: the two libs are in no way related
<theCrab>
snusnu: am writing an app/lib that will hopefully be independent of an orm/framework. Just the business logic of the organisation.
<theCrab>
snusnu: ah cool.
Gibheer has quit [Read error: Connection reset by peer]
Gibheer has joined #rom-rb
mbj has joined #rom-rb
lorenzo_ has joined #rom-rb
<snusnu>
mbj: Loader#{call, identity} and Dumper#{call, identity} ftw
<mbj>
snusnu: Loader#{object,identity} are query methods in my example that dont take any args.
<snusnu>
mbj: so?
<mbj>
snusnu: Your loader takes an arg, the tuple and returns the object.
<mbj>
snusnu: This is to coarse grained IMHO
<mbj>
snusnu: The loader can respond to #call and return a "MappingState" object that supports #object and #identity
<snusnu>
mbj: oh, i haven't looked at the loader code yet, i just like the name #call better for both #object and #tuple
<mbj>
snusnu: Yeah, I'm only talking about the result of the load operation.
<mbj>
snusnu: It should feature #identity and #object
<mbj>
snusnu: how to construct this object, is "egal"
<mbj>
sorry english speakers listening. Did not found an english subsitution for that "egal" in time.
<mbj>
snusnu: I dont like that ducktrap DSO
<mbj>
snusnu: DSL
<snusnu>
substation?
<mbj>
snusnu: what does that authenticate method do?
<mbj>
snusnu: Why we have differend names?
<snusnu>
mbj: i want it so that an app (a client of substation) can register dsl handlers by name, so #authenticate Authenticator would register an authentication handler in the chain
<snusnu>
mbj: the actual chain handlers should be configurable by the clients
<snusnu>
mbj: substation would never provide those
<snusnu>
mbj: but it would allow you to register an authentication handler, and make it available with the #authenticate dsl method
<mbj>
snusnu: IMHO this is to much.
<snusnu>
mbj: i'd basically add a Chain::Builder object that supports registering different builders under a name, and then define methods with that name on some mutable Chain::Definition
<mbj>
snusnu: Becuase they all just add stuff to the chain
<snusnu>
mbj: the Chain::Definition then gets instance_eval'ed in the block passed to Chain.build
<mbj>
snusnu: authenticate Foo, is just like add Foo, sanitize Foo is add Foo
lorenzo__ has joined #rom-rb
<mbj>
snusnu: Why we need to complexify substaiton with a bunch of dsl methods that do the same
lorenzo_ has quit [Ping timeout: 252 seconds]
<snusnu>
mbj: i'm tired of all those repetitive calls to new, and i want to reuse authenticator and authorizer as they're the same for the whole app
<snusnu>
mbj: also, this could be a place to check wether the actual chain constructed is valid, i.e. it doesn't start with an outgoing handler, or doesn't register an incoming handler after an outgoing handler
<snusnu>
mbj: also, i don't see too much complexification for substation, all i need is a builder and a definition instance .. substation never knows about the "content", or the names .. they're up to the user
<mbj>
snusnu: I dont get it
<mbj>
snusnu: I know substation dos not know the dsl names
<mbj>
snusnu: But if I call Builder#authenticate or Builder#validate it just does the same.
<snusnu>
mbj: not really, i mean, it provides the same interface, but internally, obviously you do different things .. it's really a matter of taste i guess … i thing validate Validators::NEW_PERSON is more beautiful than Validator.new(Validators::NEW_PERSON)
<snusnu>
mbj: and as i said, most but not all of my actions need to authenticate and then authorize, some need no authorization step, and some need none of that … the authenticator and the authorizer are the same for all actions tho
<snusnu>
mbj: so i don't want to consistently add them in front of the chain, or even "nest" a chain that does that, i just want to build *on top of it*
<snusnu>
mbj: obviously, you would never have to use that dsl anyway
<mbj>
snusnu: Ahhh
<mbj>
snusnu: So you do validate Person, instead of add Validators::Person ?
<mbj>
snusnu: "validate Person" vs "add Validators::Person" ?
<snusnu>
mbj: not really, i don't do any namespace convention trickery
<snusnu>
mbj: validate Person vs. Validator.new(Person)
<snusnu>
mbj: imo naming the steps is more obvious than just appending to an array
<snusnu>
mbj: with step "description" being "hidden" in the handler name
<snusnu>
mbj: the block for #build gets instance eval'ed on a custom Definition instance that responds to instance methods defined by registering handlers you use in your app
<snusnu>
mbj: eventually i want to provide substation-stack which provides handlers for ducktrap, vanguard and maybe mustache
<elskwid>
cored: Fine by me. I can be a half-decent tourguide I think. I still don't know all the bits, but I'm getting a handle on it.
<solnic>
cored: huh? no, why? the api stays the same with my fix
<cored>
solnic: if I include ValueObject to my class
<cored>
isn't the attribute method that you change the first one the call hits?
<solnic>
the problem was that this code assumed last arg to be options when it was a hash, and it can be a hash when it's a Hash[Foo => Bar] (<= this gets coerced to a hash after all)
<cored>
I'm confunse
<solnic>
cored: this is really simple man :)
<solnic>
cored: attribute :foo, Hash[Integer => String] <== when you call this, then the arg number 2 becomes a hash instance
<solnic>
the prev value object attribute method assumed that if the last arg is a hash instance then it's OPTIONS and it added :writer => :private to it
<cored>
oh
<cored>
I see
<solnic>
which basically means :writer => :private was added to the second parameter representing TYPE
<cored>
[] -> is a builder?
<solnic>
Hash[] coerces input into a hash instance
<cored>
I see
<cored>
I did not see that implementation
<solnic>
awesome :)
<cored>
that's why I was kinda confuse
<cored>
I'm trying to write an spec for this either way
<cored>
I saw that you merge that with master
<solnic>
yeah it was a simple fix so I just pushed it
<cored>
I think it's ok to write an expect for the bug, what do you think?
<cored>
s/expect/spec
<solnic>
I tweaked unit spec so it blows up with prev implementation making sure I actually did fix the problenm
<solnic>
elskwid: the coolest thing to do is to integrate with axiom-types, this would simplify a lot of stuff :) but it's A HUGE refactor
<mbj>
elskwid: +1 for axiom-types!
<mbj>
elskwid: And to patch them into coercible with inverse support
<elskwid>
solnic: No refeactor is too big!
<mbj>
elskwid: I failed to do this in the short time I had while I tried the last time!
<elskwid>
(kidding)
<elskwid>
*refactor
<cored>
solnic: fair enough
<cored>
so I leave it like that
<cored>
elskwid: how can we do this?
<cored>
do you use vim?
<elskwid>
cored: I am actually an emacs user (fairly new) but we can figure something out. Even if we have to use Google Hangouts and just do pilot/co-pilot style is fine.
<elskwid>
Especially if all you want to do is discuss what's going on.
<solnic>
oh boy emacs and vim user pairing on stuff :D
<cored>
you can use any editor
<cored>
solnic: which means you are not an user of neither, right?
<elskwid>
mbj: I'm keen to understand that idea of the inverse coercions. solnic mentioned them the other day. I haven't been around but I assume you mean if I write a coercer that knows how to make a string a boolean that it also knows how to take that boolean back to a string.
<mbj>
elskwid: This would be the "perfect" interface for delegating all primitive coercions to ducktrap!
<mbj>
elskwid: If we can also make it strict such as: coercion = coercer.from(::String, :only_decimal_notation).to(::Integer), I'd be "ueber happy".
<mbj>
elskwid: So it would only accept decimal 123, but not hex input 0x10
<elskwid>
mbj: Do you have some time this weekend to talk about ideas on how to implement? I can see I'll need some guidance but I should be able to get started with only a little bit.
<elskwid>
I need to get started on "work" this morning.
<elskwid>
heh
<elskwid>
:(
<mbj>
elskwid: Feel free to ping me
<mbj>
elskwid: I had noumerous ideas that would *work*, but no not enough time to make them work.
<mbj>
elskwid: So I'd love to offload ;)
<elskwid>
mbj: And I'd love to help more!
<cored>
it's solnic just went away
<cored>
elskwid: and you are also leaving, for work, right?
<mbj>
elskwid: I apprechiate your help! A lot.
<solnic>
I'm here
<solnic>
just in another window ;)
<mbj>
elskwid: Building a whole ecosystem in this "rom-style" is a lot of efford.
<cored>
solnic: oh did you see the list of issues ?
<cored>
maybe you can point me on one that should be easy to solve
<elskwid>
cored: Just getting started (I work from home)
<solnic>
cored: ok lemme see :)
<cored>
elskwid: I see, yes I work also from home :-P
<cored>
elskwid: I'll be around for the pairing thing, meanwhile will try to work on another issue when solnic check the list
<solnic>
cored: #170 should be easy to fix
<solnic>
mbj: dude, I just pushed loader/dumper result objects eventually, can you take a look is that what session needs?
<solnic>
mbj: it's almost identical to mbj-mapper now
<solnic>
naming is a bit different
<cored>
solnic: checking
<solnic>
mbj: we still need to change rom-session a bit so it operates on rom's relations now instead of some "mappers"
<solnic>
it needs to get relation from a registry and build a new instance injecting the specialized mapper
<solnic>
mbj: so it seems like we could avoid db roundtrip if axiom had a way of injecting IM indexed with axiom keys
<solnic>
so that it can check it before firing a query and return already loaded object
<mbj>
solnic: sorry busy
<solnic>
np
<mbj>
solnic: Will check back later.
<solnic>
sure sure
<mbj>
solnic: But it "sounds" correct, if I open the code I'll get distracted again.
<solnic>
mbj: looks like my recent commit with result objects makes no sense given that session excepts identity/object/tuple to be lazy loaded
<mbj>
solnic: It does not expect this
<mbj>
solnic: rom-session plays well with both, lazy and non lazy load.
<solnic>
yes it does, you used memoize there
<solnic>
memoize == lazy
<mbj>
solnic: rom-session does not call #object if it finds object in identity_map
<solnic>
well yeah and that's the thing
<solnic>
it expects stuff to get returned when it asks for it
<mbj>
solnic: Where is the problem?
<solnic>
current code in rom-mapper doesn't work like that so I need to change it
<mbj>
solnic: I cannot check it now. Sorry.
<mbj>
I'll get distracted and fuckup my commercial stuff. (rom is interesting, this is a good sign)
<solnic>
mbj: no worries, just loud thinking here, I will make it work easily
<solnic>
mbj: pro tip: go offline
<mbj>
solnic: haha we had this already
<mbj>
solnic: I'm free to answer questions, the ones I can answer from cache
<solnic>
lol what a nerd-like response :)
<mbj>
solnic: With these I have control about my attention.
<solnic>
kk
<mbj>
But once I follow a cache miss, I get fucked.
zaidan has quit [Ping timeout: 240 seconds]
lorenzo_ has quit [Remote host closed the connection]
<solnic>
mbj, snusnu: I merged header/dumper/loader in
<mbj>
solnic: nice!
<solnic>
I'll tweak rom-session to make it work with rom-mapper
<solnic>
then I'll add various loading strategies, ideas how to do it are very much welcom
<solnic>
s/welcom/welcome/
<mbj>
solnic: Change what you need.
<mbj>
solnic: rom-session works pretty well for me, but I expect we'll have to refactor it a lot.
<mbj>
solnic: I expect we wrap the core of rom session inside a "statefull" mapper.
<postmodern>
mbj, is there a performance gain for freezing data?
<postmodern>
mbj, at least on MRI?
<mbj>
postmodern: Number of classes is significantly reduced in unparser
<postmodern>
mbj, I know Rubinius hates freeze
<dbussink>
freeze doesn't help performance wise anywhere afaik
<mbj>
postmodern: The high number of classes in to_source is a direct problem from RBX ast is not designed to be used for anything else than rbx bytecode emitting.
<mbj>
dbussink: Not to blame anyone!
<mbj>
dbussink: BTW would you accept a bytecode emitter based on the whitequark parser ast?
<dbussink>
mbj: well, given it would be as fast and as compatible as what we have now, we would likely seriously consider it
<dbussink>
but both those criteria have been the main reason the parser works the way it works now
<mbj>
I think I can make it compatible. But as fast, dunno.
<mbj>
I think the emitter is not the bottleneck, have to benchmak the whitequark parser under rbx before I invest wasted time.
<dbussink>
well, i know it's pretty poor atm because of racc
<dbussink>
but they accepted a patch from me on racc in mri, so hopefully the gem will be updated soon as well
<mbj>
nice
<mbj>
What exactly was slow in racc, I never benchmarked it?
<dbussink>
it was using RARRAY_PTR
<dbussink>
which is really slow in rbx because of the semantics of it
<dbussink>
having to rescan the array for objects having to go through the write barrier etc.
<mbj>
I thought it was pure ruby! I mixed up the pure ruby output of racc.
<dbussink>
well, the racc change made the parser gem tests run 10x faster
<dbussink>
on rbx
<dbussink>
but i haven't compared it with melbourne performance wise
<mbj>
Okay, but the generated parser is "pure ruby"
<mbj>
And this is the only thing to benchmark, if the build of rbx would be slower is not really an issue.
<dbussink>
how do you mean?
<dbussink>
well, the parser / byte code emitter are used for all ruby code compiling
<mbj>
dbussink: yeah
<dbussink>
so loading gems etc.
<mbj>
my point is: the library racc is only needed at compile time
<dbussink>
so that being slower would mean longer load times etc. that could be very significant
<mbj>
not at run time
<dbussink>
compile time of what? of the parser itself?
<mbj>
yeah
<dbussink>
ah ok
<dbussink>
well, to measure is to know basically :)
<mbj>
So if you speak about racc (the lib) uses RARRAY_PTR and speeded up the parser tests, it does not speak about the speed of the generated parser.
<mbj>
Because the parser tests obviousely build the parser ;)
<mbj>
I'll benchmark it in my spare time. Running it through rubinius/**/*.rb
<mbj>
via melbourne than via whitequark/parser
<mbj>
If there is a significant slowdown I'll not invest time.
<dbussink>
right
<dbussink>
well, even then it would be interesting to see how the rubinius jit performs on it
<mbj>
Yeah!
<mbj>
The generated file "looks" as a perfect target for a JIT.
<mbj>
But dunno if there is "JIT poison" inside the generated parser.