skade has quit [Read error: Connection reset by peer]
skade has joined #rom-rb
skade has quit [Read error: Connection reset by peer]
mbj has quit [Ping timeout: 240 seconds]
mbj has joined #rom-rb
skade has joined #rom-rb
snusnu has joined #rom-rb
snusnu has quit [Client Quit]
skade has quit [Quit: Computer has gone to sleep.]
rikai has quit [Ping timeout: 240 seconds]
rikai has joined #rom-rb
rikai has joined #rom-rb
rikai has quit [Changing host]
rikai has quit [Read error: Connection reset by peer]
rikai has joined #rom-rb
rikai has quit [Changing host]
rikai has joined #rom-rb
mbj has quit [Ping timeout: 264 seconds]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
avdi has quit [Ping timeout: 245 seconds]
skade has joined #rom-rb
postmodern has joined #rom-rb
solnic has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
avdi has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
skade has quit [Ping timeout: 265 seconds]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
postmodern has quit [Quit: Leaving]
skade has joined #rom-rb
mbj has joined #rom-rb
<mbj>
solnic: seems you have some fun with morpher ;)
<solnic>
mbj: yeah, it worked flawlessly
<solnic>
mbj: I was only a little confused about domain::param, I build it now explicitly using class interface
<solnic>
are you planning to add an emitter for this thing?
<mbj>
solnic: yeah
<mbj>
solnic: We'll have an AST node compiling to a Transformer::Domain::Param instance
<mbj>
solnic: I simply did not have the time yesterday to add this one.
<mbj>
s(:domain, Foo, [ :list, :of, :ivars])
<mbj>
Thats the first idea.
<mbj>
It'll probably clean up once I write it down.
<solnic>
mbj: that's what I thought
<solnic>
I could try adding it if you don't have time
<mbj>
solnic: And yes I the object interface is the only interface you can "currently" use.
<mbj>
solnic: I'll add a special node that allows you to place a "precompiled" evaluator into an ast.
<solnic>
but first I want to add support for wrap/unwrap via morpher
<mbj>
solnic: should be really easy
<mbj>
solnic: We probably have to add some nodes that deal with Axiom::Tuples
<solnic>
so far it just works
<mbj>
cool
<solnic>
why do you think we're gonna need something special?
<mbj>
I think we can have an optimizer that collapses generic morpher nodes like a pair of axiom tuple to domain objects with null transformations in between into a very easy node.
<mbj>
But thats later.
<mbj>
solnic: BTW that rspec style you critized allowed me to get full mutaiton coverage for the new loaders / dumpers very fast.
<solnic>
I would still vote for simplifying that huge shared examples file
<solnic>
it is really complex man, can't argue with that I think
<solnic>
but I agree that it does speed up development
<mbj>
solnic: haha
<mbj>
solnic: I'd never keep the file as is.
<solnic>
btw I started adding those domain loaders already yesterday, didn't know you're gonna tackle it
<solnic>
so I already had ivar thingie locally done :)
<solnic>
mbj: this weekend is full of awesome. amazing progress with morpher, integration in rom, microrb.com goes live, sweeeet
<mbj>
solnic: heh, you sound motivated ;)
<solnic>
yeah
<solnic>
but tired, so, good night :)
<mbj>
solnic: ttyl
snusnu has joined #rom-rb
<snusnu>
hey guys
mbj has quit [Read error: Connection reset by peer]
<snusnu>
mbj, solnic: ping
mbj has joined #rom-rb
<snusnu>
mbj: yo
<mbj>
snusnu: hi
<mbj>
snusnu: my machine just rebooted, forgot the plug ;)
<mbj>
snusnu: We did some progress on the morpher front.
<snusnu>
mbj, solnic: i have a working implementation of a mapper with morpher :p
<snusnu>
gimme a sec, i'll show you what it can do
<lgierth>
ohai, while somebody's here: i've been working on non-ruby things for some time, so i'm flying under radar at the moment when it comes to httpkit, devtools, and mutant
<mbj>
lgierth: I dont have the time now. But I'll come back later.
<lgierth>
sure, cool
<snusnu>
i just have it hidden in my subway repo, will update it from morpher 0.1.0 to 0.2.0 in a few minutes, and push it
<snusnu>
serious shit ...
<snusnu>
:p
<mbj>
snusnu: k
<mbj>
snusnu: I got some serious advances in morpher internals
<snusnu>
i've seen them, very nice
<mbj>
snusnu: I really like the new flow.
<snusnu>
my stuff works with 0.1.0 already, just need a few minor fixes for 0.2.0
<mbj>
Target 0.3 please ;)
<snusnu>
i target master
<snusnu>
i use this stuff in our app
<snusnu>
:p
<mbj>
snusnu: Dont target master, I do shifted semver releases.
<mbj>
snusnu: master can break any time.
<snusnu>
mbj: that's alright
<snusnu>
i don't bundle update every day ,)
<mbj>
hah
<snusnu>
mbj: tell me tho, wdyt of the api?
<mbj>
snusnu: Seems you actually like morpher ;)
<mbj>
snusnu: Still reading, you know I'm bad in evaluating DSLs. Because I'm a bad DSL user.
<mbj>
s/user/author/
<snusnu>
no worries dude, there's little dsl anyway, it's mainly about generating models, morphers and mappers (encapsulated by entities) from the simple dsl with infinitely nestable wrap/group
<snusnu>
there's also 2 ways to wrap/group .. one, which references another registered entity, and another, which generates an "anonymous" entitly "inline"
<snusnu>
i currently use this stuff to do the parameter mapping, thus, for all of my transient entities
<mbj>
yeah
<mbj>
Using it for parameter mapping is a really good use case.
<mbj>
I'm still planning to reject extra keys in a hash.
<snusnu>
the nice thing is, it finally puts the model definition where it belongs imo, *outside* of an actual entity
<mbj>
But this will be an optional node.
<mbj>
!
<snusnu>
yeah, rejecting extra keys sounds feasible
<snusnu>
mbj: btw, there's no real way to make s(:merge, …) inversible, right?
<mbj>
snusnu: I had some ideas. But I'm to undersugared to remember.
<snusnu>
mbj: it boils down to comparing merge params with original input
<snusnu>
i think
<snusnu>
the thing with current irreversible :merge is, that it makes it impossible to define mappers with default values
<mbj>
snusnu: You could just remove the merged in params, in case the input is the merged value.
<snusnu>
yeah, and if it's different, leave it alone
<mbj>
yeah
<snusnu>
good, i needed that doublecheck
<snusnu>
maybe i'll get around to doing it at some point, altho it'd be cool if you could squeeze in a few minutes, given your latest sprints on morpher ;)
<mbj>
haha
<snusnu>
i'll keep on polishing my mapper
<snusnu>
:p
<snusnu>
promise
<mbj>
Its goooood to do some demanding OSS
<mbj>
I have two clients, one forces me to do monkey work.
<snusnu>
:/
<mbj>
That one consumes all my coding enthusiasm.
<mbj>
So doing some demanding OSS work actually frees my mind up.
<mbj>
snusnu: The other loaders require more knowlege
<mbj>
snusnu: The other domain specific transformers to be explicity
<mbj>
*explicit
<mbj>
snusnu: for example the attribute accessor one needs the attributes: s(:attribute_accessors, s(:param, Model, :here, :come, :the, :attribute, :names))
<mbj>
snusnu: Its in the changelog BTW ;)
<snusnu>
mbj: sweet, fixed! i even saw it, but didn't think of it
<mbj>
snusnu: We need to tune the pretty printer a bit.
<mbj>
snusnu: Still lots of noise.
<mbj>
snusnu: I thought about removing the redundant "Morpher::" prefix
<mbj>
snusnu: and/or providing a one line error reference such as input[0]["foo"]["bar"]["10"] guard failure ;)
<snusnu>
mbj: yeah, the output can be tuned for sure
<snusnu>
it's not only about the printer tho, we need a nice/standard way to consume/transform it
<mbj>
yeah
<snusnu>
i dunno if you saw what i did with type-checks/coercions and validations in the DSL .. they're completely extensible, built on morpher transformers
<mbj>
the problem is there are error cases a one line representation is NOT possible.
<mbj>
Because the error might result after a successful transformation
<mbj>
*that alters the type structure
<snusnu>
so yeah, i fully imagine to be able to coerce and validate an entity, therefore, i need ways to get back at different error formats
<mbj>
snusnu: I separete into "input format" specific errors, and "domain errors"
<mbj>
snusnu: For domain errors I'll put "named predicates" into the tree allowing us to receive unique identifiers for rule violations.
<mbj>
So you just scan for guard violations, and can receive the name of the violation. To use this for generating violation error messages that are domain specific.
<mbj>
I'd NOT put that named nodes inside the transformer stages.
<mbj>
Because I think we should not do domain validations here.
<snusnu>
we'll see, if it's simply about associating coercions and predicates with an entity blueprint, i'm fine with doing it in one stage i guess
<snusnu>
we'll see ...
<mbj>
snusnu: IMHO it should conceptually be two steps.
<mbj>
snusnu: Remember morpher stops on first error.
<mbj>
snusnu: Never process business logic before fully parsing your input.
<snusnu>
mbj: that's the code that powers the pastie
<snusnu>
dkubb: fyi, the above link is a rom-mapper spike on morpher, that supports http://pastie.org/8901939
<mbj>
dkubb: hello
<snusnu>
mbj: here you can see how i use the morpher coercions/predicates to do coercion/validation .. the "_" param represents the injected context (a hash of options passed to #map, #wrap or #group)
<snusnu>
mbj: btw, your last point, never process business logic before fully parsing input, is of course true, but i don't see how doing a sanitization/coercion/validation process in "one go" violates that, internally it'd be 3 steps anyway .. and of course it happens before business logic
<mbj>
snusnu: k
<mbj>
dkubb: BTW you are free to fsck anything in Morpher::Evaluator::**::* namespace.
<dkubb>
if you want
<mbj>
yeah
<dkubb>
this is going to be hard, you know most of my tricks
<mbj>
dkubb: Actually that whole self.build is dead code!
<mbj>
dkubb: I pushed all the AST handling to the Compiler namespace.
<mbj>
mom
<dkubb>
mbj: why the distinction between binary and nary operators? why not one or the other, since one can be used to model the other
<mbj>
dkubb: I think for predicates I'll end up only using binary evaluators, but for transformers binary evaluators modelling narity would just blow up the evaluation tree.
<dkubb>
I guess it depends on how many nodes you join together
<mbj>
dkubb: So the only nary node I currently have is s(:block, transform_a, transform_b, ....)
<dkubb>
I find binary much easier to optimize
<mbj>
dkubb: this, by definition, is modelling a sequence of transformations.
<mbj>
Using binary would be possible but make debugging / understanding of evaluation trees infinitely harder.
<snusnu>
ok guys, i have to go, cu around, comments on the mapper code are most welcome