<solnic>
hah! I wouldn’t go down that route (“real SRP”)
<mbj>
:D
<solnic>
might end up with hellish fire and screaming
<mbj>
AST representation
<mbj>
Lots of our domain / tools use domain specific ASTs to model the domain.
<solnic>
I must say I’m super curious to see how axiom would work using whitequarks’ AST
<mbj>
Axiom::Relation is an AST
<mbj>
solnic: It will become lots of easier to consume.
<solnic>
yeah
<solnic>
+ I think it’s inline with our philosophy - re-using small libraries
<mbj>
solnic: I expect we can compile RA operation executions via the LLVM.
<solnic>
the ast is such a lib
<mbj>
solnic: Longterm target.
<solnic>
now that’s even more exciting
<solnic>
we should, however, try to move forward w/o getting stuck at improving and optimizing all the things
<mbj>
solnic: Imagine a stream of raw tuples coming from 3 datastores, and ruby setups an LLVM backend passing lots of tuples / sec through the pipes. Without hitting any GC / ruby slowdown.
<solnic>
as I once told you, it’s about time to get this thing out to the wild and see what happens
<mbj>
solnic: Ruby managing that complex process, but the "raw" work is done by a highly optimized layer.
<mbj>
yeah
<mbj>
solnic: But I need to have that ultimate target in mind to sharpen layers / interfaces.
<solnic>
it is exciting to know there are so many possibilities to improve the internals
<mbj>
Ruby, for me, becomes more like a "composer".
<solnic>
first, we NEED the full stack with all the features
<mbj>
Its a good language to manage complexity.
<solnic>
I think we could target AST change for 1.0.0 release
<solnic>
but we need to go through the process of building feature-rich RDBMS support + a couple of rock solid NoSQL adapters
<solnic>
based on that we should have a clear picture of what we should do next
jfredett has joined #rom-rb
<solnic>
from my pov changing axiom to use AST is more of an internal improvement (maybe even optimization) so it can wait
<mbj>
solnic: I build 80% of our adapters
<solnic>
don’t let your mind get stuck b/c of that :)
<mbj>
solnic: And I think its worth doing the axiom => ast think as early as possible.
<snusnu>
hah, +1 solnic
<mbj>
solnic: Because adapter development will be many times more easy with this switch.
<snusnu>
let's please be able to USE rom
<snusnu>
then optimize it
<mbj>
But remember, we can transform Axiom::Relation to AST before.
<solnic>
yeah, writing adapters is already simple enough IMHO
<mbj>
Will slow down performance, but okay for me.
<mbj>
solnic: Nope, it isnt :D
<mbj>
solnic: Not if you maintain 5 adapters :D
<solnic>
that’s ok
<solnic>
really
<solnic>
lack of crucial features is far more important than the ease of writing adapters
<snusnu>
+1
<mbj>
all adapters lack write support
<mbj>
and this IS a crucial feature
<solnic>
w/o sql support, w/o UoW, w/o migrations…it’s just not very useuful
<mbj>
All adapters that need an intermediate representation
<mbj>
also known as: query language :D
<snusnu>
don't forget group/ungroup .. it's the killer feature imo
<mbj>
hehe
<solnic>
yeah, relationships in general
<solnic>
this is related to UoW too
<solnic>
mbj: write support? I just added write support to YAML adapter :P
<solnic>
you can add write support to you adapters easily probably
<solnic>
no?
<solnic>
your*
<snusnu>
mbj: the thing is this … i just don't care (at this point) how optimal adapters are … i want to finally be able to USE rom in the most basic scenarios .. we're not there yet, like, at all
<mbj>
solnic: its more complex with languages with intermediate representation
<mbj>
solnic: s/languages/adapters/
<solnic>
mbj: tell me more
<snusnu>
like, we can't even *simulate* relationships easily, currently ...
<solnic>
in mongo db it’s just a hash right?
<solnic>
woah what? wdym?
<solnic>
oh, w/o nest/unnest? right right
<snusnu>
right
<mbj>
snusnu, solnic: I'm busy with commercial stuff, back later
<snusnu>
srsly, i guess there's almost no domain we can model entirely, currently
<mbj>
AND I'LL CLOSE IRC NOW
mbj has quit [Quit: leaving]
<snusnu>
lol
<solnic>
holy shit he must’ve been really busy then
<solnic>
snusnu: yes that’s correct
<solnic>
w/o relationships it’s not useful in 99.999% of the cases
<snusnu>
yeah
<snusnu>
and we both aren't talking about relationships as in dsl, but as in merely mapping 1:n data
<solnic>
yes
<solnic>
snusnu: can you remind me what’s the idea behind releasing devtools and distributing Gemfile.devtools somehow?
<snusnu>
solnic: tbh, not really
<solnic>
hmm ok
<solnic>
I thought you guys have some plan alreadyu
<snusnu>
solnic: i know mbj can't use it commercially because his client doesn't accept any git sources tho
<solnic>
I think I’m ok with releasing devtools
<solnic>
it would stabilise the thing
<snusnu>
solnic: yeah, even tho i see no real need, i also see no reason against doing so
<solnic>
it would be easier for others to use it too
<snusnu>
solnic: the main thing is that devtools code itself should be decoupled from Gemfile.devtools tho .. otherwise, we can't ever establish semantic versioning
<snusnu>
solnic: also, *if* we are to further develop devtools into something more powerful, we'll need a release cycle anyways
<solnic>
true
<snusnu>
mbj initially said that he'd be fine with ever increasing version numbers (with every change of Gemfile.devtools) but i strongly disagree, and iirc he's persuaded now
<snusnu>
the last idea was to have 2 gems, devtools itself, with proper semantic versioning .. and devtools-gemfile, explicitly NOT claiming semantic versioning
<snusnu>
that way we could still allow users to pin to a specific devtools env, along with gemfile
<snusnu>
solnic: btw, i recently did some name brainstorming for devtools (the gem is already taken) .. and "ended up" with mddric (pronounced metric) - metric driven development, ruby in custody .. another alternative would be mddic (pronounced medic) - metric driven development in custody …. :)
<solnic>
snusnu: ok
<solnic>
if the gem name is taken
<solnic>
I refuse to release it :P
<solnic>
I don’t have 3 years to come up with a new name
<snusnu>
lol
dkubb has joined #rom-rb
<dkubb>
good morning
<snusnu>
good morning dkubb
<dkubb>
snusnu: how's it going?
<snusnu>
dkubb: quite alright, thank you .. pretty busy, but oh well :) how's things for you?
<dkubb>
snusnu: not bad, just coming down after a few crazy weeks of work.. hoping to get some axiom work done tonight and over the weekend
<snusnu>
dkubb: sounds good! what are your plans?
<dkubb>
snusnu: I think I'm going to be working on group/ungroup
<snusnu>
dkubb: very awesome! i was about to ask for that :)
<snusnu>
dkubb: i was talking to solnic about it, and we're pretty much "stuck" without it .. i mean, there are other things we could do, but group/ungroup will have the most impact
<snusnu>
dkubb: like, atm, we can't even simulate relationships, as we have no way of mapping {1,m}:n even without any fancy dsl
<solnic>
morning dkubb
<dkubb>
snusnu: what are the other things you can work on that aren't blocked?
<dkubb>
solnic: morning
<snusnu>
good question, lemme think about it
<solnic>
I want to plugin UoW into session but I won’t accomplish much w/o relationship meta-info :)
<solnic>
being mostly info about FKs
<solnic>
+ I really want to create the proxy module I told you about which would allow a multi-layer proxying
<snusnu>
dkubb: tbh, i can't think of any high prio stuff currently, but that probably doesn't mean there are no such things .. what comes to your mind?
<solnic>
session => relation => gateway => axiom
<solnic>
:)
<solnic>
snusnu: migration? O_o
<snusnu>
hehe
<dkubb>
what about catching up on housekeeping, like extracting the support libs and/or adding mutations to mutant?
<snusnu>
it crossed my mind, but yeah, it's a complete subproject on its own
<snusnu>
(that was re migrations)
<solnic>
kk
<solnic>
well
<solnic>
SQL
<solnic>
...
<solnic>
S-Q-L
<snusnu>
we could also … right
<dkubb>
I think anytime one of us gets blocked, assuming we're motivated to continue working and not using the blockage as an excuse for resting (something I totally get), we should fallback to supporting stuff
<snusnu>
:)
<snusnu>
good point
<solnic>
I NEVER REST
<solnic>
O_o
<snusnu>
lol
<dkubb>
I NEVER SLEEP
<snusnu>
hah
<dkubb>
actually this week that's partly true
<solnic>
I don’t believe you, that’s not possible
<solnic>
;)
<dkubb>
s/sleep/sleep well/
<solnic>
I won’t sleep in November once Leo is with us :)
<solnic>
I’m planning to take a full month off
<snusnu>
good plan
<solnic>
like off-off, off from work/ oss everything
<dkubb>
from everything? that's awesome
<solnic>
just help my wife with kids
<solnic>
she will need a lot of help :)
<dkubb>
yeah it's quite a jump from 1 to 2
<solnic>
it is
<dkubb>
it's an even bigger jump from 2 to 3 I hear, but have not experienced
<solnic>
and our first son is…energetic :P
<solnic>
snusnu: we agreed that SQL gem and integrating it with axiom is one of the top priorities
<solnic>
I’m happy to help with SQL gem
<solnic>
fwiw
<solnic>
you could work on it too
<solnic>
I find it kinda cool to work on it :)
<solnic>
mbj says it’s boring but he did similar work lots of times, I did not
<snusnu>
yeah, i actually wanted to familiarize myself with that code already, but i got sidetracked everytime
<snusnu>
you know, i ditched rails and sinatra, now i need to write code that allows me to still write web apps
<snusnu>
lol
<dkubb>
it's not boring to me
<dkubb>
it's only boring if you make it boring :P
<dkubb>
once you've got the code generator, then you can do things like round-trip testing, mutation testing, fuzzing, etc
<dkubb>
those are fun to do, and help solidify the code and the model so that the SQL it generates is perfect
<dkubb>
the SQL the existing axiom-sql-generator makes is perfect from the pov of returning exactly what is specified. it's not perfect from an efficiency pov, but that's a performance optimization
<cored>
hello all
<solnic>
hey cored
<solnic>
snusnu: we should finish some basic version of sql gem asap and then look at dkubb with puppy-eyes look to integrate it with axiom
<cored>
what's the sql gem
<cored>
?
<snusnu>
solnic: :)
<snusnu>
also, hey cored
<solnic>
cored: our new sql generator: github.com/dkubb/sql
<solnic>
we want a pure generator, separated from axiom/rom
<cored>
oh
<cored>
interesting
<cored>
more code to read, even when I'm not getting everythiing from rom
<cored>
:-P
<dkubb>
it's still early
<dkubb>
so you should be able to follow-along fairly easily if you wanted
<snusnu>
solnic, dkubb: without wanting to apply any sort of pressure/priority (cause i know how it goes) .. my feeling is that rom would benefit the most from having group/ungroup, server side value support, and an FK concept
<snusnu>
wdyt?
<snusnu>
my reasoning is this: with these 3 things, we could have a fully functional in-memory, thus reference, adapter
<solnic>
yeah I agree
<solnic>
but all those things are on dkubb’s plate
<solnic>
and we could work on the sql in the meantime :)
<solnic>
dkubb: can I use Hash as attribute type in axiom?
<solnic>
I wonder if we could make mongo adapter fully working
<solnic>
you can genera ObjectIds using mongodb ruby driver
<solnic>
generate*
<solnic>
so, no need to have server-side generated keys support for mongo
<solnic>
and if we can have hash as attribute type then supporting embedded docs won’t be a problem
<solnic>
oh, hash and array of course
<solnic>
I’m only wondering how to extend axiom to support mongo queries with JS’ map/reduce stuff
<snusnu>
solnic: i fail to see how object ids generated fmor the mongodb ruby driver are not, in essence, server side values
<solnic>
snusnu: bkz you can generated them yourself O_O
<solnic>
generate
<snusnu>
solnic: ok, and you would typically do that on the client anyway? pardon my ignorance, i#ve never used mongo
<solnic>
basically when you want to save something you generate object id
<snusnu>
ok
<solnic>
yeah
<dkubb>
solnic: I think a Hash type would work fine
<dkubb>
solnic: I'm adding an Axiom::Relation type for the nesting stuff
<solnic>
cool
<dkubb>
snusnu: yeah, I don't mind being under pressure as long as things are progressing in every area
<dkubb>
s/every area/other areas/
<dkubb>
snusnu: the only thing that bugs me with pressure is when someone says "this is blocking me" and they get hung up on that being the only thing they can possibly be working on, thus putting more pressure on me because things grind to a halt while I work on it
<dkubb>
it's the least motivating position to be in from my pov
<cored>
map/reduce stuff
<cored>
maybe I'm kinda ignorant but don't you think guys that putting a lot of feature or at least more features will slow you down to release at least the in mmemory adapter?
<snusnu>
dkubb: i totally understand that
<solnic>
cored: we already released the memory adapter
<snusnu>
dkubb: and tbh, i realize that i'm currently not spending as much time on rom as i would like to, but i'm pretty busy with commercial stuff too, and am somewhat extracting a few building blocks for web apps along the way, and this currently interests me most, so i spend most of my free hacking time on that
<solnic>
dkubb: I think it’s much easier to keep the progress now because 1) we released it 2) we have a better understanding of what needs to be done in many areas
jdsiegel has quit [Remote host closed the connection]
<mbj>
These moments when I cannod do client coding anymore....
<mbj>
Moving to OSS.
<mbj>
Lets finally implement blacklisting and a good test selection strategy.
<mbj>
solnic: I think I'll also nuke the rspec selection via description feature.
<mbj>
solnic: longterm
<mbj>
solnic: I think inverse line coverage is the best universal strategy.
<mbj>
solnic: Mutant will observe what lines get executed when a specific test runs.
<mbj>
solnic: And than finds its subjects, while inversing the observed relationship
<mbj>
solnic: This way you get the most sharp implicit mapping of mutation subjects to possible killing code.
<mbj>
snusnu: //cc and pls check my thoughts :D
<solnic>
mbj: hmmm this sounds interesting. so, it would run the tests checking which test touches which LOC and build a map out of that and then use it to select tests for each subject, right?
<mbj>
solnic: exactly
<solnic>
sorry, had to rephrase it to make sure I understand
<mbj>
solnic: no problem
<solnic>
ok cool!
<solnic>
please excuse the language but that sounds fucking smart
<solnic>
:)
<mbj>
Its not my invention :D
<mbj>
The PIT maintainer does it also.
<mbj>
The cool side effect of this change: Its *far* easier to support other test frameworks.
<solnic>
I can totally see that
breakingthings has quit []
<mbj>
solnic: I see lots of "improve your coverage" tweets on twitter. They all talk about line coverage tools :D
<mbj>
solnic: I'm talking about those "you get 20% off to integrate $foo with $bar"
<mbj>
solnic: I need to finish mutcov.{org,com} and name "line coverage" as "lie coverage" :D
<mbj>
jfredett: Mutant takes/took lots of my time. And I cannot spend enough time in the tool to improve it.
<mbj>
jfredett: So maybe I'm able to make some $ (€ in my case) to give mutant more time.
<mbj>
jfredett: But I'll start with OSS only for fun. Just the score and the badge. If I see enough demand I'll try the .com route :D
<jfredett>
mbj: yah, I <3 badges
<jfredett>
I've been trying to do more mutant testing in my projects, it's still a little bit hard to get into the habit of, since it's slow and processor intensive
<jfredett>
that said, it's been very useful in spotting subtle bugs
<mbj>
jfredett: I hope to make it faster, there are *lots* of low hanging fruits left.
<mbj>
jfredett: That domain (of mutation testing) is complex, I focused on correct abstractions instead of "having a working tool fast". And it already payed off.
<mbj>
jfredett: Doing such a tool *right* sadly takes lots of time :D
bf4 has joined #rom-rb
<jfredett>
mbj: I know the feeling.
<mbj>
jfredett: What version of mutant do you use?
<mbj>
Still at 0.2?
<jfredett>
uuhh.. I don't know, let me look (I haven't run it on this new project yet)
<mbj>
0.3.rc1 is around 50% faster, because it reuses a pristine rspec world that get loaded outside of the killfork
<mbj>
Also 0.3 has tons of new mutations, so that speed boost gets eaten up :D
<jfredett>
nice.
<jfredett>
yah, I'm still back on 0.1.1
<jfredett>
I need to update my toolbelt gem...
<mbj>
0.1.1 is stoneage :D
<jfredett>
yah
<mbj>
Also 0.3 does not have any C dep anymore.
<mbj>
Switched to whitequark/parser (most awesome lib)
<jfredett>
ooh, cool. I'll have to update this stuff — (reading through the commit history)
<mbj>
Mutants commit history?
<jfredett>
yah
<mbj>
have fun, 1.2k commits :D
<jfredett>
it's more of a scan, really
<mbj>
hehe
<mbj>
jfredett: Tell me about any problem. I'm still planning 0.3 through it was delayed by month now :D
<jfredett>
I'll add rc1 to my projects, see how well it goes.
<mbj>
jfredett: Somehow it does not deserve .rc anymore. Mosty because I found more conceptual problems. But it *works*. (Especailly if you are outside the ROM namespace/ecosystem)
<mbj>
jfredett: Heh, I just realised, 0.1.1 wasnt MY mutant.
<mbj>
jfredett: It was the one from txus, he handed over the gem name to me.
<jfredett>
heh
<mbj>
jfredett: The one from txus had 2 or 3 mutation operators. The last time I counted I had above 100
<mbj>
Also the txus one was buggy and easy to crash on input
<mbj>
Not to blame him, I know what 0.1 versions are like :D
<jfredett>
mbj: yah, I've noticed that 0.1 fails a lot in rbx
<mbj>
jfredett: It was more a prove of concept at this time.
<mbj>
jfredett: A mutation testing tool needs lots of infrastructure
<mbj>
jfredett: most important is a solid unparser to generate diffs on the mutated source
<mbj>
jfredett: That to_source lib was abandoned. The new version for whitequark/parser is here: https://github.com/mbj/unparsr
<mbj>
jfredett: It allows to parse mutant, namespace it under Zombie::Mutant, and execute it again "correctly"
<mbj>
jfredett: This way mutant will soon be self hosting
<jfredett>
holy crap.
<jfredett>
0.04 -> 3.9
bf4 has quit [Ping timeout: 260 seconds]
<jfredett>
yah, I'm working on a testing tool (for doing minitest/benchmark - style tests with arbitrary models), and finding that doing anything general enough to be useful is quite intensive.
<jfredett>
(the whole thing, notably, is part yak shave and part excuse to write an Automatic Differentiator)
<mbj>
jfredett: models == AR-models?
<mbj>
jfredett: Or domain models? Surry the term is so overloaded my brain does not find the correct one :D
<jfredett>
mathematical models
<jfredett>
ie, support arbitrary curves to fit data too (within reason)
<mbj>
heh
<mbj>
yeah, lots of invariants to test in such a domain.
<mbj>
And easy to forget one :D
<namelessjon>
jfredett: Which field?
<jfredett>
it's actually not *too* bad, it's restricted to a single variable model, doing automatic regression isn't too hard. (Mostly I want to support stuff like `n log(n)` matching and `log(log(n))` matching, which I *could* just implement the way minitest does (doing everything by hand once)
<jfredett>
but there's a lot of tricky things to figure out
<jfredett>
namelessjon: fields as in Field? the reals. :)
<jfredett>
namelessjon: like I said, this is a yak shave — I want to do 'assert_performance { n * log(n) }', and instead of doing the simple thing (I am not a smart man), my first thought was "Automatic Differentiator"!
<namelessjon>
jfredett: Nah, as in "which field are you constructing the models for?" Though I'm guessing general stats?
<jfredett>
namelessjon: yah, it's just for performance testing — it'll eventually run a benchmark on some block (iterate `k` times at various sizes on some bound, fit a bunch of curves, report the one w/ the least error)
* namelessjon
nod
<jfredett>
namelessjon: I have a couple abstract datastructures I'm trying to implement. I *think* I'm translating them correctly, but this is probably the best way to gain confidence that I didn't screw up something subtle
<jfredett>
namelessjon: the way I'm going about it involves defining a couple intermediate DSLs, my justification is maintainability, but really it's because I'm trying to exercise another gem I wrote (called `katuv`) which is essentially a internal-dsl framework.
<namelessjon>
:D
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
<jfredett>
mbj: this output is _way_ nicer
<jfredett>
I understand it on it's face.
<mbj>
jfredett: haha
<mbj>
jfredett: You did not used my mutant before :D
<jfredett>
though it's having trouble since a lot of this code is defined in a DSL. how's that plugin thing the API mentioned?
<jfredett>
mbj: yah, the old version was quite confusing
<jfredett>
62.86% coverage… not bad, no great.
<jfredett>
that's mutant 0.2.20, though
<jfredett>
not the rc
<jfredett>
hmm, I get a lot of "can't find definition' output because of forwardable…
<jfredett>
looks like it tries to look in forwardable.rb for the method… *clones* — damnit mbj, I don't need more yaks!
<jfredett>
91.86% coverage on this other project, nice, wasn't even trying. :)
jfredett has quit [Quit: Leaving.]
breakingthings has quit []
Gibheer has quit [Ping timeout: 246 seconds]
snusnu has quit [Quit: Leaving.]
Gibheer has joined #rom-rb
jfredett has joined #rom-rb
postmodern has joined #rom-rb
jfredett has quit [Ping timeout: 240 seconds]
jfredett has joined #rom-rb
<mbj>
jfredett: to_source is legacy
<mbj>
jfredett: You should stare unparser :D
<jfredett>
mbj: hah, I was just cloning mutant first — start at the beginning. :)