<mbj>
dkubb: And yes, I added you to all my gems when we where exchanging push rights.
<dkubb>
hmm.. rubocop is tied to parser 2.0.0 pre1 :(
<mbj>
Bad dep management from their side.
<dkubb>
yeah
<mbj>
whitequark is working hard to keep interface solid.
<dkubb>
I wish there was a way to force a dep on some other package
<mbj>
dkubb: My idea is to have full "zone coverage" (speaking about time zones)
<dkubb>
hehe
<mbj>
dkubb: It would be abused, promised.
<mbj>
So if we have a critical situartion and we cannot release a fix because some maintiainer is at sleep and cannot bump deps, we'd get fucked.
<mbj>
So if you have access to all gems we can get much better response time.
<mbj>
It is not important now, but think about hot ROM days.
<mbj>
And mutant blocks and update for an sql injection (unlikely but we all know dep management) :D
<dkubb>
if it was truly critical we'd release rom-<gem-name>
<dkubb>
which would be gross
<dkubb>
or we'd vendor the gem
<dkubb>
which would also be bad
<dkubb>
but not as bad as sitting idle while a known exploit or serious bug is blocked
<mbj>
jo
<mbj>
I remember a time when you where busy and we where blocked because nobody could push a new adamantium
<mbj>
After that week or so you gave me push rights.
<mbj>
Just to remind it must not be a security issue.
<mbj>
dkubb: I'm clicking the web for hours now, cannot force myself into dev mode.
<mbj>
Will target your mutant bug now to start.
<mbj>
dkubb: And btw I forgot to pronounce that "jo" for you :D
<dkubb>
heh
<dkubb>
mbj: I need to start removing backports from gems that don't need it
<mbj>
dkubb: Yeah
<mbj>
dkubb: IMHO we should not need it at all.
<dkubb>
yeah, not anymore
zekefast has joined #rom-rb
zekefast has quit [Read error: Connection reset by peer]
zekefast has joined #rom-rb
zekefast has quit [Ping timeout: 256 seconds]
<mbj>
dkubb: You remember when I was asked to give up my "elasticsearch" gem name.
<mbj>
dkubb: They *still* did not came up with their super hash based api.
<mbj>
dkubb: BTW mutant spec suite is my last dirty secret.
<mbj>
I think I'll take a week of from commercial and mutation cover it fully.
solnic has quit [Quit: Leaving...]
mbj has quit [Ping timeout: 276 seconds]
mbj has joined #rom-rb
zekefast has joined #rom-rb
<mbj>
dkubb: Fixed the crash you found, released as 0.3.0.beta14
zekefast has quit [Ping timeout: 245 seconds]
zekefast has joined #rom-rb
<mbj>
dkubb: Lets team up to build guard-mutant?
<mbj>
dkubb: Lost my hacky version. :(
<dkubb>
mbj: sorry was installing a new tap in my kitchen
<dkubb>
mbj: yeah, I'd love to work on guard-mutant
<dkubb>
mbj: I need it for work stuff, and I would generally prefer to have something work as I work
<dkubb>
mbj: I don't recall you giving up the elasticsearch gem name.. did you have a DM based gem for this?
<mbj>
dkubb: I was asked by the founder of elasticsearch to hand over gem name, because they are about to release a low level driver under that name
<mbj>
They showed me a gist where they outlined a very heavily hash based API
<mbj>
And I told them my api is much better and we should join foces.
<mbj>
s/foces/forces/
<mbj>
But they did not showed any interest. And said their driver will be ready within weeks.
<dkubb>
ahh too bad
<mbj>
Month pathed. And I rereleased my driver under the "esearch" name while giving them access to "elasticsearch"
<mbj>
s/pathed/passed/
<mbj>
So I was just bitching :D
<mbj>
And yeah, I used that elasticsearch gem, but as I was the only user it was very easy to switch to "esearch". But TBH I'll nitpick a lot once I see their code.
<mbj>
The good part of their gist was connection pooling and failover, but I could also add this. And IMHO in a much higher quality.
<mbj>
They teamed up with the author of the tire gem.
<mbj>
It is okay to find someone in the communicty, and most likely I did wrong with showing my arguments about code quality and interface.
<mbj>
My interface is fully functional: cluster.index(:foo).delete etc. cluster.index(:foo) would return an object representing commands on index with name foo.
<mbj>
Without any remote interaction till .delete
<mbj>
I forwarded you an email with discussion I think. I'm not angry about giving the company behind elasticsearch the gem name.
<mbj>
It is theirs, but it just feels stupid to ignore a persons argument and not deliver anything in month :D
<mbj>
They could have payed me, just like the arangodb guys did and I'd already finished that think 3-4 times.
<mbj>
s/think/thing/
<mbj>
Just ranting. Done, feels much better now.
<mbj>
dkubb: Back to code.
<mbj>
dkubb: I repeat that "registry" pattern very often. Just countet I have 5 occurances in my code.
<mbj>
s/countet/counted/
<dkubb>
hehe
<mbj>
dkubb: Do you think we should have a gem for this?
<mbj>
It would provide private registry(whatever) on the singleton tree inheriting from the class including ::Registry
<mbj>
And a public .lookup (on singleton) also.
<mbj>
also a .finalize (freezing).
<mbj>
Shure the code is *only* 40loc, 200 with dm2-style tests, but it is *real* duplication across gems.
<mbj>
My, the attribute to be used should be configurable
<dkubb>
mbj: I just upgraded the rspec dep in git mutant
<mbj>
Our asts code uses #type
<mbj>
where mutant uses #class often
<mbj>
I'm talking about the attribute to lookup from.
<dkubb>
mbj: yeah, it's worth considering. I think we have something like that in ice_nine, and probably axiom-types
<mbj>
So 7 uses.
<dkubb>
mbj: in axiom I use #type, but that's for an axiom-types
<dkubb>
.. type
<mbj>
Interface would be, class HandlerRoot; include Registry.new(:type); end
<mbj>
HandlerRoot.lookup(foo) # foo.type will be used for lookup.
<mbj>
You can implement HandlerRoot.visit etc with lookup.
<mbj>
dkubb: This works via descendants, implicit registration
<mbj>
I prefer explicit registration. Each subclass that is not a base class with abstract behavior explicitly handles a specific case
<mbj>
So this duplication does not touch axiom-types in this case.
<dkubb>
it's a bit open ended in my case
<dkubb>
I can match descendants of classes not yet defined
<dkubb>
I define explicitly which ancestor classes I can handle, but I don't actually always know all the classes up-front
<mbj>
I also think ice_nine does some tricks via superclass walking.
<mbj>
So we'd have to override .lookup (or equivalent) if we use that registration lib for axiom-types or ice_nine
<mbj>
Yeah, I'll have the same problems with any future mutant plugin
<mbj>
dkubb: nice, I'll pull and use that new syntax.
<mbj>
This will force all beta users to switch to beta rspec too, but this is not a problem IMHO.
<mbj>
I'd love to do a new stable release of mutant prior eurucamp.
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
<dkubb>
it's actually a stable rspec now
<dkubb>
so it's not like we're forcing anything unstable on people
<dkubb>
other than parser
<dkubb>
which we need to
<dkubb>
mbj: do you mind doing a new mutant beta release with the rspec changes? then I can update devtools to use the latest rspec
<mbj>
dkubb: I'm very close to push --fail-fast support.
<mbj>
dkubb: But if you need a release now, I'm happy to do it.
<dkubb>
mbj: it's ok, I'm in the middle of housework so it's not like I need it now or anything
<dkubb>
mbj: I just stop in, hack for about 10 mins, and then move onto the next thing
<dkubb>
mbj: --fail-fast would be awesome
<dkubb>
mbj: after that, what else do you think you need feature wise before you go for a stable release?
<mbj>
dkubb: hehe, I know that "volatile working" style :D
<dkubb>
mbj: heh, I get bored otherwise. I hate doing house/yard work. I'd much rather be hacking. so what I do is reward myself with 10 minutes if I can get X done
<mbj>
dkubb: I'd love to replace strategies with "load the rspec world and select specs via description"
<mbj>
dkubb: Good strategy!
<dkubb>
mbj: do you think that could come in a 0.4 release? it sounds like a large change
<mbj>
dkubb: depends :D
<mbj>
I receive lots of feedback about mutants accessbility
<mbj>
*accessibility
<dkubb>
oh yeah?
<mbj>
Because of --rspec-dm2 is the only *fast* solution.
<mbj>
And --rspec-unit is too sloow
<dkubb>
--rspec-unit is slow on all but the simplest of projects
<mbj>
yeah
<dkubb>
I would categorize our ruby libs in the "simple" category
<dkubb>
even virtus
<dkubb>
maybe not axiom, but only because I need to break it down
<mbj>
Also --rspec-dm2 has bad reporting
<mbj>
(not talking about mutants reporting)
<mbj>
I'm talking about what happens if a specific spec file cannot be found.
<mbj>
I think selection via description is close to perfect. Later we could also support select via metadata.
<mbj>
This would also fix all the "each mutation parses spec/**/*.rb again in killfork"
<mbj>
I expect a significant speedup from this.
<dkubb>
I wonder if it would be possible to fork multiple processes at once
<dkubb>
or even just "pre-fork" something and then wait to run it until the previous one has finished
<mbj>
dkubb: Yeah it is possible, and I'll do this.
<mbj>
Once I have all low hanging fruits.
<dkubb>
if you're always keeping a pool of 4 processes going, then the startup costs will be near 0
<dkubb>
there's overhead in terms of complexity of course
<mbj>
I'll use a PORO lib such as celluloid for this.
<mbj>
Initially I played around with zmq, but this needs C extensions.
<mbj>
s/celluloid/something-that-helps-me-here/
<mbj>
celluloid is only about threads AFAIK
<dkubb>
I think forking, and then using IPC would be pretty simple
<mbj>
jo, handwriting it is also an option.
<mbj>
and most likely I'll end up there
<dkubb>
yeah
<dkubb>
I think I might try it by hand first just to understand it
<mbj>
Because you know, I bitch to much about 3rd party code.
<dkubb>
especially since it's not like normal concurrency programming
<mbj>
I did lots of IPC in my C days, I think I can handle this.
<dkubb>
you're basically throwing away a child after you use it
<dkubb>
the main thing is just keeping the pool large enough so that when the next mutation runs it doesn't have to wait for a process to startup
<mbj>
Serializing the mutation for consumption inside the child will be easy.
<dkubb>
yeah
<mbj>
Use use marshal.
<dkubb>
I was thinking the parent process could tell the child "ok, here's your mutation"
<mbj>
Maybe preforking will not be needed at all.
<dkubb>
assuming we don't do full-on and run them in parallel
<dkubb>
I guess forking startup time is really low
<mbj>
I'll go with a simple map ofer mutations and fork/join childs per subject.
<mbj>
s/ofer/over/
<dkubb>
well, I guess it's probably not 0, because otherwise other apps wouldn't pre-fork
<mbj>
So if a subject has 40 mutations I'll walk over this mutations with an n-forks window.
<mbj>
But the apps that do preforking will reuse a forked child.
<mbj>
and NOT kill them after each request.
<mbj>
Also most preforking apps do get feed by the socket, wich is NOT actively managed by the parent.
<mbj>
dkubb: Hah, just found a nice way to implement --fail-fast without doing throw/catch
<mbj>
Still looks a little bit "dirty" but I'm happy.
therabidbanana has joined #rom-rb
<mbj>
dkubb: released mutant-0.3.0.beta15 with --fail-fast