<exbinary>
dkubb: hi dan, do you have a min. for a yardstick/devtools question if you're around?
<dkubb>
exbinary: sure
<mbj>
exbinary: welcome
<exbinary>
thanks! i'm seeing a disconnect between yardstick and devtools
<dkubb>
what kind of disconnect? is it not running for you?
<exbinary>
gimme a sec to pull up the code, sorry
<dkubb>
from what I've seen YARD's parser is alright at parsing ruby, but it's not perfect
<dkubb>
I kinda wish it were based on whitequark's parser
<mbj>
dkubb: I think it would be easy to convert YARD to parser.
<dkubb>
mbj: parser allows you to reference the comments before a method or block of code, right?
<mbj>
dkubb: parser has a buildin abbility to match comments with nodes.
<dkubb>
nice
<mbj>
dkubb: You get an array of comments, and you can find the associated nodes quite easily.
<dkubb>
I think YARD uses ripper
<mbj>
rippers API is far more ugly than parsers is.
<mbj>
Tried to use ripper for mutant once. And stopped early.
<exbinary>
dkubb: yardstick.rake does `Devtools.project.yardstick.options` to get read the options configured for a specific project.
<exbinary>
then passes them off to yardstick. But the way Config::Yardstick is populating the options, it leaves nils for anything not provided by the user
<exbinary>
these nils seem to trip up yardstick's defaults
<exbinary>
yardstick it uses options.fetch (in lib/yardstick/config.rb) which doesn't take nils into account.
<exbinary>
end result being, in my project with a minimal devtools setup, yardstick does nothing because the 'path' options is never set
<exbinary>
mbj: (thanks for the welcome :)
<exbinary>
dkubb: not sure if any of that made sense, but basically, unless i'm mistaken, i don't think the yardstick rake tasks work with devtools out of the box right now
<mbj>
dkubb: I expect we could port it to whitequark/parser.
<mbj>
dkubb: They seem to do all this stuff to be able to access comments.
<mbj>
dkubb: They have tons of specs for their public behavor.
<mbj>
dkubb: I'd bet porting it to whitequarks parser would be easy and reduce lots of loc. Also accurancy will probably be better.
<exbinary>
dkubb: easiest fix would be to change Devtools::Config::Yardstick#options to simply return a copy of the options loaded from Yaml (`raw`)
<exbinary>
dkubb: that way only the configurations present in the config file would be present in the hash (no nils)
<mbj>
exbinary, dkubb Have to run, cu
mbj has quit [Quit: leaving]
<exbinary>
dkubb: but it could also be handled in Yardstick::Config#defaults= too, i guess
<dkubb>
exbinary: sorry, got called away for a sec
<exbinary>
dkubb: no worries
<dkubb>
exbinary: in general, I like it when code hands the method what it is documented to accept, I don't think the method should have to do lots of assertions or coercions, unless it's part of the documented interface. I have the code proceed as if it got what it expects
<dkubb>
exbinary: so in this specific case, I think it's the rake task that needs to pass in an empty Hash when there is no configuration available
<dkubb>
exbinary: did you want to make a PR to devtools with this fix? I'm curious how many projects this'll expose yardstick difficiencies in :)
<exbinary>
dkubb: sure, that makes sense. it's not just the case of an empty hash though - the problem exists with any one config option that isn't listed in the yaml config
<exbinary>
dkubb: yeah, i was worried about the ripple effect
<exbinary>
dkubb: so if the rake task takes on the responsibility, it would have to go through each option and clean it up.
<exbinary>
dkubb: out of curiosity, why not just return a hash from Devtools::Config::Yardstick#options that only has keys for options that were specified?
<exbinary>
dkubb: is it important for the hash to list all the available options, even if they are nil?
<exbinary>
dkubb: i meant 'even the ones that are nil'?
<dkubb>
exbinary: I think it'll probably be fine to skip ones that are not set
<dkubb>
tbh, not sure why fetch with nil is used there anyway
<dkubb>
I normally would just do raw[name] in that case
<dkubb>
the end result would be the same
<dkubb>
in this specific case, I think it could become: hash[name] = raw.fetch(name) if raw.key?(name)
<dkubb>
I wouldn't worry too much about the ripple effect. any gem that uses devtools should have valid YARD docs, and if they don't I'd want to know about it
<exbinary>
dkubb: ok. i'm happy to send in a PR if you like. which direction do you want to go? fix it in devtools or yardstick?
<exbinary>
dkubb: in devtools is a small fix, imo
<exbinary>
s/small/smaller
<exbinary>
dkubb: in yardstick, i think it'd have to be something like the following for each option `@threshold = options.key?(:threshold) ? options[:threshold] : 100`
<exbinary>
dkubb: in devtools, i guess i could just change #options to return `raw` (the hash from YAML.load_file)
<exbinary>
dkubb: oh, sorry - i missed your msg at 20:01. that makes sense. ignore the rest.
<exbinary>
dkubb: i'll send in a PR. and thanks for all the amazing work. can't wait for ROM to takeoff.
<dkubb>
exbinary: thanks!
exbinary has left #rom-rb [#rom-rb]
fphilipe has joined #rom-rb
kleech has joined #rom-rb
fphilipe_ has joined #rom-rb
fphilipe has quit [Ping timeout: 252 seconds]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
fphilipe_ has quit [Read error: Connection reset by peer]
fphilipe has joined #rom-rb
skade has joined #rom-rb
fphilipe has quit [Read error: Connection reset by peer]
fphilipe has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
fphilipe has quit [Ping timeout: 252 seconds]
fphilipe has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
fphilipe has quit [Remote host closed the connection]
fphilipe has joined #rom-rb
fphilipe has quit [Ping timeout: 253 seconds]
kleech has quit [Remote host closed the connection]
fphilipe has quit [Read error: Connection reset by peer]
jfredett-w has joined #rom-rb
fphilipe has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
CraigBuchek has joined #rom-rb
snusnu has quit [Quit: Leaving.]
fphilipe has quit [Remote host closed the connection]
fphilipe has joined #rom-rb
mkristian has joined #rom-rb
fphilipe has quit [Ping timeout: 245 seconds]
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
mbj has joined #rom-rb
snusnu1 has joined #rom-rb
fphilipe has joined #rom-rb
cored has quit [Ping timeout: 252 seconds]
lfox has joined #rom-rb
fphilipe_ has joined #rom-rb
fphilipe has quit [Read error: Connection reset by peer]
fphilipe_ has quit [Remote host closed the connection]
<dkubb>
good morning
jgaskins has quit [Quit: Leaving]
skade has quit [Quit: Computer has gone to sleep.]
<mbj>
dkubb: hi
<mbj>
dkubb: Crystal looks really interesting. Through I dont like the development process.
<dkubb>
mbj: what about it?
<mbj>
dkubb: They are adding API like hell, and dont test it very well. But this could be the chicken egg problem.
<mbj>
dkubb: If I'd build a language implementation I'd focus on beeing able to run each component (regardless how "core" it is) in a sandbox.
<mbj>
dkubb: That sandbox could be a namespace or whatever.
<mbj>
dkubb: So I can test the component.
<mbj>
dkubb: A statement like "Hashes are used inside the compiler so we know if something breaks", while changing hash internals is IMHO not a good sign.
<mbj>
Could all be off the chicken-egg problem impls have.
<dkubb>
yeah, even mutant had that
<dkubb>
s/had/has/
<mbj>
What I like about chrystal: ruby syntax
<mbj>
And strong types.
<dkubb>
type inference?
<mbj>
Yeah
mkristian has quit [Quit: bye]
<mbj>
global type inference. Through I'd just use local / class wide type inference.
<mbj>
I'd probably specify all arguments once my design is done.
<mbj>
Hence I'd love to try an automagically port of some ROM stuff to crystal.
<mbj>
The type hints in the YARD docs should be enough to seed it.
<mbj>
Mostly because my current client killed my "run metrics before push" automatism.
jgaskins has joined #rom-rb
<jgaskins>
good mornin, dkubb
<mbj>
jgaskins: hi
<jgaskins>
mbj: howdy :-)
<dkubb>
jgaskins: good morning
sdelmore has left #rom-rb [#rom-rb]
sdelmore has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
CraigBuchek has quit [Quit: Leaving.]
lfox has quit [Ping timeout: 245 seconds]
fphilipe has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
cored has joined #rom-rb
snusnu has joined #rom-rb
<mbj>
snusnu: hi
lfox has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
lfox has quit [Ping timeout: 246 seconds]
<snusnu>
hey mbj
<mbj>
snusnu: hi
<mbj>
moving home, back in minutes.
mbj has quit [Quit: leaving]
CraigBuchek has joined #rom-rb
lfox has joined #rom-rb
mbj has joined #rom-rb
<mbj>
snusnu: I just released anima-0.2.0 with the #to_h change.
<mbj>
snusnu: The .attributes_hash is GONE.
lgierth has joined #rom-rb
<mbj>
snusnu: For that reason I bumped minor version. (In my mindset 0.x.y versions have semver characteristica shifted right).
mbj has quit [Read error: Operation timed out]
fphilipe has quit [Remote host closed the connection]
fphilipe has joined #rom-rb
fphilipe has quit [Ping timeout: 252 seconds]
mbj has joined #rom-rb
skade has joined #rom-rb
breakingthings has quit []
<dkubb>
mbj: I follow the same convention (re: with semver for 0.x.y versions meaning that interface changes require a minor bump)
lfox has quit [Quit: ZZZzzz…]
cored has quit [Ping timeout: 272 seconds]
<mbj>
dkubb: Lets document it somewhere.
<mbj>
dkubb: If you follow x.y.z prior to 1.0 you run into "major explosion" version numbers.
<mbj>
If I see a lib at 15.2.1 I'm worried.
<mbj>
dkubb: BTW anima crashes 2.1.0
<dkubb>
ruby 2.1.0?
<mbj>
jo
<dkubb>
if i followed semver in a pre 1.0 release I'd probably have 50.x
<mbj>
heh
<mbj>
yeah
skade has quit [Quit: Computer has gone to sleep.]
<dkubb>
mbj: I hit some really weird behaviour in ragel. in one case, ragel wouldn't execute an action when the action is triggered after reading the last character in the stream
<dkubb>
mbj: I found on the mailing lists, they said to append a null character to the stream after eof so that ragel can advance to it and the exit transition can fire
fphilipe has joined #rom-rb
<dkubb>
mbj: I've started writing integration tests for all the explicit scanner and parser behaviour, and then I plan to expand SELECT parsing to get everything.. I'm still moving things around a lot, so it doesn't make sense to unit test it all though
<dkubb>
plus I don't have a strong understanding of the best way to organize things
<dkubb>
I keep moving things back and forth between the scanner and parser, trying to decide how best to divide the work
<mbj>
dkubb: For such domains I try to find a "branch covering corpus" of inputs. Not focusing of the Class level public API.
<mbj>
dkubb: I plan to fully mutation cover all emitters in unparser via Unparser.unparse
<mbj>
NOT theactually Unparser::Emitter public API.
<dkubb>
I think of SQL::Generator::Emitter as if it were a private class
<mbj>
Yeah
<dkubb>
I wish I could make such a thing easily in ruby
<mbj>
We should create a convention.
<dkubb>
YARD has a @private convention for documenting private classes
<mbj>
I'd love mutant would be pointed to the public API of these private classes somehow.
<dkubb>
mutant could use YARD for hints
<dkubb>
it could skip over @api private methods too
<mbj>
I think the "kill expressions" I'm talking about for a such long time will be the perfect solution.
<mbj>
Because the @api private is to less. You need to be pointed to Unparser.unparse
fphilipe has quit [Ping timeout: 246 seconds]
<mbj>
@mutcov tag maybe :D
<dkubb>
@see Unparser.parse
<dkubb>
you can have a method reference another method, which says "my interface is like this other method"
<mbj>
mhh
<mbj>
actually a really good idea.
<mbj>
I think I'll NOT use the YARD API and roll out my own tag scanner.
<mbj>
Less runtime dependencies and only "one parse".
<mbj>
No need to parse once via whitequark/parser and an additional time via ripper.