<snusnu>
hmm, i'm not concerned with the name MethodObject itself i guess, i wonder how to integrate the Public module on demand?
<mbj>
snusnu: IMHO Freestanding is better
<mbj>
include Concord.new(:foo, :bar), MethodObject
<snusnu>
how would that work without the presence of concord, it wouldn't, right?
<snusnu>
then it should be prefixed with the Concord namespace too
<mbj>
class Foo
<mbj>
def initialize(bar, baz)
<mbj>
@bar, @bar = bar, baz
<mbj>
end
<mbj>
include MethodObject
<mbj>
def call
<mbj>
@bar + @baz
<mbj>
end
<mbj>
end
<mbj>
Foo.call(1, 2) => # 3
<mbj>
use without concord ;)
<snusnu>
oh, so you'd want to get at the arity without concord's help?
<snusnu>
or did you think of a generic .call(*args) anyway (i wouldn't like that)
<snusnu>
in any case, concord knows it already
<snusnu>
but i do agree, that it might be useful to use with anima too for example
<snusnu>
so yeah, maybe freestanding is indeed better
<snusnu>
meh, what i don't like tho, is that for proper arity checks, the module needs to be included after #initialize was defined .. kinda disrupting the regular flow of declarations
<mbj>
snusnu: the module cann be included at any time
<snusnu>
altho it might be ok for those (rare?) situations where neither concord or anima are used
<mbj>
snusnu: Because the def self.call(*args); new(*args).call; end will check arity
<mbj>
snusnu: You'll get a clear failure because the initializer will raise anyway.
<mbj>
No need to duplicate arity checks here.
<snusnu>
mbj: you're probably right, it's enough to let #initialize do the arity check, and passing through from .call
<snusnu>
although, the name is "taken" by something more beautiful already, that little gem wouldn't do it justice, heh
snusnu has quit [Quit: Leaving.]
lfox has quit [Quit: ZZZzzz…]
snusnu has joined #rom-rb
<snusnu>
mbj: otoh, maybe the reference to momo is ok, if you know what i mean ;)
<snusnu>
mbj: altho it goes the opposite direction
<snusnu>
mbj: actually, i don't like momo as a name for anything that *saves* time
<snusnu>
:p
cory_ has joined #rom-rb
irclogger has joined #rom-rb
irclogger has quit [Ping timeout: 246 seconds]
<cored>
hello
<snusnu>
hey cored, sorry, didn't have any time for commenting on your PR last night
<snusnu>
is there anything specific you need to know?
<cored>
snusnu: is ok, no worries
<cored>
snusnu: well, I was wondering parting from the code that's already there if there's another thing to be done
<cored>
but there's no such thing as functionality at the moment, I have to make it work extracting the current task implementation for flay
<cored>
and start using mine
<cored>
kinda scare without proper tests, probaly I should ask mutant to just go and fuck my code up
<snusnu>
heh yeah, refactoring devtools is a bit scary as it has no tests at all .. what i'd do, is write tests for the stuff you refactor, and "ensure" everything's still working by simply running it
<snusnu>
no need to write tests that don't belong to the refactoring done in your PR
<snusnu>
once more and more code gets well factored, we might take the time to do a more dedicated testing cycle
<cored>
yes
<cored>
that's what I'm doing
<cored>
my tests are just integration tests
vsorlov has joined #rom-rb
<snusnu>
regarding the state of the PR, i'd just go forward and look how e.g the Flay#call method can be further destructured
<cored>
I don't know exactly what should be the correct assertion at this moment, so that's why I'm planning to go ahead and remove the Task and try to use mine without a lot of changes and part from there
<cored>
that's one of my problem, normally I don't know when is enough, I don't have that type of experience to know that's the code is good already
<snusnu>
i guess it's fine to have unit tests for the stuff you write, and leave out integration testing for now, and just do sanity checks by running devtools manually
<cored>
probably what I need to do is also ask reek/flay/mutant for that
<cored>
snusnu: ok, I will move that then to be more granular in a more unit tests manner and try to make some tests by hand
<snusnu>
that's one way to do it yeah, "but" you can get at it all by yourself with "simply" tackling larger methods with the goal to make them smaller .. cut out chunks that belong together, maybe introduce new objects that seem like nice places to fit the code in, etc
<snusnu>
ideally, you'd try to write immutable objects as much as possible
<snusnu>
you can ping me if you're at a point where you dunno how to make something work without mutating the objects
<snusnu>
immutability is no hard requirememnt, especially not while getting familiar with the code and doing a few initial refactorings
<snusnu>
eventually tho, it should mostly fit with the style we use in other related projects
<cored>
well, at some point I will have to mutate state
<cored>
otherwise the program will be useless, right?
<snusnu>
you probably will have to, but please think hard about it ;)
<cored>
so what we are aiming for is total inmutability of the core objects?
<snusnu>
but yeah, don't think about it as a hard requirement, if you can improve the code with mutable objects, don't hesitate to just do it
<snusnu>
then it leaves us with a situation where we can discuss the introduction of immutability more focused
<snusnu>
cored: eventually, i guess it's safe to say that we aim for as much immutability as possible, altho you're right, there will probably always be mutable places left, i guess the goal is simply to minimize them
<cored>
great
<snusnu>
don't hesitate to start with just what you would do tho .. don't let immutability stop you from improving the code … you/we can always come back later and refactor again
<cored>
I really also aimining to work like that on my own code
<snusnu>
the goal of your PR is to better factor the runner code, with the goal of making it easier to *test*
<cored>
yes
<snusnu>
it might be an interesting experience to do another PR at some point, removing mutabiity as much as possible
<snusnu>
this way, you have more narrow areas to focus on
<snusnu>
and you see the effects of mutability vs. immutability more explicitly
<snusnu>
it really depends on how *you* like to do it tho .. i will definitely not reject improvements just because they use mutable objects ;)
<snusnu>
mbj: ok, looking through whitequark/ast .. i'm starting to realize how using it would allow me to nuke otherwise special cased internal structures
<snusnu>
mbj: re axiom-schema, that is
<snusnu>
mbj: in fact, it's probably really a great generic way to store data collected by DSLs that is then used to build up the target structure using some processor that acts as what we previously mostly did with adhoc builder classes
<cored>
snusnu: well, I will follow you lead, I'm a learning a bunch just doing this PR so it's a win/win
<snusnu>
cored: great! and yeah, just go on refactoring stuff that looks fishy to you, maybe let yourself be guided a bit by tools like reek (i think that it's the most easy to "use" of them)
cored has quit [Ping timeout: 264 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
cored has quit [Changing host]
<mbj>
snusnu: yeah
<mbj>
snusnu: Pls review backlog from yesterday I talked to dkubb about strategies to avoid finalization!
<snusnu>
mbj: i've skimmed through that and i agree
<snusnu>
mbj: the thing is tho, once you want to have the *convenience* of avoiding forward declarations or futures, you're stuck with having to define everything in the proper order
lfox has joined #rom-rb
<snusnu>
mbj: btw, if that works for you, we could probably do a skype call later today evening
<snusnu>
mbj: i probably won't go out tonight, as i already did that yesterday, and will do it again tomorrow :p
<mbj>
snusnu: Took me some cycles to end up with this API.
<snusnu>
mbj: i see, and based on the position in the arglist to #children, you generate a method that accesses the children array at the respective index?
<mbj>
snusnu: Yeah
<snusnu>
nice idea
<mbj>
snusnu: And some more domain specific shugar ;)
<snusnu>
i will look at this in a dedicated refactoring cycle, i need to familiarize myself more with raw ast api before that i guess
knowtheory has quit [Quit: Computer has gone to sleep]
knowtheory has joined #rom-rb
knowtheory has quit [Ping timeout: 240 seconds]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
lfox has joined #rom-rb
vsorlov has quit [Ping timeout: 245 seconds]
breakingthings has quit []
breakingthings has joined #rom-rb
snusnu has quit [Quit: Leaving.]
irclogger has joined #rom-rb
irclogger has quit [Read error: Operation timed out]
jgaskins has joined #rom-rb
snusnu has joined #rom-rb
<jgaskins>
snusnu: hey, did you forget about last night? :-)
knowtheory has joined #rom-rb
knowtheory has quit [Client Quit]
knowtheory has joined #rom-rb
knowtheory has quit [Client Quit]
postmodern has joined #rom-rb
mbj has quit [Ping timeout: 246 seconds]
cored has quit [Ping timeout: 252 seconds]
mbj has joined #rom-rb
snusnu has quit [Quit: Leaving.]
<mbj>
postmodern: Heh, did saw the diff for that MRI issue. Just *expected* it to be more MRI-C-Magic ;)
<mbj>
postmodern: Probably my guess was correct.
<mbj>
postmodern: Parsers should be fuzzed, IMHO.
<mbj>
postmodern: Still thinking hard how to mutation cover a parser ;)
<postmodern>
mbj, totally, input fuzzing probably ended up triggering the bug
jgaskins has quit [Quit: This computer has gone to sleep]
<postmodern>
mbj, PHP had a similar bug too
<mbj>
postmodern: That PHP one is around 12 years old?
<postmodern>
interested in the idea of replacing the complex bits of MRI with Rust/Go
<mbj>
postmodern: *month
<mbj>
postmodern: +1
<mbj>
I switched a smal "play/embbedded" project to rust already.
<mbj>
Lots of FUN. And feeling much better now :D
<postmodern>
nice
<postmodern>
yeah i like the idea of having a smarter compiler and semantics
<postmodern>
while memory mapped languages are fun, you can really shot yourself in the face with them
<mbj>
Personally I'd not write C anymore.
<mbj>
Rust just *looks* as a good successor.
<mbj>
But I dont write that much C anymore these days. So my POV is weak.
<mbj>
postmodern: Lets write a mutant for rust ;)
<mbj>
Best way to learn a language/runtime: Make a mutation tester for it.
<mbj>
:P
<postmodern>
mbj, that's what i was wondering, how difficult it would be to implement mutators/fuzzers for rust
<postmodern>
mbj, it's LLVM based, so couldn't be too hard?
<postmodern>
mbj, also they expose the parser via libsyntax
<dkubb>
you could mutate the LLVM IM couldn't you?
<mbj>
postmodern: An AST or bytecode based mutator?
<mbj>
postmodern: AST mutators have the advantage of a nice diff ;)
<dkubb>
then anything that LLVM works with could be mutated
<mbj>
postmodern: Bytecode based mutators have better granularity.
<mbj>
postmodern: But a full covering AST mutator is already LOTS of work.
<postmodern>
how much flexibility do Rust's semantics give you? how many mutation options might you have for a simple statement?
<mbj>
dkubb: The LLVM IR makes it unable to generate a diff.
<dkubb>
whops, I meant IR
<dkubb>
mbj: I guess it loses information
<mbj>
dkubb: yeah
<mbj>
dkubb: Also some IRs you can generate do not have a valid code input.
<mbj>
postmodern: Rule of thumb, each node has "semantically adjacent and less powerfull" replacements.
<mbj>
postmodern: Also the obvious ones literals / control flow etc.
<dkubb>
mbj: it's the same thing with any mutator, you can create an AST that cannot be created in the normal language
<mbj>
postmodern: I think we can easily get 50+ mutation operators.
<mbj>
dkubb: Its easier to follow the languages rule with AST based mutators.
<dkubb>
it's too bad there wasn't some kind of specification defining standard labels for each mutation
<mbj>
dkubb: Also there is no clean bytecode => AST conversion. To show a diff a programmers brain can work with.
<mbj>
dkubb: In mutant?
<mbj>
dkubb: We could easily add it.
<mbj>
dkubb: But coming up with the label values would be hard.
irclogger has joined #rom-rb
<dkubb>
mbj: well, I was thinking if there were unambiguous names for things, then other libs could use the same terminology
<dkubb>
mbj: once there's a shared vocab, then it's easier to jointly develop new operators
<mbj>
yeah
<mbj>
dkubb: We can define one. Need to make an index of all mutation operators in mutant anyways.
<mbj>
dkubb: Just for my personal "dick size war" - moments ;)
<dkubb>
mbj: sort of like what whitequark did in his AST doc
<mbj>
dkubb: yeah
<dkubb>
mbj: name each operator, and then contact other developers to see if you can work on standardizing things
<mbj>
dkubb: why not.
<postmodern>
before we write a mutator for Rust, I'd just be interested if rewriting parts of MRI in Rust would actually prevent bugs
<postmodern>
also something like QuickCheck for Rust would be cool
irclogger has quit [Ping timeout: 252 seconds]
<mbj>
yeah
<mbj>
postmodern: As always I'd love to get my hands dirty. But OSS time is limited ;)
<mbj>
postmodern: You remember that ducktrap thing I use as an "XSD for params-hash/json/yaml", currently rewriting it.
<dkubb>
why rust specifically?
<dkubb>
aren't there other, more stable languages, with much longer proven track records at stability?
<mbj>
dkubb: Its IMHO a good C successor, and can work like a plugin replacement.
<dkubb>
not bashing rust, just wanting to understand what makes it better than others
<mbj>
There are some other stable languages, but IMHO they would not be pluggable as easy.
breakingthings has quit []
<mbj>
Rust supports foreign calling conventions very easily.
<mbj>
ABI wise.
bf4 has joined #rom-rb
bf4 has quit [Read error: Operation timed out]
adkron has quit [Ping timeout: 248 seconds]
snusnu1 has joined #rom-rb
irclogger has joined #rom-rb
<dkubb>
mbj: in mutant, if I have a spec that covers a specific module's behaviour, will it be picked up under module_spec.rb ?
<dkubb>
mbj: I have a module that I want to test the inclusion behaviour for, but I don't want to make a file like module/class_methods/included_spec.rb .. making spec files for private methods is a smell imho
lfox has quit [Quit: ZZZzzz…]
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<mbj>
dkubb: The file name based selection strategy was removed.
<mbj>
dkubb: Mutant finds specs to kill mutations only via the rspec description.
<mbj>
dkubb: So if you have "Lib::SomeModule#foo" you need a test with this rspec description metadata.
<mbj>
describe Lib::SomeModule, '#foo' do
<mbj>
...
<mbj>
end
<mbj>
dkubb: I plan to ditch all this stuff and support a "kill expression2.
<dkubb>
mbj: if I have describe Lib::SomeModule will it be used to kill mutations inside Lib::SomeModule.included ?
<mbj>
dkubb: no
<mbj>
describe Lib::SomeModule do
<mbj>
describe '.included'
<mbj>
will do
<mbj>
or describe Lib::SomeModule, '.included' do
<mbj>
these both are equivalent.
<dkubb>
ahh ok
<dkubb>
I don't like to have describe blocks for private methods
<dkubb>
would you accept a patch to make it so it fallsback to running describe blocks for the module only?
<mbj>
dkubb: lets solve this stuff finally via kill expressions
<mbj>
dkubb: kill expressions will allow to describe a mutation-subject - killing-test relationshop
<mbj>
*relationship
<dkubb>
how do you see those looking?
<mbj>
Externally via a configuration file
<mbj>
I'm not sure
<mbj>
had serveral ideas already.
<dkubb>
the describe stuff works alright though
<dkubb>
aside from this specific issue
<mbj>
not totally
<dkubb>
what problems do you have with the current strategy?
<mbj>
there are some domains that have lots of code that is exposed via a single public interface.
<mbj>
for example unparser.
<mbj>
I expect all mutations can be covered via Unparser.unparse
<mbj>
Especially for a lib that introduces mutation coverage these kill experessions will be really handy.
<mbj>
I love to spec the public interface of a Class/Instance
<dkubb>
what about using TracePoint and automatically associating each example with the code it touches?
<mbj>
also a good idea
<dkubb>
that'll allow pinpointing mutations
<mbj>
Its about implicit vs explicit coverage.
<dkubb>
and it'll allow any spec organization method people wish
<mbj>
yeah
<dkubb>
I will probably continue to do things the way I do though for normal classes
<dkubb>
I like that a method's unit test fully covers that unit
<mbj>
yes
<dkubb>
I don't care about implicit coverage
<mbj>
Same here
<mbj>
but I wanna have something "in between" while I create explicit coverage.
<mbj>
going from full implicit coverage to full explicit coverage is more easy than from nothing to explciit.
<mbj>
That kill expression thing is an algebra systhem (that does not exist currently)
<mbj>
That allows to define how to select tests.
<mbj>
For a given subject.
<mbj>
So your edge case could be perfectly definded.
<mbj>
And people can also go for full implicit coverage via trace points ;)
<mbj>
dkubb: I'm thinking about a longest prefix match algorithm.
<dkubb>
mbj: oh interesting
<dkubb>
mbj: so most specific match
<dkubb>
mbj: I think that would work well for most current purposes
kenphused has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
bf4 has joined #rom-rb
bf4 has quit [Ping timeout: 248 seconds]
adkron has joined #rom-rb
<mbj>
dkubb: Yeah you define a set of mutation matchers
<mbj>
dkubb: subject matchers, and the action to take.
<mbj>
dkubb: So you could also mix rspec and test unit in the same project ;)
<mbj>
dkubb: it would allow solnic to use his strategy (the implicit one)