_whitelogger_ has quit [Remote host closed the connection]
_whitelogger__ has quit [Remote host closed the connection]
ur5us has quit [Ping timeout: 244 seconds]
olleolleolle has quit [Ping timeout: 245 seconds]
olleolleolle has joined #jruby
olleolleolle has quit [Ping timeout: 265 seconds]
olleolleolle has joined #jruby
ur5us has joined #jruby
olleolle1lle has joined #jruby
olleolleolle has quit [Ping timeout: 256 seconds]
olleolle1lle has quit [Ping timeout: 256 seconds]
olleolleolle has joined #jruby
olleolleolle has quit [Ping timeout: 256 seconds]
olleolleolle has joined #jruby
jeremyevans has quit [*.net *.split]
ur5us has quit [Ping timeout: 264 seconds]
jeremyevans has joined #jruby
subbu is now known as subbu|away
drbobbeaty has quit [Ping timeout: 260 seconds]
drbobbeaty has joined #jruby
subbu|away is now known as subbu
marcheiligers[m] has quit [Quit: Idle for 30+ days]
subbu is now known as subb|lunch
subb|lunch is now known as subbu|lunch
jeremyevans has quit [*.net *.split]
subbu|lunch is now known as subbu
victori has quit [Ping timeout: 276 seconds]
<headius[m]>
enebo: only things remaining for 9.2.17.0 are psych (which I will just punt to 9.3 because it isn't important) and the new .exe
<enebo[m]>
ah ok I will make the new .exe
<headius[m]>
I see nothing else recent that should go in
<headius[m]>
byteit101: will be cycling back into 9.3 stuff so I have your PR up again
<byteit101[m]>
awesome, let me know -if- *when* you have questions
victori has joined #jruby
<enebo[m]>
pushed to jruby-9.2.
<headius[m]>
neato
victori has quit [Client Quit]
victori has joined #jruby
victori has quit [Client Quit]
victori has joined #jruby
victori has quit [Remote host closed the connection]
victori has joined #jruby
<slonopotamus[m]>
headius:
<slonopotamus[m]>
whoops
<headius[m]>
slonopotamus:
<slonopotamus[m]>
Hi, I saw your PR about zlib, but didn't have a minute to test it yet) Going to try now.
<slonopotamus[m]>
Is it OK that your fix exists in `jruby-9.2` branch but doesn't exist in `master` branch? I'm not sure about branching policy in JRuby repo.
<headius[m]>
slonopotamus: we merge them peridically
<slonopotamus[m]>
Okay. Then, I have to say that you actually fixed this thing!)
<slonopotamus[m]>
* Okay. Then, I have to say that you actually fixed this thing!) Thanks!
<headius[m]>
excellent!
<headius[m]>
still an open issue for getting the rest of specs passing but at least this issue is resolved
<slonopotamus[m]>
Hehe. It currently passes "deflates chunked data without errors" test but doesn't pass "deflates chunked data". Without looking into test details, this is at least funny.
<headius[m]>
yeah the specs are not particularly good at isolating behaviors... I would guess the "without errors" specs just check that nothing blew up
<headius[m]>
usually these specs don't get in because they don't test anything more than just testing proper outputs
<headius[m]>
clearly if it errors it won't produce output
<headius[m]>
that is the entire diff vrom 2.5.7 to 2.5.8
<headius[m]>
ok the stdlib changes are basically nothing
jeremyevans has joined #jruby
<enebo[m]>
yeah no stdlib at all from what I see
<enebo[m]>
some very minor parser changes but even those are remove value_expr checks those could mean less void value expression errors but I suspect they are still caught elsewhere
<headius[m]>
I will make sure bundled gems are updated
<enebo[m]>
They can also mark unused variables but also I bet caught elsewhere
<enebo[m]>
updated rake?
<headius[m]>
the diff of actual stdlib files is super tiny so I will include this all in one PR
<headius[m]>
checking... I think we may have updated some of these beyond 2.5.8 though
<headius[m]>
we were not including path and an io/console test expected it
<headius[m]>
not the function name
<enebo[m]>
but what is the difference between TCSADRAIN and TCSANOW
<headius[m]>
one is what CRuby uses, the other is not 😀
<headius[m]>
TCSANOW The change occurs immediately.
<headius[m]>
TCSADRAIN The change occurs after all output written to fildes has been transmitted to the terminal. This value of optional_actions should be used when changing parameters that affect output.
<enebo[m]>
but the first two lines was what it was and the next two is what it became but if this is just for MRI then fine
<headius[m]>
so the intents was to flush but it did not quite do it the same way
<headius[m]>
flush/apply immediately I mean
<enebo[m]>
so it now will flush immediately ok
<headius[m]>
if I change something, it either failed a test or didn't match the equivalent C code
<enebo[m]>
much of it is just new stuff so I am not really against that
<enebo[m]>
c_cc vs cc_c is something I don't get at all but I imagine that was a typo?
<headius[m]>
and this adds support for the kwargs that `raw` and `getch` are supposed to support
<headius[m]>
yeah typo... I did not see any reason it was named differently so I just fixed it
<enebo[m]>
yeah kwargs change looks interesting in that it passes them down
<enebo[m]>
well if the code here is obviously hit (for the changes) and we work on linux/mac/windows I guess I am game
<headius[m]>
I will include in 2.5.8 PR then since that is the last stdlib piece that is not up to date with latest
<enebo[m]>
I do really want to clamp down on what we fix there. We know we have plenty of bugs we will probably never fix at this point
<headius[m]>
anything where we match 2.5.8 but there is something newer I do not update
<headius[m]>
this one just stuck out for me because I know the old io/console we ship is broken for several features
<headius[m]>
and the gem one is 100%
<enebo[m]>
I almost exclusively would like it to only be raised focus on a user reported problem
<enebo[m]>
but this is not a lot of changes and if it leads to problems we can just for .18
<headius[m]>
yeah I can't say anyone has reported the missing features
<headius[m]>
other than me while trying to get our code into the gem
<enebo[m]>
So the other observation about these point releases which is maybe obvious but the more we have the more we get reported problems
<enebo[m]>
That has nothing to do with quality
<headius[m]>
yeah people see the activity and try newest sooner
<enebo[m]>
It likely means more releases gets more people trying stuff
<enebo[m]>
In that sense the notion of a .18 or .19 based on a couple of fixes tends to almost be marketing
<enebo[m]>
but with that said I think 9.3 should be most energy as I think that will garner a lot more interest
<enebo[m]>
Each time I see some image manip. Q for JRuby someone will reply..."but it has not been released for n months. I assumed it is dead"
<enebo[m]>
image_voodoo just works. This notion that software has to be released or people have no interest is still a phenomena which always surprises me :)
<headius[m]>
I agree and do not want to have to do .18 any time soon
<headius[m]>
once this 17 is settled I will be back on trying to close 9.2 issues and PRs
<headius[m]>
er 9.2
<headius[m]>
AGH 9.3
<headius[m]>
I dunno how to deal with that... software that is "done" looks "dead", but software that spins a release every week is probably super unstable
<headius[m]>
or at least the risk is high
<headius[m]>
enebo: this 2.5.8 update is ready to go then
<headius[m]>
I will not do tests in this PR because there are a lot of places we have patched our tests and I don't feel like reviewing that for a minor update
<enebo[m]>
ok I looked at the rest. So I say merge it assuming nothing is broken
<headius[m]>
ok, after it is green I will merge
<headius[m]>
enebo: there is one failure in io/console test but I think it is an out of date test
<headius[m]>
ok, 9.2.17.0 is done... versions updated, stdlib updated, issues and PRs closed or rehomed
<headius[m]>
also merged to master
<headius[m]>
kalenp: I send something to release@jruby.org but not sure if it propagated... 9.2.17.0 next week
<kalenp[m]>
Thanks for the heads up! We've upgraded to 9.2.16 without any issue so far.
<kalenp[m]>
Though I suspect that the IO.copy_stream story isn't entirely done. I haven't dug into the details yet, but it's still misbehaving in our integration tests while passing in the unit tests.
<headius[m]>
hmm
<headius[m]>
that blasted thing
<kalenp[m]>
hopefully next week I can dig into what's going on now. the hard part is that it doesn't show up in our unit tests, but only when we're actually copying to a stream produced by our Mail gem. so seems to depend on some details of the particluar IO object that's on the receiving end
<kalenp[m]>
I thought I'd captured it all in that initial bug report, but apparently not
<kalenp[m]>
gotta hop now. thanks again for the heads up on the next release
<headius[m]>
hmm well let me know if you can isolate the problem