<snusnu>
dkubb: interestingly, your suggestion re #constructor as an instance method raises a ruby warning about initialize_instance being an lvar that is assigned but never used
<snusnu>
dkubb: heh, sorry, even more interestingly, that only happens when i use the def syntax inside the Module.new block
<snusnu>
dkubb: your suggestion works
<snusnu>
dkubb: and i like it! it captures the intent better than jumping around explicitly between class and instance scope
<snusnu>
dkubb: otoh, thinking about it again .. it's somewhat obscure too, introduces a new lvar, and doesn't get rid of the "other" lvar in #define_initialize
<snusnu>
dkubb: also, having the class utility method in this case seems quite ok too
<snusnu>
dkubb: so i guess i'm gonna keep the version in current master
<dkubb>
well, with def you probably can't reference lvars
<dkubb>
with define_method you can, because it's still in scope in the block
<snusnu>
yeah
<dkubb>
snusnu: you know what I would suggest doing, create an InstanceMethods module (or whatever name), put a normal initialize method in it, and then include that from define_initializer. no need to make an anonymous module for something that doesn't need state
<dkubb>
snusnu: also, I would recommend using descendant instead of scope within #included and related methods. it's more consistent with other code we have in the ROM ecosystem, and (IMHO) it's easier to understand what you're doing
<snusnu>
dkubb: heh yeah, i agree with both suggestions ;)
<snusnu>
dkubb: it's funny, when i stepped into that code, i kinda followed the current layout rather blindly
<dkubb>
snusnu: oh, I was just saying fat fingering the keys isn't that common, at least not for me
<dkubb>
snusnu: why is .initialize_instance available through anima, attributes_hash is not? I would think they should be consistent
<dkubb>
snusnu: I know you didn't write the code, I was more making a statement
<snusnu>
dkubb: ok :) i guess i still don't really get it tho, especially the part about only doing the checks conditionally .. where do you see an opportunity for that?
<dkubb>
I would make the decision on whether or not the methods should be added to the class or not.. my gut feeling is that it will be unlikely for you to want to do: User.initialize_instance(user, attributes) or User.attributes_hash(user) .. so I would think they should both be through self.class.anima
<dkubb>
or through a private #anima instance method that itself delegates to self.class.anima
<snusnu>
dkubb: lemme check on .initialize_instance and symmetry there
<snusnu>
dkubb: i'm actually planning another refactoring, introducing a MethodBuilder that gets initialized with scope (or rather, descendant), and does the job of defining
<snusnu>
dkubb: i don't like passing descendant around that much
<dkubb>
yeah, that's a good idea
<dkubb>
when you have the same argument to a bunch of methods it's a sign you're missing an object
<snusnu>
yeah
<snusnu>
dkubb: in fact, i will move most of the code to that builder object .. the anima proxy itself should be as slim as possible, and only provide methods useful for anima *operation*, not building it up
<snusnu>
dkubb: it's a bit "weird" to use a builder object to build a module builder, but oh well ;)
snusnu has quit [Ping timeout: 240 seconds]
snusnu1 has joined #rom-rb
snusnu1 has quit [Client Quit]
snusnu has joined #rom-rb
<dkubb>
snusnu: it's not that weird
<lgierth>
not too weird (=abstract) for the abstraction level of anima's use case
<snusnu>
dkubb: also, i agree that both #initialize_instance and #attributes_hash should only be accessible via infected_instance.class.anima, but there's a lot of code depending on #attributes_hash as it was the only way to get at the hash prior to me adding #to_h earlier today
ezkl has quit [Quit: QUIT!]
ezkl has joined #rom-rb
ezkl has quit [Client Quit]
ezkl has joined #rom-rb
ezkl has quit [Quit: QUIT!]
ezkl has joined #rom-rb
<snusnu>
dkubb: what is the actual motivation behind rubocop discouraging the use of raise in favor of fail ?
<dkubb>
snusnu: I believe it's that with raise you have an expectation of catching and recovering from the error, with fail you generally are propagating it up to the top
<snusnu>
dkubb: ah right! thx
<snusnu>
dkubb: ok, i pushed a few more commits to anima, including silencing the rubocop
<snusnu>
dkubb: if you have see any "low" hanging fruits lemme know ;)
<dkubb>
snusnu: I can see one, you could use instance_exec instead of class_eval, and pass through the args to the inner block, thus removing the need for an lvar to be defined in the outer scope
<dkubb>
I don't know if overall it'll be a lowering of complexity
<dkubb>
but it may be worth trying to see if you like the results more. it'll allow you to cut out stuff like names = @names
<dkubb>
and instead you'd do descendant_eval(@names) { |names| names.each { |name| attr_reader(name) } }
<dkubb>
you could do: descendant_eval(@names) { |names| include Equalizer.new(*@names) }
<dkubb>
er, I mean *names there instead of *@names
<snusnu>
interesting, lemme check that
<snusnu>
dkubb: that gives an increase in flay score by 2, but i like it
<snusnu>
dkubb: pushed
jgaskins has quit [Quit: This computer has gone to sleep]
<snusnu>
dkubb: i could probably remove equalizer in the example by not relying on #eql? in the code examples further down ;)
<snusnu>
dkubb: do you think it's worth it tho?
<snusnu>
dkubb: i like the clarity and succinctness of the #eql? comparisons at the bottom of the readme
<dkubb>
snusnu: what about the symmetry between #initialize and #to_h, do you think they should both use self.class.anima?
<dkubb>
snusnu: does the code require #eql? to function?
<snusnu>
dkubb: no the code shouldn't/doesn't require #eql? to function .. afaict i only need equalizer in the readme example because of the #eql? checks at the bottom of the code examples
<dkubb>
snusnu: you could define #== methods that just does: to_h == other.to_h
<dkubb>
snusnu: you could also maybe remove the attr_reader
<dkubb>
snusnu: I wonder if OpenStruct provides something that could be used
<snusnu>
dkubb: ok, fixed the symmetry issue for #initialize and #to_h
lgierth has quit [Quit: Ex-Chat]
<snusnu>
dkubb: OpenStruct.to_h returns nil at least in 1.9.3
snusnu has quit [Quit: Leaving.]
zekefast has joined #rom-rb
Gibheer has quit [*.net *.split]
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
zekefast has quit [Ping timeout: 252 seconds]
zekefast has joined #rom-rb
zekefast has quit [Quit: Leaving.]
Gibheer has joined #rom-rb
zekefast has joined #rom-rb
kleech has joined #rom-rb
mbj has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
kleech has quit [Ping timeout: 246 seconds]
kleech has joined #rom-rb
ezkl has quit [Quit: QUIT!]
zekefast has quit [Quit: Leaving.]
snusnu1 has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
snusnu1 has joined #rom-rb
kleech has quit [Ping timeout: 272 seconds]
kleech has joined #rom-rb
jgaskins has joined #rom-rb
breakingthings has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
CraigBuchek has joined #rom-rb
snusnu has joined #rom-rb
<snusnu>
yo mbj
irclogger__ has joined #rom-rb
<mbj>
snusnu: jo
<snusnu>
mbj: happy with the anima refactorings?
<snusnu>
mbj: it looks rather different now ;)
<mbj>
snusnu: dunno, no time to take a look.
<mbj>
snusnu: BTW having the ability to define an own #initialize is AFAIK an anti feature.
<mbj>
snusnu: Tought about this a bit.
<mbj>
snusnu: animas are data capsules
<mbj>
snusnu: if you need to do $crazy_stuff in #initialize you'd need to refactor IMHO.
<snusnu>
i don't agree
<mbj>
snusnu: I'd think such stuff makes sense for concord.
<snusnu>
it's one thing wether your app should be refactored, but it's another to hijack #initialize, leaving no way to modify it without monkey patching and thus duplicating functionality
bf4 has joined #rom-rb
<snusnu>
it surely is nothing that will ever hurt anima client code
<snusnu>
even if it's never used
<mbj>
snusnu: Do you have a valid use for hickacked #initialize? Pls show me.
<snusnu>
not now
<snusnu>
but really, you still need to tell me why you're opposed
<snusnu>
i've seen no strong reasons so far
<snusnu>
btw, imo it depends on where anima is used
<snusnu>
if you use it as data capsules in a rom context, i agree, why would you need to do that
<snusnu>
but outside of that use, where you purely want the convenience it adds, why not allow nicer callsites by supplying an #initialize which stuffs in default values
<snusnu>
iirc i did that somewhere around my cookie code in our app
<snusnu>
can't show you the exact place right now, but i will take a look at it later
<snusnu>
in any case, i see absolutely no harm in having that possibility
<snusnu>
and really, it doesn't complicate the code either, especially not with the latest refactorings
<mbj>
snusnu: I'm not angry. I just questioning to add a feature / complexity to a code base when there is no real use case.
<mbj>
Proactive features is something bad, IMHO.
<snusnu>
i know you're not angry
<snusnu>
but you'd have to show me the complexity it adds
<snusnu>
and you'd probably need to take the time to look through the new refactored code
<snusnu>
so let's say it like this .. let's discuss this again once you looked through that code :p
<snusnu>
also, it wasn't proactively added … i USED it in my app before adding it to anima proper
<mbj>
snusnu: All features we have to tests are complexity ;)
<snusnu>
that's too puristic for me
<mbj>
snusnu: But why you have to *use* it in your app?
<snusnu>
not now dude
<snusnu>
not now
<snusnu>
it's convenient
<mbj>
snusnu: Sure there isnta better way?
<snusnu>
and it doesn't complicate
<snusnu>
there is *always* a better way
<snusnu>
;)
<snusnu>
the thing is this: anima implementation itself is simpler, since now it simply includes a module with static instance methods for infected classes
<snusnu>
the very fact that this is simpler than it was before, justifies it imo
<snusnu>
imo if we actually do not want to support that usecase, it's just a sideeffect of simplified code
<snusnu>
mbj: get my point?
<snusnu>
sry if i sound stubborn on this, but i really see no harm
<snusnu>
as i said, it actually just fell out of the design
jgaskins has quit [Quit: This computer has gone to sleep]
jgaskins has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
zekefast has joined #rom-rb
kleech has quit [Ping timeout: 246 seconds]
kleech has joined #rom-rb
cored has joined #rom-rb
snusnu has quit [Quit: Leaving.]
zekefast has quit [Ping timeout: 240 seconds]
snusnu has joined #rom-rb
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
breakingthings has quit []
<dkubb>
good morning
kleech has quit [Remote host closed the connection]
zekefast has quit [Quit: Leaving.]
zekefast has joined #rom-rb
breakingthings has joined #rom-rb
CraigBuchek has quit [Quit: Leaving.]
snusnu has joined #rom-rb
CraigBuchek has joined #rom-rb
mbj has quit [Ping timeout: 244 seconds]
Eiam has quit [Quit: ╯°□°）╯︵ǝpouǝǝɹɟ]
<snusnu>
hey dkubb
<snusnu>
thx for the further simplifications in anima!
<snusnu>
i just pushed another tiny one
Eiam has joined #rom-rb
<dkubb>
snusnu: yeah, I saw those and I figured it was just easier to do them than comment on it
jgaskins has quit [Quit: This computer has gone to sleep]
<snusnu>
dkubb: i'm rather happy with anima now, i mean, i was already before, but yeah, imo the codebase is much nicer now
<dkubb>
snusnu: I thought about moving that Methods module out into it's own file, and directly under the Anima namespace, since it's not strictly related to the builder code
<dkubb>
there's also a few mutations to kill, but nothing huge
vsorlov has joined #rom-rb
<snusnu>
dkubb: yeah, moving that module somewhere else might be ok
<snusnu>
dkubb: however, that'd require integration test changes that i'm not entirely sure how to do with having only an anonymous class
<snusnu>
dkubb: the thing is, if someone uses an anonymous class, as long as he/she doesn't provide a .name method, the error message will always be somewhat useless (given that an anonymous class' .name is nil)
<snusnu>
dkubb: i'm wondering how common that would be
<snusnu>
this looses the possibility for meaningful error messages with anonymous classes, but it kills a mutation ;)
<snusnu>
and i srsly doubt that anonymous classes are the golden path in anima usage anyway, they mostly seem to happen in specs
<dkubb>
I think that's fine. I don't use Class#name much explicitly, I just use Class#to_s implicitly like this
<snusnu>
yeah me too, but i couldn't find a way to overwrite #to_s in an anonymous spec class
<dkubb>
it'll do the right thing with a named class, and for an anonymous class it'll return the object address, which is fine I think
<snusnu>
yeah
<snusnu>
i think so too
<dkubb>
I rarely define .name for anonymous classes
<dkubb>
we only do it in specs, like you said
<snusnu>
me neither, i *only* saw it in specs so far, right
<snusnu>
ok pushed
knowtheory has joined #rom-rb
<dkubb>
snusnu: I like that you've moving anima towards exposing less internal state
<dkubb>
like in that instance_variable_name change
<snusnu>
yeah, make it as slim as possible
<snusnu>
i like that ;)
<snusnu>
dkubb, mbj: btw, just killed the last remaining mutations, anima is green now
<dkubb>
nice!
kleech has joined #rom-rb
<snusnu>
heh, it's funny, after adding that #to_h support, i got into refactoring mode (thx to you dkubb) .. it got kinda addictive, and with such nice small libraries, a few hours can have awesome impact
<dkubb>
snusnu: yeah. when I follow the Boy Scout rule (always leave the code cleaner than how you found it) this happens to me too
<dkubb>
snusnu: if the code is well tested, then there's no reason not to spend a bit of time cleaning it up and refactoring
<snusnu>
absolutely, sometimes i'm like, nah, i can't be bothered with this atm, but when i actually overcome that initial hurdle, it's always fun
<snusnu>
as in last night, it was exactly the right thing to do … too tired for work, bored with anything else, so yeah ;)
<snusnu>
it is indeed a rather weird and long dump :p
<dkubb>
I'd be curious to see what the mutation looked like that caused that
kleech has quit [Remote host closed the connection]
<snusnu>
yeah, and i'd also like to see the reason for the noop failure a few specs "above"
cored has quit [Ping timeout: 272 seconds]
jgaskins has joined #rom-rb
<snusnu>
hey jgaskins, i'm really sorry, but i won't have time tonight :/ .. there's a table tennis tournament i have to join today evening, and that might very well end late .. because, to be exact, it's not only tabletennis, but turntabletennis ;) .. meaning that there's a DJ too, the whole thing happens in a club ;)
<snusnu>
jgaskins: i'd love to find another day that works for both of us tho!
<jgaskins>
snusnu: all good. :-) same time next week?
<snusnu>
jgaskins: fine with me!
<jgaskins>
snusnu: perfect. see ya then!
<snusnu>
alright!
<mbj>
snusnu: I like it!
<mbj>
snusnu: Thx for cleaning up my stuff.
<mbj>
snusnu: No public interface change? - Lets release?
<snusnu>
mbj: cool! yes please! .. and no, no public interface changes afaik
<snusnu>
mbj: can you do the release? i have to go now
<mbj>
snusnu: np
<mbj>
snusnu: I'll do
<snusnu>
cool thx
<snusnu>
dunno, maybe ducktrap too?
<mbj>
snusnu: mhh
<mbj>
snusnu: BTW I consider anima as "feature compleate".
<mbj>
snusnu: No need to add a single dime anymore.
<snusnu>
mbj: i updated it to work with anima's #to_h .. but i'll leave the decision to you, it's not that urgent for me
<snusnu>
mbj: agreed
<mbj>
anima is just another self contained building block.
<snusnu>
mbj: there's one more refactoring dkubb pointed out .. the Builder::Methods module could be moved out of that namespace
<mbj>
snusnu: Feel free to work through concord also ;)
<snusnu>
but it's probably not that important
<snusnu>
mbj: hehe
<mbj>
dkubb, snusnu: Sorry for my absence when you both improved my code.
<snusnu>
mbj: well let's see .. it's even smaller tho, so i might just get around to it sometime soon
<snusnu>
mbj: i suppose you have a different mutant then, compared to me and travis
<snusnu>
feel free to fix, and push your mutant changes ;)
<mbj>
snusnu: no
<mbj>
snusnu: my MRI does not crash, where the MRI does.
<mbj>
the MRI in jenkins
<snusnu>
i don't follow, you're talking about the crash on 2.0.0?
<snusnu>
you see alive mutations instead?
<mbj>
snusnu: IMHO yeah.
<snusnu>
mbj: in any case, it might be a good idea to kill the mutations locally, and push that to anima master?
<mbj>
snusnu: yeah
<mbj>
snusnu: I'll try.
<snusnu>
i've not yet tried to replicate the 2.0.0 bug on my box, and i don't have time anymore .. so good luck!
<snusnu>
will check it out once i come back from turntabletennis ;)
<snusnu>
have a good evening guys, i'm off
snusnu has quit [Quit: Leaving.]
vsorlov has quit [Ping timeout: 248 seconds]
snusnu has joined #rom-rb
vsorlov has joined #rom-rb
cored has joined #rom-rb
<snusnu>
mbj: fwiw, i just ran mutant on my 2.0.0-p247 and i get no crash either, but the same 2 alive mutants you get
<snusnu>
dkubb: ^^
<dkubb>
hmm
<dkubb>
I'll run with master now
kleech has joined #rom-rb
<dkubb>
snusnu: I only see one noop failure for Anima::Attribute#load
<snusnu>
dkubb: and no crash?
<snusnu>
dkubb: because there's a noop failure on travis too
vsorlov has quit [Ping timeout: 246 seconds]
<dkubb>
no crash
<dkubb>
oh wait, 1.9.3, I'll do 2.0.0 now
kleech has quit [Remote host closed the connection]
<dkubb>
2.0.0 runs perfectly
<snusnu>
lol that's weird
<snusnu>
dkubb: mbj and myself get different behavior from travis, and you get still another behavior
<snusnu>
dkubb: fwiw, i'm on mavericks
<dkubb>
haha
<dkubb>
I thought about setting up a vm for testing
<mbj>
dkubb: Too bad travis does not have the "ssh into build" feature ;)
<mbj>
dkubb, snusnu: Thinking loud about resubmitting my a little bit refined, mutant talk to euroko. Opinions? - Does the concept / implemnentation still have "news" value?
<mbj>
AFAIK yes, just need other brains to participate ;)
<dkubb>
mbj: yes, I would guess that only about 5% of the community has even heard of it
<dkubb>
mbj: heard and understand I mean
<mbj>
dkubb: heh
<mbj>
dkubb: goooood, gives me enough confidence ;)
<dkubb>
mbj: I still can't wait until we get mutation covered projects in wider usage. virtus is probably the widest used project we have that has any mutation coverage (aside from pieces of DM1)
<dkubb>
mbj: the DM1 pieces I used mutation coverage have literally had zero bugs reported since I wrote the code
<mbj>
dkubb: yeah, I know that feeling.
<dkubb>
what I really want to see is, in production, how stable is the ROM stack? How many bugs are reported that are due to flawed logic *or* a flawed specification?
<dkubb>
I suspect most bugs will be due to specification bugs, which is fine, because the only way to find those bugs is through real world experience
<dkubb>
or anticipating them, which can only be done through pure luck or experience
<dkubb>
finding logic bugs is awesome through, because it should point directly to a missing mutation in mutant. we can upgrade mutant, use it to find the mutation in the code, fix the code.. and then run mutant against everything else to find and fix every similar bug in all the libs
zekefast has quit [Ping timeout: 265 seconds]
<mbj>
dkubb: Yeah
<mbj>
dkubb: I have some ideas with "inverse" mutations. Where specs get mutated.
<mbj>
dkubb: This is an explorational idea.
zekefast has joined #rom-rb
snusnu has quit [Quit: Leaving.]
<dkubb>
I've thought about that too
<dkubb>
if you remove a context and all mutations continue to be killed maybe it wasn't doing anything
<mbj>
dkubb: yeah
<dkubb>
I do sometimes have redundant examples, like confirming the return value in each context
<dkubb>
but if there was a nicer way to create contexts that can be inherited, I would likely put that common stuff in that, and then each context can focus on the specific behavioural difference
<dkubb>
shared_context is alright, but I don't see why it wouldn't be possible to just "inherit" from an existing context and override something
<mbj>
dkubb: Yes, I stopped work on xspec for morpher
<mbj>
dkubb: Because vanguard/ducktrap/xspec/mutant-filters share something I wanna extract.
<mbj>
traceable predicate evaluations.
<dkubb>
mbj: I may experiment with an rspec style where if I have repeating code in different contexts I define a shared context before them
<dkubb>
I suspect that predicate evaluations is just one part of it
<mbj>
dkubb: I'm getting to sick of rspec-dsl and rspec internals.
<mbj>
dkubb: stuff like be_true vs be(true)
<mbj>
dkubb: Where the first actually matches for thruthyness instead of true.
<dkubb>
it should be: be_truthy
<mbj>
exactly
<mbj>
there are many of this "imperfections" in the rspec dsl.
<dkubb>
you should add an issue to ask about a renaming in the rspec dsl
<dkubb>
deprecate the old syntac
<dkubb>
*syntax
<dkubb>
be_falsey
<mbj>
Also the internals are not very mutation-tool-interfacing-friendly.
<mbj>
dkubb: No, I'll not spend my limited OSS time on improving something that is not "good" enough in its internals.
<mbj>
Just read the rspec code and you know what I'm talking about.
<mbj>
It just does not fit my quality demands anymore.
<mbj>
Its better than nothing, but its the same with heckle vs mutant.
<mbj>
Improving heckle was not possible.
<dkubb>
yeah
<mbj>
and yeah, in OSS I'm somehow affected by NIH. with GOOD side effects ;)
<dkubb>
I suspect rspec just has too many use cases to handle. something smaller and focused would work
<dkubb>
I would say minitest is a nice alternative, except the internals are not so nice
<mbj>
Yeah
<mbj>
An spec system is nothing more than a group of predicates and a system to set a subject up.
<dkubb>
and dependencies
<mbj>
Get the internals right and counquer that domain.
<mbj>
Just like with mutant, I came up with a good OO structure for that domain.
<mbj>
And I think I can do the same fo predicates, which are the base for a spec system.
<dkubb>
if you get the dependencies right, then you can probably parallelize large parts of things
<mbj>
! yeah
<dkubb>
you realize all this stuff we do with predicates is simply because ruby's own logic system doesn't allow introspection
<mbj>
Thats the reason I'll do it AST based.
<mbj>
Not ruby AST based, a predicate ast.
<dkubb>
if I could do something like capture { condition == 5 && val != other } and then get an AST it would make things so much simpler
<dkubb>
even if the AST was ruby specific, it'd be ok if it were standardized
<mbj>
Yeah
<dkubb>
we were almost there with 1.8, but I feel like 1.9 was a step backwards
<dkubb>
if we could have runtime introspection of the code in a block and get an AST back *without* having to examine the physical source, that would be ideal
<mbj>
I think it will come back. And than we can perfeclty interface my solution via converting that implementation specific IR to whitequark/ast.
<dkubb>
it would need support for 1.9/2.0, as well as changing to return whitequark/ast
<mbj>
Thought about a converter from rbx-ast to whitequark/ast
<mbj>
would be very easy to build.
<dkubb>
does rbx provide a to_source or to_sexp interface?
<mbj>
whitewquark/ast => rbx-ast would be as simple as: parse_rbx(unparse(whitequark_ast)) ;)
<mbj>
dkubb: it has to_sexp
<mbj>
my to_source I build for early mutants is imperfect
<mbj>
no to_source ootb. also no source locations.
<dkubb>
your to_source project is dead right? unparser is the successor, isn't it?
<mbj>
yeah
<dkubb>
a sourceify-alike that has a fallback to whitequark/parser would be interesting
<mbj>
but transform(rbx_ast.to_sexp) => whitequark/ast would be easy.
<dkubb>
it could use VM specific strategies to parse the code
<mbj>
10 hours.
<mbj>
with roundtrip tests involving unparser ;)
<dkubb>
and fallback to parsing the source as normal
<mbj>
BTW I'd love to do such work if someone sponsors me.
<dkubb>
that would be an interesting way to verify the code
<dkubb>
verify the code in unparser though
<mbj>
unparser already does round trip testing.
<mbj>
mutation cover unparser is the last thing I have to do.
<mbj>
The code structure of unparser would be very uneasy to mutation cover.
<mbj>
At least with current matcher.
<mbj>
I think about an inverse mutation <=> test matcher.
<dkubb>
you could have mbj/runtime_parser ;)
<mbj>
where the tests has metadata advertising witch code it mutation covers.
<dkubb>
something that parses code in it's runtime form might be even better for mutant, wouldn't it?
<mbj>
what is the "runtime form" ?
<dkubb>
because it would be unaffected by monkey patching
<dkubb>
well, right now mutant works with a static source parser. but once the code is evaluated it can be modified into a form that is different from the source
<mbj>
dkubb: You talking how to mutate parser itself?
<mbj>
*talking about
<dkubb>
I was just thinking that if you could get the AST of the method in the form that is equivalent to what ruby currently thinks it is
<mbj>
Ahh
<mbj>
the "effective" AST.
<dkubb>
rather than what the method is in the source file
<dkubb>
yeah
<mbj>
def foo
<mbj>
end
<mbj>
memoize :foo
<mbj>
;)
<dkubb>
right
<mbj>
yeah
<mbj>
That would be the perfect situartion yeah.
<mbj>
I did a pretty good job with finding the source / effective source of a method.
<mbj>
But its not "that" easy. And that perfect.
<mbj>
Could be far easier with help from VM/impl.
<dkubb>
it sounds like it is possible with all the VMs, just different difficulties
<dkubb>
with rbx probably being the easiest
<mbj>
I'll research in this direction a bit.
<mbj>
But there are still more "low hanging" fruits for mutant ;)
<mbj>
and here we are again: I'd love to write a generic interface: BUT
<dkubb>
too bad sourcify wasn't active
<mbj>
platform specific dependencies are horror with rubygems.
<mbj>
So much stuff to fix in the ruby ecosystem :(
<dkubb>
I often wonder if it's much better in other ecosystems, then I look and find it's not
<dkubb>
well, it's better in some cases, but worse in others
<mbj>
:D
cored has joined #rom-rb
bf4_ has joined #rom-rb
bf4 has quit [Ping timeout: 260 seconds]
<mbj>
dkubb: Reading through ruby-intern, fucking awesome ;)
<mbj>
I think mutant could benefit a lot.
irclogger__ has quit [Ping timeout: 260 seconds]
<mbj>
Also I'll find a way to make it cross mri/jruby/rbx, probably I'll define my interface and create adapters.
bf4_ has quit [Ping timeout: 246 seconds]
<mbj>
dkubb: Could you *please* stop to come up with addictive ideas ;P
CraigBuchek has quit [Quit: Leaving.]
<dkubb>
hehe
<dkubb>
mbj: how does he do it? is it relying on published interfaces or something?
<dkubb>
mbj: what I would suggest is start with the to_ast public interface and define just what you need underneath to make it work for rbx (since that'll be simplest), and then move to jruby or rbx
<dkubb>
mbj: what I would love to see is something that can replace sourcify, except using to_ast.. it could delegate to_sexp to to_ast too.. to_source could be done with unparser
cored has quit [Ping timeout: 272 seconds]
<dkubb>
mbj: I saw somewhere that ruby-core was thinking about providing Proc#to_source