<travis-ci>
[travis-ci] rom-rb/devtools#17 (master - b2117e9 : Markus Schirp): The build has errored.
<dkubb>
good afternoon
<dkubb>
solnic: that's awesome, I'll check it out
<dkubb>
solnic: I'll probably start beefing it up for personal dev, so I can do all my oss work in it if that's ok with you
<mbj>
dkubb: hola!
<mbj>
dkubb: I released mutant-0.3.beta4 with all our latest fixes.
<mbj>
dkubb: I also released adamantium-0.0.8 with ice_nine-0.8.0 dependency.
<dkubb>
sweet
<dkubb>
ahh, thanks for that
<dkubb>
when you used gem-release do you use the "tag" option?
<dkubb>
mbj: I'll test that gem against my other projects
<mbj>
dkubb: forgot to make a tag, I normaly do.
<dkubb>
no worries
<mbj>
mom
<dkubb>
I was thinking about making something that could retroactively tag gems
<mbj>
done
<dkubb>
it would have to download the gem and then find the point in the git history when it matches the source the closest, and then add the tag to it
<solnic>
dkubb: yeah sure
<dkubb>
I have a bunch of gems where I've forgotten to tag properly
<mbj>
dkubb: I think this is wasted time!
<mbj>
Dont see a value.
<mbj>
Maybe tagging the latest release of each major branch
<mbj>
And this exact by hand.
<dkubb>
solnic: I was going to make a vm for bloomcrush, but it'd be nice to have something unified and simple. I doubt there'll be any conflicting deps. I generally would follow the same approach on my oss projects as for personal/work projects. only ths oss vm is going to have *more* deps than I would normally run, because it needs to have multiple rubies and datastores
<dkubb>
mbj: I do see some value in being able to find a specific version via a tag
<dkubb>
mbj: but yeah, it would only be done if it was to fix some kind of pain
<mbj>
dkubb: I'll adopt that vm also, but I'll try to use lxc.
<mbj>
dkubb: If you have an inexact tag this creates major debugging pain
<mbj>
dkubb: So just tag the latest release of each major branch (semver heads).
<mbj>
And this by hand.
<dkubb>
yeah, lxc looks neat
<dkubb>
I don't have any specific use cases for it right now
<mbj>
virtualbox is pain
<mbj>
And consumes far more resources than lxc.
<mbj>
I dont need a full operation system.
<dkubb>
but I wonder if it'd be nice for separating each service into a container
<mbj>
A systemcall isolation is IMHO enough.
<dkubb>
I run vagrant/virtualbox since I'm on osx
<dkubb>
so no lxc
<mbj>
jo, I see
<dkubb>
but once I'm in the vm I may look at lxc
<mbj>
I use some "handgrown" lxc scripts currently.
<mbj>
Works, but is pain.
<mbj>
Did not made it into something easy to reuse.
<dkubb>
vagrant is dead simple to use once you get it setup
<dkubb>
I can do it. I've been working in a vm full time for the last year
<solnic>
we should remember about tagging
<mbj>
yeah, I also used vagrant, but that was on my underpowered box
<mbj>
Was to heavyweight for my machine.
<solnic>
I really don't like when ppl don't tag releases
<mbj>
solnic: I did not tagget the mutant betas :(
<mbj>
But I'll tag the nonbetas.
<mbj>
The betas are for internal consumption in hour ecosystem.
<solnic>
yeah final releases are more important
<solnic>
I guess skipping pre-preleases is ok
<dkubb>
I actually think it wouldn't be too hard to match up source with git releases.. it might be a fun diversion for an afternoon
<mbj>
dkubb: I reduced that mutant crash in Aggregate::Mean.call to (left - right) / foo
<dkubb>
you could do it like git bisect, and do a binary search to find similarities in the text
<dkubb>
mbj: oh really? I wonder if that was with something slightly older in axiom? last night I changed some of the division operations to use a Rational instead, so there shouldn't be any uses of #/ in the source afaik
<dkubb>
either way, it's good to fix it
<dkubb>
mbj: wdyt about exercising unparser/parser by pointing it to something like ruby spec, parsing all the code first, then unparsing it, evaling it, and then running the specs?
<mbj>
dkubb: Yeah it is an older source!
<mbj>
dkubb: Yeah, that will find 99.99% of all edge cases.
<dkubb>
mbj: I'm just trying to think of things that could exercise parser/unparser
<mbj>
I'll do so later!
<mbj>
Would also deserve a blog post, IMHO.
<dkubb>
mbj: maybe a simple runner, where you'd specify a ruby file, it would parse/unparse/eval, and then run the specs in the file
<mbj>
Once done :D
<dkubb>
it seems like a runner like that could almost be a one-liner
<mbj>
yeah
<dkubb>
eval Unparser.parse(Parser.new(File.read path)) or something
<dkubb>
(not sure if that's the api)
<dkubb>
who cares if it loads it's deps in via normal ruby, the point is the spec itself will be run through parser. then you can just do find spec -type f | xargs parser_test.sh
<dkubb>
it might not be particularly fast, but I bet it'd find most of the edge cases like you say
<mbj>
API is: Unparser.unparse(Parser::CurrentRuby.new.parse(File.read(path)))
<dkubb>
it's better than waiting for people to report them
<dkubb>
hehe
<dkubb>
that's pretty awesome btw
<mbj>
dkubb: Yeah, I planned this, but I dont had the time.
<mbj>
I battle tested to_source with this strategy.
<dkubb>
I'm surprised there's no parse_file method, not that it would be particularly hard to use File.read
<dkubb>
oh yeah?
<dkubb>
I didn't know that
<mbj>
But I did not used the result
<mbj>
Just made shure it did not crashed while unparsing.
<mbj>
So 50% of the accurancy.
<dkubb>
that's still a good first-run
<mbj>
I'm limited in time, as always.
<dkubb>
not crashing is basically the first step
<mbj>
Lets say it this way, once I have 0 reproducible problems I'll do that strategy.
<dkubb>
people who want to contribute to ROM could help with this stuff
<dkubb>
tooling is just as important as the actual project
<mbj>
Currently I'm fighting (left - right) / other
<dkubb>
perhaps even more-so, since it's benefits will likely outlast ROM's, and help the whole community
<mbj>
yeah
<dkubb>
not that I don't think ROM is important
<mbj>
I think mutant is a really nice side effect of the project.
<dkubb>
I just see us as a slice of the community. all of ruby needs these tools
<mbj>
Running mutant on axiom
<dkubb>
a web framework built ROM style with mutant will be far more stable than Rails or even Sinatra
<mbj>
I realized web frameworks are far from being hard and bloated.
<mbj>
You need: Routing, uri-generation, a business logic context and presenters and a view layer.
<mbj>
routing and uri generation are inverse from each others
<dkubb>
I think you could break up some of those into related gems
<mbj>
Could be handled via a dedicated library
<mbj>
Yeah, what I'm talking about.
<dkubb>
the problem is everyone just gives up and starts making a monolithic framework because it's easier
<mbj>
In some 'plain rack' projects I used rack-mount
<mbj>
Do not like the code inside, but nice router api.
<mbj>
dkubb: Making a monolitic mutation covered framework is a LOT OF HARDER!
<dkubb>
mbj: does mutant work with ruby 2.0?
<mbj>
jo
<mbj>
dkubb: it does, I develop it under 2.0
<dkubb>
cool
<mbj>
But it does not have a keyword argument mutator, these are nooped for now.
<mbj>
BTW mutant-0.3 finds new mutations also in axiom.
<dkubb>
nice
<dkubb>
axiom is not 100% mutation covered yet
<dkubb>
it's close, but some of those extend issues were blocking me