kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
postmodern has quit [Quit: Leaving]
skade has joined #rom-rb
kleech has joined #rom-rb
kleech has quit [Remote host closed the connection]
kapowaz_ has joined #rom-rb
kapowaz has quit [Ping timeout: 240 seconds]
kapowaz_ is now known as kapowaz
mkristian has joined #rom-rb
cored has joined #rom-rb
zekefast has quit [Ping timeout: 240 seconds]
lfox has joined #rom-rb
zekefast has joined #rom-rb
jgaskins has joined #rom-rb
zekefast has quit [Quit: Leaving.]
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
zekefast has joined #rom-rb
snusnu has joined #rom-rb
CraigBuchek has joined #rom-rb
snusnu has quit [Quit: Leaving.]
lfox has quit []
snusnu has joined #rom-rb
zekefast has quit [Quit: Leaving.]
<mbj>
snusnu: hi
<snusnu>
mbj: hey
<snusnu>
mbj: bbiab
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
zekefast has joined #rom-rb
<snusnu>
yo mbj
<mbj>
snusnu: jo
<mbj>
snusnu: Had a very good OSS yesterday.
<snusnu>
mbj: nice! i saw the commits to morpher
<snusnu>
mbj: so what's its status?
<mbj>
snusnu: Not ready ;)
<mbj>
snusnu: But far better loc / feature score ;)
<snusnu>
mbj: hehe
<snusnu>
mbj: what are the major parts missing?
<mbj>
snusnu: DSL is compleatly absent.
<mbj>
snusnu: And mutation coverage of all nodes.
<snusnu>
mbj: all nodes are around tho?
<mbj>
snusnu: + errors for tracking transformers.
<mbj>
snusnu: no, but adding nodes is so easy.
<mbj>
snusnu: Just need a node of each type to prove my design.
<snusnu>
mbj: what i mean is,can we start thinking about a dsl?
<mbj>
snusnu: Next I'll add erros to trackers. Than its feature comleate.
<mbj>
snusnu: Yeah, feel free to think about DSL. As long it results in an AST I'm happy to build the backend.
<snusnu>
mbj: sweet, any different requirements compared to ducktrap? for the dsl i mean
<mbj>
snusnu: less ugly
<snusnu>
wdym?
<snusnu>
i wouldn't copy ducktrap dsl if that's what you're thinking ;)
<mbj>
snusnu: duckrap was ugly. Morpher should be LESS ugly.
<mbj>
snusnu: Just design whatever you like. Dont even think about ducktrap / morpher.
<mbj>
Design a DSL how you'd like to have it for data transrormation. Totally free.
<snusnu>
i more meant feature wise, or is it still "only" about defining transformations in both directions, ok
<mbj>
And compile it to an AST that reflects this DSL structure as close as possible.
<mbj>
snusnu: Inverse generation is alreay in.
<snusnu>
mbj: so this time, you only need to specify one direction? how would that work for the general case?
<mbj>
snusnu: You before also only specified one direction.
<snusnu>
mbj: ehm, no? at least not in the way i mean
<snusnu>
mbj: a hash_transform involved me telling it how to go forth, and back
<mbj>
snusnu: no
<snusnu>
fetch_key/dump_key
<snusnu>
dude ...
<mbj>
snusnu: that was just an implementation detail.
<mbj>
snusnu: That leaked through the DSL.
<mbj>
snusnu: dump_key was to place a key in a generated hash.
<mbj>
snusnu: fetch_key to apply a transformation to the value of a key in a hash
<mbj>
snusnu: A fetch / dump -key pair was like: take a value from hash, process it, and put it back.
<mbj>
snusnu: Through mostly it was fetck_key("a_string"), some_foo; dump_key(:a_string)
<snusnu>
mbj: well, that's what makes it bidirectional the way i think about it
<snusnu>
mbj: so at its core, morpher now provides transformations, and it's your responsibility to declare them in a "chain" that'll guarantee roundtripping?
<mbj>
snusnu: no, if you use highlevel structures you should not have to think.
<mbj>
ducktrap:
<mbj>
hash_transform do
<mbj>
fetch_key("a_string") do
<mbj>
some_transformation
<mbj>
dump_key(:a_string)
<mbj>
end
<mbj>
end
<mbj>
morpher:
<mbj>
hash_transform do
<mbj>
symbolize_key("a_string") do
<mbj>
some_transformation_on_value
<mbj>
end
<mbj>
end
<snusnu>
and there are predefined ops like symbolize_key, so you only define the transformation on the string, and "on the way out", it knows to perform #to_sym because of the primitive op?
<mbj>
snusnu: that symbolize_key will be represented via fetch / dump_key after AST transform.
<snusnu>
mbj: ok, so coming up with #symbolize_key is actually already a DSL design?
<snusnu>
mbj: or is symbolize_key provided by "core" morpher already
<mbj>
snusnu: Its a preprocessor.
<mbj>
snusnu: this preprocessor was a proof of concept.
<snusnu>
mbj: so, it'll record the block given to symbolize_key, and it'll know that it has to transform a symbolize_key(value, &block) node into fetch_key(value) { call_the_block; dump_key(value.to_sym) } ?
<snusnu>
can the block contain arbitrary stuff? is it's return value important?
<mbj>
snusnu: no
<mbj>
snusnu: you emit an AST with s(:symbolize_key, "foo", s(:more nodes))
<mbj>
snusnu: And pass this into the compiler.
<mbj>
snusnu: The compiler knows s(:symbolize_key ,... will be expanded.
<mbj>
snusnu: I'll add a dedicated preprocessor so you can view the AST after and before Preprocessing.
<snusnu>
mbj: i guess i'll keep on doing axiom-schema then (i would have anyway) .. i need more time to get a feel for morpher to be able to think about a dsl
<snusnu>
so far i basically only heard no's to my assumptions, so i guess i'm not yet ready for it ;)
<mbj>
snusnu: sorry ;)
<mbj>
snusnu: I'll add a DSL than you can think about improving it.
breakingthings has joined #rom-rb
<snusnu>
mbj: sounds good
snusnu has quit [Quit: Leaving.]
mkristian_ has joined #rom-rb
mkristian has quit [Read error: Operation timed out]
lfox has joined #rom-rb
mkristian__ has joined #rom-rb
snusnu has joined #rom-rb
kleech has joined #rom-rb
mkristian_ has quit [Ping timeout: 272 seconds]
vsorlov has joined #rom-rb
mbj has quit [Quit: leaving]
kleech has quit [Remote host closed the connection]
lfox has quit [Ping timeout: 248 seconds]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] mbj/inflecto#21 (master - 8160889 : Martin Gamsjaeger): The build has errored.
lgierth has quit [Read error: Operation timed out]
lgierth has joined #rom-rb
breakingthings has quit []
zekefast has quit [Quit: Leaving.]
<snusnu>
hey dkubb, still around?
<dkubb>
snusnu: yup
<snusnu>
dkubb: yeah, so we were discussing the responsibilities of axiom-schema
<snusnu>
and we ended up thinking that it should not be the responsibility of axiom-schema to define relations that are already connected to a specific database
<snusnu>
we want axiom-schema to *only* define relations, that by themselves, basically raise on all ops, i.e. that aren't even connected to the memory adapter
<snusnu>
you'd have to take an app specific Database instance (we can provide a base class) that knows about an adapter, and relation names
<snusnu>
you can then use that, to get actual, gateway relations, from the relations registered with the schema
<snusnu>
so the idea is to define only relations, that you can then hook up to whatever adapters
<snusnu>
in tests, you'd use memory backed ones, for production/development, you'd use the native backends of your choice
<snusnu>
so basically, axiom-schema doesn't even need to know about the concept of databases, it's simply a registry of relations
<snusnu>
you can take individual relations, or a set of those, and "turn them into" db backed relations (gateways)
<snusnu>
dunno if that makes sense from that description, but it was basically what we were discussing
<snusnu>
well, at least related to axiom-schema .. we then went on to think further about how we actually want to *manipulate* relations, i.e. support insert/update/delete from relations (with EVs and ECs)
<snusnu>
so, re axiom-schema, think of it as only a hash of relations .. in order to connect a few of these relations to, say, a postgres database . .you'd have to write a Postgres < Axiom::Database class, and then do something like axiom_schema = axiom_schema.connect(Postgres, :rel_1, :rel_2, …)
<snusnu>
well, some api like that, but you get the idea?
CraigBuchek1 has quit [Quit: Leaving.]
<snusnu>
that Postgres class, it would know which schema relation names, map to which actual postgres table names, and it would know how to create postgres relations
<snusnu>
dkubb: i'm not really sure wether i gave a proper description of our ideas, can you follow them at least loosely so far?
<dkubb>
I think so, sorry, in two convos at once
<snusnu>
no worries
lfox has quit [Quit: ZZZzzz…]
<snusnu>
in any case, the core idea behind it, is that a formal description of the involved relations (the DSL provided by axiom-schema) .. should not know about the actual backends used for those relations
<snusnu>
i.e. axiom-schema relations themselves need not have an idea that they are (going to be) connected to any adapter backed relation
<snusnu>
all it cares about, is that they are *relations*
<snusnu>
you can then go on to "transform" that schema (of course doing functional update, returning new schema instances) into a set relations that are connected to some actual adapter
<dkubb>
so you're thinking axiom-schema would more be used to tie together relations from different adapters?
<snusnu>
yeah, and axiom-schema itself has no idea about adapters and databases
<snusnu>
it only describes the relations
<snusnu>
but it provides some api like #connect, that you pass an adapter, and a set of relation names .. and it will return a new schema instances, that now has gateway relations, at least for those passed to #connect
<snusnu>
so it really is a blueprint of the schema, but in no way tied to actual databases
<snusnu>
a true, logical schema
<snusnu>
which you can then use to build a physical one
<snusnu>
so when you define an axiom schema, you simply register base relations and relations, with all unique names .. if you then want that schema to be "deployed" in memory, you'd do something like schema = schema.connect(memory_adapter)
<snusnu>
if you want some relations to reside in postgres and some in mysql, you'd do sth like: schema = schema.connect(postgres, :rel_1, :rel_2); schema = schema.connect(mysql, :rel_3, :rel_4)
<snusnu>
of course there can be sugar on top of that stuff, that api is very crude and not likely to end up this way, but it should bring the idea across
Guest___ has joined #rom-rb
<snusnu>
another stab at it: 1) you define your axiom schema, all (base) relations, unique names 2) you write a Database class (we provide base functionality) which has an adapter, and an internal map of logical to physical relation names 3) you create a new "physical" schema with schema = schema.connect(that_database_class)