<snusnu>
dkubb: i've decided that i will use whitquark/ast right from the start in axiom-schema
bf4 has quit [Ping timeout: 272 seconds]
<snusnu>
dkubb: simply as the internal structure used for the "data collection phase" while executing the DSL code
<snusnu>
dkubb: an ast processor would then create the respective schema object along with axiom (base) relation instances
<snusnu>
dkubb: and databases/repositories
<snusnu>
dkubb: based on the ast that got collected by the dsl
<snusnu>
dkubb: as a side effect, i will end up with an ast format that describes axiom base relations
<snusnu>
dkubb: also, with some ast reshuffling/processing/topsorting, we might even get around finalization ;)
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 246 seconds]
irclogger has quit [Ping timeout: 246 seconds]
<dkubb>
snusnu: very nice. you should check out mbj's axiom-sexp
<dkubb>
snusnu: I bet it could be adapted into an axiom-ast gem, which you could use
<dkubb>
snusnu: I think mbj already did all the work of breaking down axiom into nodes into something somewhat resembling an ast
<dkubb>
it looks like not all of it is, some of the attribute types are missing, but it's probably a good start
<snusnu>
dkubb: thx for the tip! i will definitely look at it
<snusnu>
dkubb: btw, i just stumbled again over the problem of equalizer freezing the hosted class
<snusnu>
dkubb: took a while to figure out what was happening .. i was looking at failures in my ast gem usage, but well, it was equalizer ;)
<snusnu>
dkubb: the dsl class is mutable and keeps a reference to an ast instance, that is updated everytime a method is called that updates the ast
<snusnu>
dkubb: simply including Equalizer.new(:ast) broke that, because that leads to a frozen hosting class
<snusnu>
dkubb: iirc there's a ticket somewhere, i remember filing one
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 264 seconds]
adkron has joined #rom-rb
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 264 seconds]
irclogger has joined #rom-rb
irclogger has quit [Ping timeout: 264 seconds]
adkron has quit [Ping timeout: 246 seconds]
bf4 has joined #rom-rb
postmodern has quit [Quit: Leaving]
postmodern has joined #rom-rb
adkron has joined #rom-rb
bf4 has quit [Ping timeout: 245 seconds]
irclogger has joined #rom-rb
irclogger has quit [Ping timeout: 272 seconds]
vsorlov has joined #rom-rb
adkron has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
cored has quit [Ping timeout: 265 seconds]
vsorlov has quit [Ping timeout: 272 seconds]
lfox has quit [Quit: ZZZzzz…]
<dkubb>
snusnu: I don't have any open tickets for equalizer, also I only have one reported ticket from you that I closed 9 months ago and it doesn't appear related
<dkubb>
snusnu: if you can get a minimal repro together I can look at it
bf4 has joined #rom-rb
irclogger has joined #rom-rb
bf4 has quit [Ping timeout: 272 seconds]
irclogger has quit [Ping timeout: 246 seconds]
dkubb has quit [Ping timeout: 245 seconds]
Gibheer has quit [Ping timeout: 245 seconds]
Gibheer has joined #rom-rb
snusnu has quit [Quit: Leaving.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 252 seconds]
dkubb has joined #rom-rb
bf4 has joined #rom-rb
irclogger has joined #rom-rb
bf4 has quit [Ping timeout: 264 seconds]
irclogger has quit [Ping timeout: 272 seconds]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 245 seconds]
bf4 has joined #rom-rb
irclogger has joined #rom-rb
bf4 has quit [Ping timeout: 272 seconds]
irclogger has quit [Ping timeout: 245 seconds]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 265 seconds]
bf4 has joined #rom-rb
kenphused has quit [Ping timeout: 240 seconds]
irclogger has joined #rom-rb
postmodern has quit [Quit: Leaving]
bf4 has quit [Ping timeout: 246 seconds]
irclogger has quit [Ping timeout: 264 seconds]
zekefast has joined #rom-rb
mbj has joined #rom-rb
<mbj>
dkubb: morning
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 246 seconds]
adkron has joined #rom-rb
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
adkron has quit [Ping timeout: 252 seconds]
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
snusnu has joined #rom-rb
<snusnu>
yo mbj
<mbj>
snusnu: jo
<mbj>
snusnu: I'm really happy morpher turns out to become great.
<snusnu>
mbj: i really like the ast stuff
<snusnu>
awesome
<mbj>
snusnu: Begun to implement ast transforms to simplify evlauators and DSL.
<snusnu>
mbj: i will need your brains a bit later on for exactly that reason .. transforming an ast
<snusnu>
mbj: i hope to finish my ast construction spike soonish, and then i will push it, for your critical eyes to see
zekefast has quit [Quit: Leaving.]
<mbj>
snusnu: heh
bf4 has joined #rom-rb
irclogger has joined #rom-rb
<mbj>
snusnu: We can pair if you want to.
<mbj>
snusnu: AST transforms are really powerfull.
<snusnu>
mbj: that'd be very cool at some point! i still have to do some kind of setup for that tho .. e.g., i still haven't activated and familiarized myself with tmux
bf4 has quit [Ping timeout: 272 seconds]
<snusnu>
mbj: btw, would you think that an axiom-schema needs a name? (i currently don't store one)
zekefast has joined #rom-rb
zekefast has quit [Client Quit]
<snusnu>
mbj: i guess it makes no sense for a schema to have a name, it spans n databases anyway, probably no need to have more than one of those around?
irclogger has quit [Ping timeout: 272 seconds]
<mbj>
snusnu: no I dont think so.
<mbj>
snusnu: Why you'd need multiple schemas?
<snusnu>
mbj: i see no reason either
<snusnu>
just doublecheckin'...
<snusnu>
mbj: i somehow think that we should "disallow" to define virtual relations within the same dsl block than base relations
<mbj>
snusnu: yeah
<snusnu>
mbj: no finalization issues for base relations with the intermediate ast we create .. but for virtual relations, they need to either have all base relations defined already, or we need to construct them asts too (which will probably still take us a while?)
<mbj>
snusnu: We can reorder relation link nodes to the end of the ast evaluation.
<mbj>
snusnu: To remove the need for finalization?
<snusnu>
mbj: yeah, that's what i thought about too .. but this only works if virtual relations are created as sexps too
<snusnu>
mbj: but the "ideal" way to define them, is to just use regular axiom api .. which implies the relations have either already been built, or are available as sexps only
<snusnu>
mbj: ideally, after a schema definition, we know the complete ast of everything (including complex joins in virtual relations etc)
<snusnu>
and only *then* do we start to actually build objects
<mbj>
snusnu: You can easily create a new base relation based on a base relation with no FK attribute.
<snusnu>
wdym?
<mbj>
snusnu: mhh
<mbj>
snusnu: Uneasy to explain.
<mbj>
snusnu: Let me just point you to this once I see your gist.
<snusnu>
ok fair enough
<snusnu>
for now tho, lemme rephrase it … when defining a virtual relation, i want to just do relation(:some_name) { people.join(tasks) } .. this implies that there are either already built base relation objects for people and tasks around, or (and i'd prefer that) .. that these virtual relation definitions only define an ast as well … allowing us to perform validity checks on the ast, *before* we start building axiom objects
<snusnu>
mbj: ^^
<snusnu>
mbj: i.e. we would have an ast for the complete schema definition, validate that, transform it, and process it into proper axiom objects
<snusnu>
mbj: if we can get to the 2nd variant, we need no finalization .. even with FKs in the mix
lfox has joined #rom-rb
<snusnu>
we can validate and reshuffle the ast so that everything is built before its needed
<mbj>
snusnu: exactly
<mbj>
snusnu: Just like the session does.
<mbj>
snusnu: BTW I think the session should use an AST structure ;)
<snusnu>
topsort ftw
<mbj>
snusnu: to reorder ops ;)
<mbj>
Exactly.
<snusnu>
yeah
<mbj>
tsort an AST structure is very easy
<mbj>
More easy than sorting full blown objects representing the ops.
<snusnu>
i imagine so
<snusnu>
btw, i'm already totally sold on using an ast for an ir with dsl definitions done "our style"
<snusnu>
i will probably never write any special case structure again lol
<mbj>
snusnu: heh
<mbj>
;)
<mbj>
Its so awesome how you can special case away stuff via ast transforms ;)
<snusnu>
even tho i don't really like the actual ast building code
<mbj>
solvable
<snusnu>
but that is to be accepted i guess
<mbj>
IMHO
<snusnu>
i'm quite happy with my current design, it's ok'ish factored . .and yeah, sugar can be added
<snusnu>
i'd especially like to have methods that allow me to insert updated nodes at certain positions, just "filling in the rest"
<snusnu>
those should be fairly easy to add tho
<mbj>
snusnu: I think that the use "AST as IR" pattern is a missing pice in our design.
<snusnu>
i will have to use it more, but it really is a very nice pattern for slim dsl implementations where only the pointer to the ast is mutable
<snusnu>
everything else can then be immutable
<snusnu>
and we get the benefits of *knowing* that we only process valid data
<mbj>
heh
<mbj>
yeah
<snusnu>
mbj: question: in an ast for base_relation, should all the children be optional, or should it be "prefilled" with empty nodes for each child type?
<snusnu>
s(:base_relation,
<snusnu>
s(:attributes),
<snusnu>
s(:fk_constraints),
<snusnu>
s(:pk_constraint),
<snusnu>
s(:key_constraints),
<snusnu>
s(:database, database),
<snusnu>
s(:aliases),
<snusnu>
s(:name, name))
<snusnu>
is that "correct" .. or should it only have children for :database and :name
<snusnu>
i somehow assume my above pasted version is correct
<mbj>
snusnu: Its hard to judge this without thinking for myself.
<mbj>
snusnu: Generally it looks good. A very complex node.
<snusnu>
yeah, judging without thinking is probably always a bad idea
<snusnu>
lol
<mbj>
snusnu: thinking about this would require me to try for myself first.
<mbj>
snusnu: Would take 60min
<mbj>
snusnu: I like to compare my and others solutions.
<mbj>
For now I'd just go with this and "feel" the pain, if any.
bf4 has joined #rom-rb
<snusnu>
heh ok, i'll leave it like this for now … i actually went down that road because it made building the ast easier, as i don't need constant nil checks .. also, it seems more natural to describe the type precisely, as in, what properties does it have
<mbj>
yeah
<mbj>
makes sens
<mbj>
I think it could be simplified.
<snusnu>
for a "general" base relation, certainly :database and :aliases aren't needed
<snusnu>
the rest is compulsory tho, i assume
<snusnu>
obviously, the first 3 children (:attributes, :key_constraints and :fk_constraints) are themselves only containers for a list of :attribute, :key_constraint and :fk_constraint
<snusnu>
the rest are "values"
bf4 has quit [Ping timeout: 265 seconds]
irclogger has joined #rom-rb
lfox has quit [Quit: ZZZzzz…]
<mbj>
snusnu: If you give someone an AST you must tell if its the first stage after DSL / parse. Or a very late stage after preprocessing.
<mbj>
snusnu: Also you might have backend specific preproessing.
snusnu has quit [Quit: Leaving.]
irclogger has quit [Ping timeout: 245 seconds]
snusnu has joined #rom-rb
mbj has quit [Ping timeout: 248 seconds]
irclogger has joined #rom-rb
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 240 seconds]
irclogger has quit [Ping timeout: 245 seconds]
<dkubb>
good morning
<snusnu>
hey dkubb
<snusnu>
dkubb: lemme find that equalizer issue for you
<dkubb>
snusnu: sure. I looked but I didn't see anything. maybe it was reported under another project?
<snusnu>
dkubb: yeah it was, am currently looking for it
<snusnu>
dkubb: damnit i cannot find it
<snusnu>
dkubb: i'll keep on working for axiom-schema another half hour and then i have to leave .. it's not that urgent, but i won't forget it and get back to you
<snusnu>
dkubb: roughly, it has to do with equalizer somehow freezing the hosting class
<snusnu>
dkubb: initially i discovered it when working on substation, but i just can't find a related comment/issue
<dkubb>
snusnu: that's really interesting. I wonder if it happens with the latest master code?
<dkubb>
snusnu: the Equalizer#initialize does freeze it's own instance, but that happens before the module is mixed in, at which point it doesn't know anything about the object it's being mixed into
<dkubb>
snusnu: one way to track down where it's happening is define a self.freeze method on the class and have it raise an exception, then do your module includes.. it'll blow up at the point where the naughty code is
<snusnu>
dkubb: tbh, i haven't yet tried equalizer from master, i will try that soon .. right now, the code is otherwise broken, so i have no real testbed ;)
<snusnu>
dkubb: thx for the tip tho! i will surely try it out once i'm back on track
<snusnu>
dkubb: currently still having fun with a bigger refactoring of axiom-schema code .. sadly, i was hoping to have something pushable before i leave for tonight, but i somehow start doubting that
<snusnu>
dkubb: i'm fairly happy with the design of the code so far, of course there's definitely lots of room for improvement
<snusnu>
dkubb: given that it's my first venture into using whitequark/ast, i'm happy tho
<snusnu>
dkubb: and i kinda kept my promise that the DSL objects expose only the bare minimum
<snusnu>
dkubb: there's actually only one mutable place right now if i'm not mistaken, and that's the pointer to current @ast .. hidden in AST::Builder subclasses
<snusnu>
mbj, dkubb: added you guys and solnic as collaborators
<mbj>
snusnu: nice
<mbj>
snusnu: doing a look through soon
<mbj>
snusnu: but ping me if you dont get any input
<snusnu>
mbj: awesome, comment away in the PR, i will leave in a few minutes, but i will continue working on that code tomorrow
<dkubb>
snusnu: cool
<dkubb>
snusnu: once we have a schema object we can also do migrations
<snusnu>
dkubb: yeah!
<snusnu>
dkubb: btw, i *love* how there is currently actually only *one* "real" object .. Axiom::Schema which only exposes #[] .. everything else is purely for constructing that ;)
<snusnu>
dkubb: of course the ast object itself plays the crucial role, but from a "running an app with this" pov, it's one object heh
<snusnu>
dkubb: well of course there's the Axiom::Schema::Database object too, but that's not yet used .. currently i'm only concerned with building the ast .. no transforming/processing yet
<dkubb>
snusnu: I like how you're isolating mutation. it'll make it easier to make the code thread-safe in the future
<snusnu>
dkubb: i'm starting to think that i will never again use adhoc objects to represent IR collected from a DSL .. an ast is a perfect fit, and given that our immutable style involves a lot of building of objects (via dsls) that's a great pattern
<dkubb>
snusnu: yeah, although I probably wouldn't mix AST w/behaviour objects to much, but I like the idea of using it for the DSL side