<enebo>
ChrisBr: so only missing bit is context.runtime in what I said more or less and that is style but not purely style...just something to know about
<ChrisBr>
ah thanks
<ChrisBr>
so the conditional without curly is fine as it is only one line? Or should I change it to the ternary operator?
<enebo>
ChrisBr: yeah 'if (foo) bar();'
<enebo>
if (value != null) result.op_aset(key, value);
<enebo>
ChrisBr: I would be inclined to do this personally but braces is fine too
<ChrisBr>
Ok, thanks
<GitHub7>
[jruby] headius pushed 2 new commits to jruby-9.1: https://git.io/vNLWP
<GitHub7>
jruby/jruby-9.1 a320da8 Charles Oliver Nutter: Grr, dynlangs and refactoring.
<GitHub7>
jruby/jruby-9.1 e6a8b40 Charles Oliver Nutter: Isolate threads and ensure they are alive before testing.
<GitHub7>
[jruby] headius pushed 1 new commit to jruby-9.1: https://git.io/vNLlr
<GitHub7>
jruby/jruby-9.1 ce434ec yui-knk: Set original Module to definedClass of methods...
<GitHub105>
[jruby] headius closed pull request #4944: Set original Module to definedClass of methods (master...test_alias_owner_2) https://git.io/vNTqn
<enebo>
ChrisBr: try a mvn clean
vtunka has quit [Quit: vtunka]
<enebo>
ChrisBr: sometimes if you get a syntax error during a build at the wrong time our generated populators from processing @JRubyMethod annotations does not finish so we get weird errors like that
<ChrisBr>
thanks, indeed fixed the issue :)
<ChrisBr>
enebo: ^^
<enebo>
cool
<GitHub170>
[jruby] headius pushed 1 new commit to jruby-9.1: https://git.io/vNLRA
<GitHub170>
jruby/jruby-9.1 8c2426f Charles Oliver Nutter: Wrong method.
<headius>
brb Ruby community, we need a year off from releases
claudiuinberlin has joined #jruby
<GitHub60>
[jruby] headius pushed 1 new commit to jruby-9.1: https://git.io/vNLam
<GitHub60>
jruby/jruby-9.1 5f76ad1 Charles Oliver Nutter: Include null check to mimic logic in interpreter....
<headius>
enebo, ChrisBr: I'm killing that 2.5 build because I'm working on 9.1 CI greening...feel free to queue it up later if you need the results
olle has quit [Quit: olle]
<chrisseaton>
headius: IntelliJ does the most ludicrous renamings whenever I try to refactor
<chrisseaton>
Rename a local variable called 'foo' and it wants to modify an SVG file with an element called foo - things like that
ddadacha has joined #jruby
<headius>
chrisseaton: yeah it's way too invasive
<headius>
except in this case when it didn't detect an obvious case
<headius>
so idk
<chrisseaton>
headius: are frozen string literals garbage collected? I know they're de-deuplicated, but is the de-duplicator weak?
<headius>
it tries to rename symbol sometimes too
<headius>
chrisseaton: in JRuby it is
<headius>
I assume it is in MRI Too
<chrisseaton>
There's some specs that have a frozen string literal, take the object_id, and then expect a subsequent frozen string literal to have the same object_id
<chrisseaton>
That's broken isn't it?
<chrisseaton>
Nothing holds onto the first frozen string literal
<headius>
hah yeah I love those
<headius>
yeah I don't know that it's behavior someone should expect
<headius>
it's a side effect of MRI anchoring frozen strings in their instrs
<headius>
I think we pass for a similar reason, but I don't think it's an appropriate guarantee
subbu is now known as subbu|away
<headius>
there's others that are testing opto or impl details like defined? always returning the same object
<headius>
there's no user-facing reason that should be specified behavior
<headius>
omg weakref specs
<chrisseaton>
The gap between the two is short so you probably just have never GCd
<ddadacha>
hey folks, wondering if this is a good spot to ask some questions about a jruby deployment issue I'm hitting
<headius>
ddadacha: sure is!
<headius>
chrisseaton: we have a similar structure to MRI though...FrozenString operand anchors the string attached to it
<headius>
so while the script is live, the frozen strings it contains will be alive
<ddadacha>
headius: great, thanks! I just upgraded an old rails app from 3.2 to 4.2. Everything works fine in my dev env but when I deploy to tomcat7 with warbler, rails initializes but starts spitting out this error: `DEBUG: resetting rack response due exception`
<headius>
chrisseaton: hey you run on the same GC we do, do you have any issues with weakref specs being flaky?
<headius>
I'm about ready to exclude them completely because they randomly fail if GC doesn't deliver the goods
<chrisseaton>
Ruby weakref? No
<ddadacha>
I figured one/some of my gems are not playing nicely but I'm not sure how to isolate the problem
<headius>
ddadacha: so first thing might be to raise an issue on warbler project...there's at least one active maintainer there that might know it immediately
<ddadacha>
hmm I wasn't sure if it was a warbler issue though, since it was creating the war file just fine and rails was initializing (I have some logs in my initializers that are running - it's just after it finishes starting up that I hit that error)
<ddadacha>
right, I saw that file but wasn't sure how to get more info like what the specific exceptionw as
<headius>
oh yeah I see that in your SO post now
<headius>
yeah I'd expect it to get logged somewhere
<headius>
right, so it might just be an app/gem/whatever issue
<headius>
that appears to try to log the exception somehwere
<ddadacha>
right, that's what I figured too. Do you know of some way to debug it? I was trying to find more info/logs around it but I'm not entirely sure where to look
<ddadacha>
excellent, thanks I'll look for that message
<headius>
@kares got any thoughts here?
<headius>
hmm
<ddadacha>
would ErrorApplicationHandler (eventually) log errors in the same spot as the context.log?
<headius>
at the very least a jruby-rack issue report would clarify whether it's logging enough or not
<headius>
well, HTTP response I assume, but you said you see this before even hitting the server?
<ddadacha>
yes after startup but if I hit a URL after it's started, I get the same error as well
<ChrisBr>
enebo: the rubyspec tests from mri belong to spec/core/... ?
<headius>
I have not built jruby-rack in a while but getting this error report is definitely our first step :-) may have to hack a modified jruby-rack to dump more info
<headius>
those binding messages should definitely not be there
<GitHub150>
[jruby] ChrisBr opened pull request #4954: Alias Set#=== to #include? (ruby-2.5...feature/set-equal) https://git.io/vNLX8
<headius>
and there's two of them along with two of your exception errors
<ddadacha>
in terms of getting the error report, so would you like me to file an issue with jruby-rack? I'm a bit of a jruby noob so not entirely sure what you'd like me to post haha
<headius>
well post explaining what you did and that you can't get jruby-rack to report the actual error
<ddadacha>
there's quite a few more of resetting rack response due exception that I didn't copy after that btw
<ChrisBr>
ok, so cherry picking the specs shouldn't be necessary usually?
<headius>
it's either a bug (insufficient logging) or a documentation issue (no clear way to enable that logging)
<headius>
ChrisBr: not usually no
<headius>
it doesn't really hurt anything
<ddadacha>
ok I can do that for sure
<headius>
eregon might have an opinion about that since he has been doing the merging
<ChrisBr>
checking master ..
<ddadacha>
I'll loko into the binding issues as well, I dug into them briefly but didn't find much on them either
<ChrisBr>
same for master
<headius>
ChrisBr: if they're not on master then they never made it out of MRI into ruby/spec
<headius>
so that needs to happen
<headius>
master specs were last updated just a few weeks ago
<headius>
probably could cp for now since they're not in spec/ruby either
<ddadacha>
headius: thanks for the help! I'll post an issue to jruby-rack and dig into the binding stuff in the mean time
<headius>
bbrowning worked on TorqueBox and might have some tips about getting it to log also
<ChrisBr>
no was speaking about the jruby master! Thought they maybe are in jruby master but did not made it into ruby2-5 branch! But they're also missing in master
<headius>
fwiw this has frustrated me about jruby-rack in the past too
<headius>
ChrisBr: ok
<ddadacha>
good to know =)
<ddadacha>
I don't think I'll be able to hack a modified version together quickly atm, don't have any of the build envs set up... crossed my mind though
<headius>
yeah link me your issue and I'll add myself
<bbrowning>
ddadacha: tomcat by default has multiple log files - did you check all of them for any more info?
<headius>
I can't help with building a custom one today but maybe tomorrow
<bbrowning>
and, from the code, it looks like this may spit out errors in the html response
<bbrowning>
ddadacha: so, whatever's sending the requests to your app to generate those log entries is likely getting some kind of error response back I guess
<bbrowning>
(I haven't used jruby-rack or warbler in a long time, so this is just a guess)
<headius>
bbrowning: that's what it looked like to me too
<headius>
I'd argue the DefaultErrorApplication should be logging regardless if it's an app exception
<GitHub135>
[jruby] headius created use_ruby_weakref (+2 new commits): https://git.io/vNLM6
<GitHub135>
jruby/use_ruby_weakref 87a0e73 Charles Oliver Nutter: Move common script-level dynscope logic to helper.
<GitHub135>
jruby/use_ruby_weakref 783d025 Charles Oliver Nutter: Revert to using weakref.rb, since it's based on a proper weak map....
<GitHub138>
[jruby] headius fast-forwarded jruby-9.1 from 5f76ad1 to 87a0e73: https://git.io/vNLDk
<GitHub88>
[jruby] headius opened pull request #4955: Revert to using weakref.rb, since it's based on a proper weak map. (jruby-9.1...use_ruby_weakref) https://git.io/vNLDu
<ddadacha>
bbrowning: yeah I was tailing all of the log files in my tomcat dir just to be sure, just that 1 line is added to the logs at the time
<ddadacha>
the response is just my 50x.html page, I don't see anything else apart from my raw html
<ddadacha>
looking to see if tomcat is overwriting the error response somewhere since it's just defaulting to my 50x
<ddadacha>
headius, bbrowning: just realized I was mistaken with this error happening on startup. Found out that the first few times were because my load balancer's health checks were firing and were queued up while tomcat was starting. I disabled it, restarted tomcat and now it won't output the log until I fire the request myself
<ddadacha>
the binding messages are no longer present either
<headius>
aha
<headius>
but you still don't see the result in the response?
<GitHub194>
[jruby] headius created null_toplevel_frame_name (+1 new commit): https://git.io/vNL9S
<GitHub194>
jruby/null_toplevel_frame_name 6908774 Charles Oliver Nutter: Do not provide a frame name for toplevel....
<ddadacha>
no, still looking to see if I can get tomcat to just spit the raw response somewhere
<headius>
ok
<headius>
codefinger: you around?
<codefinger>
yo
<codefinger>
headius: sup?
<headius>
codefinger: ddadacha and I have been trying to figure out how to get jruby-rack to lock an exception during process()
<headius>
it goes to DefaultErrorApplication but that only seems to produce an error response
<headius>
log not lock
<ddadacha>
headius: I removed my custom 50x rendering, now I'm just getting apache's usual "Internal Server Error" 500 page. Still nothing in the response
<headius>
ok
<codefinger>
not sure off the top of my head
<codefinger>
i can take a look
<GitHub67>
[jruby] headius opened issue #4956: Signal + thread tests from MRI are unreliable https://git.io/vNL7b
<codefinger>
ddadacha: do you have a repo that demonstrates the problem?
<ddadacha>
codefinger: no, sorry it's not public unfortunately
<codefinger>
if you could sketch out a simple app that reproduces it that would help
<ddadacha>
I'm not sure I can tbh. I suspect this error is being thrown because of a problem with one of the gems that I just updated. I don't know how to manually trigger the error though
<ddadacha>
trying to figure out which gem(s) in particular so that I can troubleshoot further
<ddadacha>
that all being said, I'm not sure it's specifically with a gem or some config etc since this was a pretty huge update on our part
<GitHub30>
[jruby] headius pushed 4 new commits to jruby-9.1: https://git.io/vNLFo
<GitHub30>
jruby/jruby-9.1 6983b58 Charles Oliver Nutter: Sleep longer for slow envs.
<GitHub30>
jruby/jruby-9.1 e2206af Charles Oliver Nutter: Exclude these pesky thread+signal specs....
<GitHub30>
jruby/jruby-9.1 d2f4f0c Charles Oliver Nutter: Try disabling compressed OOPs to pass the ripper rlimit test....
<GitHub143>
[jruby] headius closed pull request #4955: Revert to using weakref.rb, since it's based on a proper weak map. (jruby-9.1...use_ruby_weakref) https://git.io/vNLDu
<GitHub166>
[jruby] headius deleted use_ruby_weakref at 783d025: https://git.io/vNLFb
<GitHub74>
jruby/jruby-9.1 1b4a2f3 Charles Oliver Nutter: Merge pull request #4955 from jruby/use_ruby_weakref...
<GitHub74>
[jruby] headius pushed 1 new commit to jruby-9.1: https://git.io/vNLFF
dave__ has quit [Read error: Connection reset by peer]
<ChrisBr>
is it known that RubyHash.rehash is not handling collisions properly?
<ChrisBr>
hmm, it's driving me nuts :/ I'm pretty sure my fix works because the items are removed from the table but in the ruby code it still contains both elements :(
<ChrisBr>
yeah, right equals compares key and value
<ChrisBr>
headius: so you mean we should use insert instead?
<headius>
I'm stepping through it now
<headius>
I tried using that function to check equality but it's still not working
<headius>
something's weird
<headius>
ChrisBr: I know what it is
<headius>
it's not clearing out insertion ordering fields in the entry
<headius>
so when it walks in insertion order for inspect it still picks it up
<headius>
this rehash isn't great anyway...it doesn't resize the buckets and it uses some really slow path code for calling eql?
<GitHub72>
[jruby] yui-knk opened pull request #4959: Raise `TypeError` if `#extend_object` is called for no module objects (jruby-9.1...test_extend_object_9_1) https://git.io/vNtme