<mbj>
snusnu: Morpher::Evaluation#success? and bubble this through the evaluator trees.
<mbj>
snusnu: Actually I was trying to reach solnic. Tab completition choose you because solnicht left ;)
<snusnu>
mbj: no worries, can't wait for it to arrive ;)
<mbj>
snusnu: We forgot to do our weekly rom skype call for a while.
<snusnu>
mbj: yeah man, i was on holiday and now i'm pretty busy again
<dkubb>
good morning
<snusnu>
mbj: we should try to do one within the next 2 weeks tho, cause from then on, i'll be on holiday and then travelling
<snusnu>
hey dkubb
<dkubb>
yeah, I try to fit it in a few nights a week when I have some spare time
<dkubb>
I'm working on the sql generation and parsing, doing round-trip testing
<dkubb>
thinking about both sides of the problem have helped me with generation
<dkubb>
I feel like the ast is better and I'm finding problems in generation because I need to think more deeply about the structure of the query
<dkubb>
like, for example, order of operations
<snusnu>
dkubb: out of curiosity, do you have specific (axiom/rom) plans for putting the sql parser to use, or is it "just" for being able to do roundtrip testing
<snusnu>
dkubb: in any case, rest assured that i like the direction :)
<dkubb>
no, the primary purpose is to replace the sql generation under axiom
<snusnu>
yeah
<dkubb>
I know some people didn't like how I emit the queries, so I'm trying to make it just as correct, but easier to understand
<dkubb>
I'm going to do some transformations on the ast, where I rewrite nested subqueries to inner joins when possible
<dkubb>
in truth, I never liked the exact way I emit nested queries either
<snusnu>
sweet, i think correctness obviously comes first, but when it comes to debugging sql, idiomatic queries help
<dkubb>
but I was mostly fine with it because the queries were correct
<dkubb>
but when debugging idiomatic queries are probably really important
<snusnu>
definitely
<dkubb>
especially since I expect people to be looking at the generated queries to try to figure out things like why and index isn't being used, or why too much data is being pulled in at once
<dkubb>
a 10 level deep nested query is hard for humans to parse
<snusnu>
dkubb: btw, i had to interrupt my work on axiom-schema because i got too busy commercially, i'm thinking that maybe during my vacation, i'll be in the mood to do some hacking tho
<snusnu>
i'll be on holiday for 1 month starting end of january, and after that, i'll be travelling but working for another 3 months
<mbj>
snusnu: heh
<mbj>
snusnu: no problem. Just ping me once you are ready. I have skype open during daytime typically.
snusnu has quit [Quit: Leaving.]
cored has joined #rom-rb
cored has joined #rom-rb
snusnu1 has joined #rom-rb
snusnu1 has quit [Client Quit]
snusnu has joined #rom-rb
<dkubb>
mbj: thanks for fixing the yardstick issues so quickly
<dkubb>
I must've been using it in an environment where set was loaded by something else
<mbj>
dkubb: Probably.
<mbj>
dkubb: BTW I noticed another long standing yardstick problem. I'll fix it also.
<mbj>
dkubb: It arises when sorting.
<mbj>
dkubb: manifests in: yardstick-0.9.6/lib/yardstick/processor.rb:57:in `sort_by': comparison of Array with Array failed (ArgumentError)
<mbj>
dkubb, snusnu: Just cracked some thoght problem with morpher
<mbj>
shared specs covering more cases now
postmodern has joined #rom-rb
<mbj>
Really happy, I think morpher could be a nice foundation for any kind of datastructure mapping I'll do in the next years.
<mbj>
Even if I port it to another language.
<dkubb>
mbj: have you never seen anything similar to morpher in another language?
<dkubb>
I haven't, but I haven't really looked
<mbj>
dkubb: I dont think so.
<mbj>
dkubb: But you are longer in the business than me.
<mbj>
Most languages have "parts" of morpher.
<mbj>
But not the full thing.
<mbj>
Its really interesting for me to research in this topic. Especially once I realized I could have "imperfect" mappings. #transitive => false.
<mbj>
dkubb: I'd expect there is something like morpher in a language.
<mbj>
dkubb: But I'd be really prod if I'd found a new pattern. 0.001% chance.
<mbj>
*proud
<dkubb>
that'd be cool
<dkubb>
it might even be cooler if you rediscovered another pattern though, because once you find the right name for it then there's a whole body of code and research you can use
<mbj>
dkubb: Sometimes I become arrogant. And think my implementation of a pattern could be better than existing once.
<mbj>
dkubb: I think I proved this with mutant vs heckle, unparser vs ruby2ruby
<mbj>
dkubb: But other communities could easily build stronger equivalents.
<dkubb>
I don't think that's arrogant. we can often do something better when there is an existing implementation
<mbj>
dkubb: Mhh, I researched around 5min into heckle.
<dkubb>
heh
<mbj>
dkubb: Dont think I ever used it for reference.
<dkubb>
well, heckle is more a proof of concept
<mbj>
I just saw the code (a giant class) and moved on.
<dkubb>
no one actually uses it seriously anymore afaik
<mbj>
I saw on twitter some people are using it.
<dkubb>
well, maybe a few peolpe, but it hasn't really caught on
<dkubb>
zenspider has said to me that he doesn't like the code and it's hard for him to maintain
<mbj>
Yeah. I expect so.
<mbj>
I really value heckle, for proof of concept and getting me into mutant.
<mbj>
I dont like the code. But still value the efford the author put in.
<dkubb>
he did enough to prove it was a good idea
<dkubb>
I found tons of bugs in axiom when I originally started using it
<mbj>
yeah
<dkubb>
mutant did find even more though, which is expected
<mbj>
:D
<mbj>
Heckle has lots of blind spots.
<mbj>
Nodes the mutator does not see.
<mbj>
Also the lack of an isolation mechanism leets to many "falsly killed mutations"
<mbj>
*falsely
<CraigBuchek>
In some ways, the "competition" is good. Survival of the fittest. Like how KDE and Gnome tend to make each other better.
<mbj>
CraigBuchek: +1
<CraigBuchek>
And since they're
<CraigBuchek>
Open Source, you can steal ideas from each other.
<dkubb>
I actually think every oss project needs at least one strong competitor
<CraigBuchek>
I've not used Heckle or Mutant, but I've been away of Heckle for some time, and think it's a great idea.
<dkubb>
lots of lots of competitors is bad, but one strong one is good
<CraigBuchek>
Yeah, 2 or 3 seems about right for competitors.
<dkubb>
maybe even two or three, but too many and things get dilluted
<dkubb>
I was upset when merb was killed off. I think it made rails weaker
<CraigBuchek>
I can think of some examples where we're starting to exceed that. Rack servers. Background job processors.
<CraigBuchek>
dkubb: The merb case is a bit different, IMHO. It got absorbed into Rails, more than killed off.
<mbj>
dkubb: I think rails does not need a competitor. It'll kill itself.
<CraigBuchek>
I was ready to move from Rails to Merb, then they announced the merger. I'm relatively happy with the resilt.
<dkubb>
it was kind of forced on everyone involved though
<dkubb>
rails has no strong competition in the ruby community, merb would've made it stronger as competition rather than a merger I think
<CraigBuchek>
What I'd really like to see is something that's more like the hexogonal architecture. Where the application is laid out, and the web UI sits on top of that.
<CraigBuchek>
I'd also like to see a strong competitor to ActiveRecord. :D
<dkubb>
I'd like that. DM was strong, and I still think DM1 is better than AR4, but I stopped wanting to develop new apps using an ActiveRecord pattern
<CraigBuchek>
Looking at the description of Hexagonal Architecture again makes me want it even more.
<dkubb>
so my contributions to DM fell because I wasn't using it in any day to day projects. I'd rather work on ROM since I see it as a better way forward
<dkubb>
oss time is limited, so I can only really invest in the places where I see it making a difference to myself firstly, and secondly to the community
<CraigBuchek>
I think ROM is a better way forward, but I wish DM1 was still being actively worked on in the meantime.
<dkubb>
yeah, I don't see anyone picking up the slack really. I've offered to mentor a few people, but so far no one's wanted to start
<CraigBuchek>
Because as it stands right now, neither is a really viable competitor.
<dkubb>
I used DM1 on a rails 3 project up until the summer and it worked really well. better than what AR4 would've been
<dkubb>
Sequel is a really good Active Record library
<CraigBuchek>
The only problem I have with DM1 is supportablity going forward.
<dkubb>
the problem is that it's not marketed as well as AR.. it's not even been marketed as well as DM was
<dkubb>
yeah, even I probably wouldn't start a new project today using DM1.. not unless whoemever I was working on it with would agree to sponsor dev
<dkubb>
because I can't donate maintenance time for work projects
<dkubb>
if I'm going to make an oss project it would be based on ROM
<dkubb>
it's a bit selfish, but with limited free time I don't think I can do anything else. it probably wouldn't be sustainable for me to work on something that I don't think is the way forward
<dkubb>
maybe I could do it for a few months, but it would probably fall off regardless of how hard I would try not to
<CraigBuchek>
Yeah. That's kinda what I'm saying too.
<CraigBuchek>
Except ROM really isn't in a place I'd be comfortable to be using yet.
<dkubb>
I wouldn't use it for a work project
<dkubb>
most of the time I don't get to do greenfield dev anyway. right now I'm working on a rails/spree app, so I have to use AR
<dkubb>
I could mix in other ORMs, but that's not fair to whoemever has to maintain it after me
<CraigBuchek>
I think Perpetuity might get to that place first — if it gets the Postgres adapter working. It seems simpler. I have some fear that it's too simple though for future needs.
<dkubb>
yeah, I think that might be a good option for a non-AR ORM right now
<CraigBuchek>
Yeah — that's the other part of "supportable" - is there enough mindshare for people to bother learning it.
<CraigBuchek>
It looks like Perpetuity might be a good stepping stone to ROM.
<dkubb>
I think for the most part we agree on lots of things. the syntax may be different, but many of the concepts are the same
<dkubb>
and it's mapping from different concepts that's the really hard part of moving
<dkubb>
perpetuity also targets postgresql, which will be the first DB that ROM targets
<dkubb>
I'll accept patches for mysql and sqlite, but I probably won't add them until someone agrees to maintain them
<CraigBuchek>
How are the in-memory and Postgres adapters coming along these days?
<dkubb>
in-memory is pretty solid and mostly "done"
<dkubb>
I'm working on the SQL generation side of things right now
<CraigBuchek>
I see.
<dkubb>
there's an sql gem that I have, which is going to generate the SQL for SELECT, INSERT, UPDATE and DELETE
<dkubb>
it's not tightly coupled to axiom though
<dkubb>
there'll be a bridge between the two
<CraigBuchek>
So I've been working on Virtus front-ends for AR (declare attributes in the model, check that with the DB) and Perpetuity, in hopes that I can help with a ROM front-end when it's ready.
<dkubb>
the problem really comes down to transforming one ast into another
<dkubb>
relational algebra is relatively similar to SQL, but what's considered idiomatic SQL is a bit different, so we need to do things like transforming nested queries into things like multiple INNER JOIN statements
<dkubb>
that was one of the biggest complains when I released my first naive SQL generator, that the queries would be unintelligible to developers
<dkubb>
(while being correct, as "proven" by extensive fuzzing)
<CraigBuchek>
And in hopes that getting people to declare attributes in their model classes will make a transition to ROM easier.
<dkubb>
I don't think ROM is going to require that. attributes need to be declared in the mapper layer at least. if they're in the model they could be inferred by the mapper though.. it won't be a requirement
<dkubb>
I could see there being a virtus aware mapper that can build itself based on the attributes defined in the model. that wouldn't be too difficult to make
<CraigBuchek>
Yeah, that's the idea. The mapper can pull from the model.
<dkubb>
we want ROM to work with plain ruby objects
<dkubb>
I would guess perpetuity could do the same thing
<mbj>
dkubb: See it this way, 90% of my @api tags have the value private.
<mbj>
dkubb: Removing 90% of the occurencies => less code and faster to parse for brain.
<dkubb>
mbj: do you have lots of public visibility @api private methods?
<mbj>
no
<mbj>
onlysome.
<mbj>
Some of my libs, like unparser have only "one" public method.
<mbj>
Unparser.unparse for instance.
<mbj>
unparser has one @api public, and 297 @api private.
<mbj>
*296 api private.
<dkubb>
unparser is probably a bit on the extreme side
<dkubb>
so is sql
<mbj>
sure
<mbj>
but same for mutant, only 2 classes have public interfaces.
<mbj>
With rom I expect only 10 - 20 methods to be public.
<dkubb>
that is true. lots of private classes too
<dkubb>
what if when a class is @private, it assumes all methods are @api private?
<dkubb>
in fact, an @api public in an @private class is likely a mistake, since a private class should not be visible in the public api, not even one of it's methods
<dkubb>
@private is a YARD convention already, so we're not inventing any new concepts
<mbj>
dkubb: good idea!
<mbj>
I'm 100% okay with having to specify @api private tags on methods for classes without @api private.
<mbj>
Also we might consider to load the library and examine the visiblity of methods on-line.
<mbj>
To detect methods that are not part of the public interface anyways.
<mbj>
dkubb: morpher now supports conceptually all features ducktrap had, + some new ones.
<mbj>
Will clean up more and than release 0.1.
<dkubb>
mbj: I would accept a patch for such a change, or you can make an issue in the tracker and I'll add it on my next yardstick pass
<mbj>
0.1 will be fully mutation covered and stay there.
<dkubb>
nice!
<mbj>
I think I found a nice set of primitves to build it.
<mbj>
Also the shared examples are many times more powerfull than the ones I have in ducktrap.
<mbj>
dkubb: gonna go to sleep, have fun
mbj has quit [Quit: leaving]
postmodern has quit [Quit: Leaving]
postmodern has joined #rom-rb
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] rom-rb/devtools#236 (master - 81dee5e : Markus Schirp): The build was broken.