<headius[m]>
FWIW I have never really understood why MRI cares if you initialize an instance variable or not, since it's all dynamicky anyway, but I have no strong opinion for the issue
<headius[m]>
jeremyevans: I also just realized that those a0 and b0 methods are too large for us to even JIT
<headius[m]>
modified to only do ten allocs and the initialized/uninitialized split is more prominent
ur5us has joined #jruby
<jeremyevans>
headius[m]: Thanks for checking. I figured there would always be some decrease in JRuby, even if the difference is smaller. I didn't think about checking indy with JRuby.
<jeremyevans>
headius[m]: if you have time and could post your results to the ticket, that would be helpful.
newalexandria[m] has quit [Quit: Idle for 30+ days]
ur5us has quit [Ping timeout: 260 seconds]
_whitelogger has joined #jruby
<enebo[m]>
johnphillips31416: ok thanks. I think unless I see a similar problem using warbler this morning we need to make a diff for you to print out what file/line is executed at that point
<enebo[m]>
The problem with that is that message happens in a generated class
<enebo[m]>
At this point I think the problem was the 4th problem I identified but that neither of us can make fail synthetically or even fully reason out. The changes I made on this branch really should have killed any confusion of removing a scope during compilation itself
<enebo[m]>
the 4th problem was that we successfully compile something as a child and then later compile something else which recompiles that child and its parent (assuming closure is culprit) but that original child is still activated (closure is still executing) but not is looking at different scope layout.
<enebo[m]>
Although after having written that...how often is this occurring? 100%?
<johnphillips3141>
This actually happens when our app starts up, pretty reliably
<enebo[m]>
reliably < 100% though?
<johnphillips3141>
Few times in a row
<johnphillips3141>
We compile our classes in our jar
<fzakaria[m]>
Hi.
<fzakaria[m]>
Did anyone figure out what those IRC Bridge Status invites are ?
<fzakaria[m]>
I feel so dumb using this chat client (Element / Riot / Matrix)
<enebo[m]>
johnphillips31416: so you use jrubyc to generate .class files and that is how your ruby source is loaded?
<johnphillips3141>
Warbler has an option to compile source which we do. We do not compile 3rd party gems
<johnphillips3141>
Should I still be testing ir_concurrency or is it merged to 9.2?
<enebo[m]>
johnphillips31416: I will merge it today but this is an interesting discovery
<enebo[m]>
if it in fact compiles source to .class files that is essentially us storing our internal IR as a big binary hunk of data into a .class file
<enebo[m]>
we decode that using a different codepath than the parser codepath
<enebo[m]>
johnphillips31416: could you not do 'compiled' and see if you still see the problem
<enebo[m]>
johnphillips31416: now that I think back on your previous statement of not seeing it when you just 'jruby' invoke your app perhaps we have a lead
<enebo[m]>
Actually I think I can even see a problem with IRReader
<enebo[m]>
our persistence mechanism used by jrubyc will emit what essentially is the conclusion of having been freshly built from the parser
<enebo[m]>
when we read this back in we did not save the previous flag state and we will recalculate it
<enebo[m]>
it appears to have some problems now with recent changes
<enebo[m]>
our calculations do not call up into closures that I can see which would explain dynscope removal issues probably
<enebo[m]>
I think perhaps a better solution (which happens to also be a FIXME) is to just save all flag state into the persisted data and to not try and recalculate
<enebo[m]>
This was actually also not right before all this work but it happened to work out because fullIC would nuke and recalculate which would then do the closure flag calc
<enebo[m]>
The extra extraneous recalcs actually sort of fixed it by accident
<johnphillips3141>
will try building with warbler without compilation. In general warbler adds 3 things versus running from the command line: compilation, a different jruby entrypoint, and a different url classloading path
<johnphillips3141>
the jar has no issue/works fine when I do the warbler build without compilation
<headius[m]>
that's good news
<headius[m]>
the precompiled stuff has other differences internally, like trying to be lazy about certain things that could be to blame for that error
<headius[m]>
lazy instruction loading, which means more lazy optimization and analysis than regular execution, etc
<headius[m]>
jeremyevans: sure I'll post what I have
<headius[m]>
fzakaria: I am guessing it's something to do with nickserv/chanserv on Freenode trying to connect with your bridged username
<headius[m]>
I would like for the integration to be a little cleaner but it seems to work well
sagax has joined #jruby
<enebo[m]>
johnphillips31416: I would not bother with compilation unless you are looking for some level of obfuscation. It does not load faster or generate faster code.
<enebo[m]>
johnphillips31416: BUT I want to fix this so please allow us to work through this last problem (fingers crossed)
<kares[m]>
as 9.2.13 is still pending, what do you guys think about backporting the IO copy_stream bug?