dhoc has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]
dhoc has quit [Quit: dhoc]
nowhereFast has joined #jruby
nowhereFast has left #jruby [#jruby]
dhoc has joined #jruby
travis-ci has joined #jruby
<travis-ci> jruby/jruby (ruby-2.6:0d0ea41 by Charles Oliver Nutter): The build failed. https://travis-ci.org/jruby/jruby/builds/669957391 [178 min 5 sec]
travis-ci has left #jruby [#jruby]
dhoc has quit [Quit: dhoc]
ur5us has quit [Ping timeout: 240 seconds]
lopex[m] has quit [Quit: killed]
headius[m] has quit [Quit: killed]
cyberarm has quit [Quit: killed]
enebo[m] has quit [Quit: killed]
ThomasEEneboGitt has quit [Quit: killed]
MarcinMielyskiGi has quit [Quit: killed]
fzakaria[m] has quit [Quit: killed]
amiracam[m] has quit [Quit: killed]
UweKuboschGitter has quit [Quit: killed]
KarolBucekGitter has quit [Quit: killed]
JesseChavezGitte has quit [Quit: killed]
OlleJonssonGitte has quit [Quit: killed]
BlaneDabneyGitte has quit [Quit: killed]
joni_pv[m] has quit [Quit: killed]
slackfan[m] has quit [Quit: killed]
chrisseaton[m] has quit [Quit: killed]
byteit101[m] has quit [Quit: killed]
HarlemSquirrel has quit [Quit: killed]
RomainManni-Buca has quit [Quit: killed]
rtyler1 has quit [Quit: killed]
kares[m] has quit [Quit: killed]
JulesIvanicGitte has quit [Quit: killed]
XavierNoriaGitte has quit [Quit: killed]
donv[m] has quit [Quit: killed]
MattPattersonGit has quit [Quit: killed]
codic0912 has quit [Quit: killed]
msp-greg[m] has quit [Quit: killed]
FlorianDoubletGi has quit [Quit: killed]
rdubya[m] has quit [Quit: killed]
olleolleolle[m] has quit [Quit: killed]
JasonRogers[m] has quit [Quit: killed]
ipproxy[m] has quit [Quit: killed]
TimGitter[m] has quit [Quit: killed]
rwilliams[m] has quit [Quit: killed]
rg_3[m] has quit [Quit: killed]
ChrisSeatonGitte has quit [Quit: killed]
CharlesOliverNut has quit [Quit: killed]
ibee[m] has quit [Quit: killed]
anubhav8421[m] has quit [Quit: killed]
liamwhiteGitter[ has quit [Quit: killed]
TimGitter[m]1 has quit [Quit: killed]
kasaltie has quit [Quit: killed]
liamwhiteGitter[ has joined #jruby
rg_3[m] has joined #jruby
kasaltie has joined #jruby
lopex[m] has joined #jruby
cyberarm has joined #jruby
MattPattersonGit has joined #jruby
fzakaria[m] has joined #jruby
headius[m] has joined #jruby
olleolleolle[m] has joined #jruby
XavierNoriaGitte has joined #jruby
FlorianDoubletGi has joined #jruby
rdubya[m] has joined #jruby
codic0912 has joined #jruby
joni_pv[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
OlleJonssonGitte has joined #jruby
MarcinMielyskiGi has joined #jruby
HarlemSquirrel has joined #jruby
JesseChavezGitte has joined #jruby
msp-greg[m] has joined #jruby
donv[m] has joined #jruby
TimGitter[m] has joined #jruby
kares[m] has joined #jruby
byteit101[m] has joined #jruby
rtyler1 has joined #jruby
enebo[m] has joined #jruby
ThomasEEneboGitt has joined #jruby
amiracam[m] has joined #jruby
ChrisSeatonGitte has joined #jruby
slackfan[m] has joined #jruby
ipproxy[m] has joined #jruby
UweKuboschGitter has joined #jruby
KarolBucekGitter has joined #jruby
anubhav8421[m] has joined #jruby
TimGitter[m]1 has joined #jruby
rwilliams[m] has joined #jruby
chrisseaton[m] has joined #jruby
ibee[m] has joined #jruby
RomainManni-Buca has joined #jruby
JulesIvanicGitte has joined #jruby
CharlesOliverNut has joined #jruby
JasonRogers[m] has joined #jruby
ur5us has joined #jruby
shellac has joined #jruby
Antiarc has quit [Quit: ZNC 1.7.4+deb7 - https://znc.in]
Antiarc has joined #jruby
sagax has quit [Read error: Connection reset by peer]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (ruby-2.6:11b34cb by Charles Oliver Nutter): The build failed. https://travis-ci.org/jruby/jruby/builds/670053761 [168 min 26 sec]
ur5us has quit [Ping timeout: 252 seconds]
<kares[m]> hey, you guys have your oss idea licenses renewed?
sagax has joined #jruby
dhoc has joined #jruby
subbu|away is now known as subbu
<enebo[m]> kares do not quit idea
<enebo[m]> kares: but yeah hiro asked last wednesday and has not hard back yet
<enebo[m]> OR change the date on your machine :)
<kares[m]> okay no biggie
<enebo[m]> It only seems to start mentioning it will stop working like 4 days before it happens
<enebo[m]> Or at least that was when I noticed it
<kares[m]> yy
<kares[m]> not quiting not an option, for some reason project windows aren't always closing (a blank window persists) until I restart
<enebo[m]> kares: manual date I think should work but that is no fun
<enebo[m]> another option could be to sign up with evaluation copy
<enebo[m]> which may require another email address
<enebo[m]> I suspect covid-19 has affected their productivity
dhoc has quit [Quit: dhoc]
dhoc has joined #jruby
xardion has quit [Remote host closed the connection]
xardion has joined #jruby
shellac has quit [Ping timeout: 260 seconds]
<headius[m]> I quit and it started up again fine
<headius[m]> couple days ago
<enebo[m]> headius: I half wonder if they disabled license checking somehow
<enebo[m]> I was too afraid to see :)
<enebo[m]> I did look for a covid page but did not see one
<headius[m]> yeah I have no idea
<headius[m]> ok, TODAY we'll get 2.6 merged
<headius[m]> not sure where these last few were failures are coming from... never seen them up to now
<headius[m]> were=weird
<enebo[m]> I am going to fix or attempt to unbreak for loops with serialization on master since that regressed when we merged our IRScope removal branch
<enebo[m]> The second thing broken is ir inliner has no working callsites any more
<enebo[m]> but for for now :)
<headius[m]> for loops with serialization?
<headius[m]> what madness is this
<headius[m]> oh you mean serializing IR of for loops
<enebo[m]> lvars read in from serialization end up with improper depth
<headius[m]> I was imagining some unholy combination of for loops and Marshal
<headius[m]> ok
<headius[m]> I'm going to actually take a deeper look at these failures because they suddnely showed up in CI
<headius[m]> some of them I can't repro locally, so not sure about that
<enebo[m]> Ultimately I just want to read in staticscope and be done and non-zero depths will calculate from that
<headius[m]> this one doesn't repro locally and I have no idea why it would differ
<enebo[m]> I mean that is basically how itworks now except for for loop variables get wrong depth
<headius[m]> the warnings there should have been captured by a stderr hook
<headius[m]> yah that sounds like the right way
<enebo[m]> the other benefit of making it work is IRBuilder can be simpler by just creating base variables from staticscope
<enebo[m]> non-zero still needs to be created
<headius[m]> hmmm
<headius[m]> I'm wondering if these are failures from the parallel run that are not getting cleaned up
<enebo[m]> headius: remove parallel and see if it passes
<headius[m]> yeah worth a try
<headius[m]> some of these are so weird
<headius[m]> hmm
<headius[m]> only fullint and jit builds failed
<headius[m]> ok at least one of these is only failing in JIT
<headius[m]> [[1, 2, 3]].collect(&->(a, b, c) {[a, b, c]})
<headius[m]> that should error, but JIT doesn't
<enebo[m]> does it actually properly work?
<headius[m]> yeah the inner array is getting splatted out
<headius[m]> but it should be passed in as a single argument
<headius[m]> this shouldn't be hard to diagnose though
<headius[m]> other one failing only in jit is a test for the file+line of a binding frame
<headius[m]> I love all the nonsene I embed in indy call sites
<headius[m]> blonde, brunette, redhead
<headius[m]> oddly some duplication there I'm not sure about
travis-ci has joined #jruby
<travis-ci> jruby/jruby (ruby-2.6:11b34cb by Charles Oliver Nutter): The build failed. https://travis-ci.org/jruby/jruby/builds/670053761 [169 min 5 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> ok
<headius[m]> so jitted blocks are called directly and that skips an arity check
<headius[m]> full int blocks may do the same
<headius[m]> so this is missing from the protocol of optimized blocks... need to check arity in-body when a lambda
sagax has quit [Read error: Connection reset by peer]
sagax has joined #jruby
ur5us has joined #jruby
<fzakaria[m]> hi
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (ruby-2.6:44d05d2 by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/670301698 [76 min 29 sec]
<headius[m]> fzakaria: hello there!
<travis-ci> jruby/jruby (ruby-2.6:a04cf2c by Charles Oliver Nutter): The build has errored. https://travis-ci.org/jruby/jruby/builds/670304094 [100 min 57 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<headius[m]> aha
<headius[m]> enebo: wow I found one that only fails in full interpreter
<enebo[m]> nice
<headius[m]> that lambda thing seemed to be that the optimized prepareArgs logic was splatting the incoming args array before arity checking, and the non-optimized path didn't do that at all
<headius[m]> we need to figure out all these different prepareArgs variants and clean this up
<headius[m]> there's like five different ways to prepare args for a block
<headius[m]> I deleted the splatting and we'll see how it does in CI
<headius[m]> this is a really weird thing to only fail in fullint
<enebo[m]> funny to see the bug we have is removing a check for something people will not knowingly do
<enebo[m]> so obviously we only see this from a test
<headius[m]> yeah I don't consider such things high priority but I just want to get this merged
<headius[m]> I fixed that one
<headius[m]> the other was binding.source_location is wrong when inside a jitted method
<headius[m]> because it only uses interpreter backtrace
<enebo[m]> well it is reasonable to fix if for no other reason to make this all consistent
<headius[m]> I tagged that... will need a special call site for binding that knows how to get caller source location
<enebo[m]> I am just thinking about how we end up seeing bugs
<headius[m]> all of the methods that have special vision into caller should have special call sites
<headius[m]> I am pondering a generic mechanism to make that easy
<enebo[m]> we tend to be pretty good on golden path (e.g. working) code and our bugs come from these less commonly encountered things
<headius[m]> so like map "binding" to different logic for how to compile and bind the call site somewhere
<headius[m]> if it's builtin we use the file and line in hand, and if not we just continue a normal dyncall
<headius[m]> we can make almost all the frame-aware methods zero cost this way I bet
<headius[m]> for $~ too
<headius[m]> you have any idea why this constant deprecation thing would be different in fullint?
<headius[m]> it seems like somehow the warnings are output differently 😳
<enebo[m]> which one...I saw the one earlier where it was twice
<headius[m]> gist above
<headius[m]> the test replaces stderr with an object that should capture the output, but this seems to skip that object when in fullint
<headius[m]> it goes straight out, and shows up in the test output
<headius[m]> I'm not even sure where to start looking
<enebo[m]> github appears to be down and I closed that tab thinking it was just the arity issue
<headius[m]> hah
<headius[m]> down for me too
<enebo[m]> yeah not just us two either
<enebo[m]> so in full int it will print out but not get captured
<headius[m]> aha I think I have it
<headius[m]> 2.times {FALSE}
<headius[m]> and then the test checks that it was output only once
<headius[m]> perhaps fullint is not caching it and looks it up twice?
<headius[m]> $ jruby -Xdebug.parser -X-C -Xjit.threshold=0 -e '2.times {FALSE}'
<headius[m]> -e:1: warning: constant ::FALSE is deprecated
<headius[m]> -e:1: warning: constant ::FALSE is deprecated
<headius[m]> why on earth
<headius[m]> it's exactly twice too
<headius[m]> I did 10 and it's still twice
<enebo[m]> So how does it know to only do it once?
<enebo[m]> I am not quite up to speed here
<headius[m]> well it would be cached after the first access
<headius[m]> the warning is from lookup
<headius[m]> I think I have an answer though
<headius[m]> even with threshold=0 it's running through startup interpreter once
<headius[m]> so the nodes change and it gets looked up twice
<enebo[m]> ah ok...likely first run is startup and second is full
<headius[m]> right
<enebo[m]> I don't know why that happens for threshold=0 but with that said this would probably only happen in a main script
<headius[m]> yeah startup interp and then second time is interp
<headius[m]> I modified threshold = 0 for JIT to not run in parallel
<headius[m]> but I don't think that's the issue here
<headius[m]> I think the call logic for IR has the startup context in hand and still uses it after it submits for optimization
<enebo[m]> 2020-04-02T15:41:40.903-05:00 [main] INFO Interpreter : I: 5, R: 9 - %cl_1_2 = search_const(%scope ;name: FALSE, no_priv: false)>
<enebo[m]> -e:1: warning: constant ::FALSE is deprecated
<headius[m]> so it tosses it over and it probably even runs synchronously, but it doesn't re-get the context
<enebo[m]> -e:1: warning: constant ::FALSE is deprecated
<enebo[m]> 2020-04-02T15:41:40.915-05:00 [main] INFO Interpreter : I: {3} %cl_1_2 = search_const(%scope ;name: FALSE, no_priv: false)
<enebo[m]> This is when full runs
<headius[m]> yeah
<headius[m]> and it's exactly two because the second call re-gets context which is now full
<enebo[m]> yep
<headius[m]> aha of course
<headius[m]> it does promoteToFullBuild inside the call path for simple
<headius[m]> so it can't go back
<enebo[m]> Ok so threshold=0 is stll just moving through startup on acquire but then getting replaced from jit
<headius[m]> this may be specific to blocks
<headius[m]> yeah
<headius[m]> so it does run synchronously but by the time we submit for JIT we've already committed to startup call path
<headius[m]> this explains a lot of other rando failures too
<headius[m]> like fstring idempotence
<headius[m]> now about fixing it
<enebo[m]> we could pobably make clone clone value but that is very worrisome to me :)
<headius[m]> yeah worries me a little too
subbu is now known as subbu|away
<enebo[m]> I mean this would be operands keep their values
<headius[m]> right
<enebo[m]> and that would be very weird for let's say a temp var
<headius[m]> so we only create or lookup or cache once
<headius[m]> but we can't apply that to bytecode jit in any case
<headius[m]> I am thinking of tagging for now
<headius[m]> I mean I could do some work to move the block jit checks earlier in dispatch but it's a bunch of code for a very specific and rare and pretty much benign case
<enebo[m]> ok
<headius[m]> I'll open a bug and tag it
<headius[m]> once GH is back anyway
dhoc has quit [Quit: dhoc]
<headius[m]> GH is back
subbu|away is now known as subbu
<headius[m]> enebo: at this point if I get a green build without messing with it (rerunning etc) I'm going to merge to master
<headius[m]> there may be some new flaky tests to investigate but we can deal with that
<headius[m]> next job after this has settled will be load service
travis-ci has joined #jruby
<travis-ci> jruby/jruby (ruby-2.6:19d2f64 by Charles Oliver Nutter): The build failed. https://travis-ci.org/jruby/jruby/builds/670315417 [166 min 37 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> aww
dhoc has joined #jruby
<headius[m]> I've got a good feeling about this run
travis-ci has joined #jruby
<travis-ci> jruby/jruby (ruby-2.6:eb030b2 by Charles Oliver Nutter): The build is still failing. https://travis-ci.org/jruby/jruby/builds/670330775 [167 min 17 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (ruby-2.6:2215b31 by Charles Oliver Nutter): The build was fixed. https://travis-ci.org/jruby/jruby/builds/670346469 [173 min 31 sec]
<headius[m]> boom!
<headius[m]> hopefully the PR half of the checks also passes... bbiab