<mbj>
Dunno how strong it is under meta programing. But I think it will NOT support runtime metaprogramming.
<solnic>
awesome name
<mbj>
And this is a feature I wanna remove from ruby also.
<mbj>
After your lib/app was booted, I'd like to all a Kernel.remove_metaprogramming!
<mbj>
*all => call
<solnic>
gotta go focus on work, ttyl
onewheelskyward_ is now known as onewheelskyward
<mbj>
solnic: np, same here.
lfox has joined #rom-rb
cored has quit [Ping timeout: 272 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
<mbj>
solnic: I think it got it. Ruby allows you to define a whole universe inside a while condition. Parts of that universe are now getting scanned for lvar reads till an lvar boundary.
lfox has quit [Quit: ZZZzzz…]
<mbj>
solnic: If the lvar was NOT defined in the parens of the nodes of the while, and first defined in the body, the body gets emitted before the while => while guard style.
<mbj>
solnic: And I think it got it correct. Also the tracing wich lvars exist at a given point in the AST.
<mbj>
solnic: No I'll have to wire it togetter and fuzz with /**/*.rb :D
<dkubb>
it's good for unparser to handle the rubygems corpus. people could literally run a gem's specs to get a baseline, then compare it against the specs of parsed/unparsed ruby code
<dkubb>
round trip testing will help parser and unparser improve
<mbj>
dkubb: If the specs pass with the original code, and the AST parsed from tune generated code matches the AST from the original code we could skip this.
<dkubb>
you can't unfortunately.. rubocop basically ignores the includes/excludes directives unless they were read from a .rubocop.yml in the root
<mbj>
mhh
<dkubb>
I suppose it could be fixed in rubocop, but I didn't want to get side tracked
<mbj>
so lets add a ticket to rubocop
<mbj>
IMHO its under active developent, we'll get it in.
<mbj>
dkubb: BTW I learned lot about ruby internals when writing that lvar tracker.
<mbj>
dkubb: Its actually not easy :D
<dkubb>
I just wish "no" was said more often during language design ;)
<mbj>
yeah
<mbj>
c = readbyte while c
<mbj>
actually
<dkubb>
I wonder if there's a correlation between "hard to parse for computers" and "hard to parse for humans"
<mbj>
def some_io_routing
<mbj>
c = readbyte while c
<mbj>
end
<dkubb>
does that initialize "c" automatcally after the first while loop?
<dkubb>
like it would run readbyte first, set c, and then test "while c"
<mbj>
I think is this: There is a correlation between "hard to parse correctly with compusers by human written software, and "hard to parse for humans".
<mbj>
dkubb: no
<mbj>
acutally its:
<mbj>
def some_io_routing
<mbj>
c = readbyte while c != 0xff
<mbj>
end
<dkubb>
oh I see
<mbj>
because c is an lvar, it gets assigned to nil
<dkubb>
so c starts off as nil, which satisfied the conditional, then it does the readbye, then the while test again
<mbj>
yeah
<dkubb>
I think I may have written something like that before
<dkubb>
but can it not just be written as: c = nil; while c != 0xff; c = readbyte; end
<mbj>
Detecting the need for this is very hard.
<dkubb>
I would be more likely to want to try using until there and state the conditional in the positive
<mbj>
I need to now: c is read from condition && c got FIRST assigned by body
<mbj>
s/now/know/
<mbj>
and that FIRST is a big problem. I need to scan the parent tree with lexical rules for assignments of c
<mbj>
that can be from block args, def args or traditional assinments.
<dkubb>
oh interesting
<mbj>
All from the emitter of while
<mbj>
And I'll emit as postcondition
<dkubb>
it could be a global var, class var or ivar
<mbj>
To make sure parse(source) == parse(generate(parse(source))) can acutally work
<mbj>
no it cant.
<dkubb>
no?
<mbj>
global vars and ivars are explicit prefixed with @ and %
<mbj>
s/%/$/
<mbj>
there is no ambiguity here.
<dkubb>
well, I know in this specific exmaple
<mbj>
Its all about the "first use of lvar introduces an lvar, and changes the behavior from private method send to lvar read"
<dkubb>
but I was talking about $c = readbyte while $c != 0xff
<mbj>
This will not a problem for unparsing.
<mbj>
Can safely be emitted as; while $c != 0xff; $c = readbyte; end
<mbj>
The only reason to emit body before condition is to make sure parser will turn the method call "c" into an lvar read.
<mbj>
If there would be a "force to read as lvar even if its undefined so return nil" expression in ruby we could also emit this as: while force_read_as_lvar_with_default_nil(c); c = readbyte; end
<mbj>
As we have a "force to read as ivar or gvar" via the $ / @ prefixes it is not a problem.
<mbj>
There is a force to read as lvar, eighter emitting body before while, or doing that c = nil beforehand.
lfox has joined #rom-rb
<mbj>
If you look at the rbx bytecode you'll see that assign to nil.
<mbj>
But my job is to produce source that will get turned into a specific ast, hence I must correctly detect that situration.
<mbj>
BTW I have a dkubb.fsck request once I push the code :D
lfox has quit [Ping timeout: 240 seconds]
<dkubb>
mbj: would a stopgap be to do c ||= nil before the expression?
<mbj>
dkubb: I'd have to emit it before ALL expressions that can be written as postconditions.
<mbj>
dkubb: while is just the start, need to support this for ALL controll flow that is possible as "guard claus" style.
<mbj>
dkubb: I'm very close to wire the lvar scope scanner. Once this works all of the control flow emitters will get a #postcodintion? (private) to decide between emit_normal and emit_postcondition
<mbj>
s/postcondition/guard/
<mbj>
dkubb: And yes, it would work.
<mbj>
but it would make most of mutants output close to unreadable.
<mbj>
dkubb: And +1 good idea ;)
<dkubb>
I was more thinking about getting something working and then optimizing it. I agree it's not the ideal case at all. I would like for the unparsed code to be as close to the original semantics as possible
<mbj>
dkubb: It would break mutant.
<mbj>
dkubb: Actually it wount.
<mbj>
dkubb: I'd love to discover this thing more early :D
<mbj>
dkubb: But for now I'm very close to commit the optimized version.