lucasb has quit [Quit: Connection closed for inactivity]
sagax has quit [Quit: Konversation terminated!]
slyphon has joined #jruby
slyphon has quit [Client Quit]
_whitelogger has joined #jruby
<rg_3[m]> @hea
sagax has joined #jruby
<headius[m]> How does it modify code?
<headius[m]> I did not see that in the repo
<rg_3[m]> headius: i tried this hack https://github.com/rg-3/trip.rb/commit/54d250929e2465e568ae64399be609865dae05ad but sadly didn't work :(
<rg_3[m]> headius: it can "modify" code because when the tracer thread is suspended you can call `binding.eval('some_method_arg = 2')` then resume the tracer again with the altered value
<headius[m]> Oh I see
<headius[m]> I can probably add this per thread tracing in a couple minutes but I'm in transit
<rg_3[m]> well, looks like, from my hack, there's problems :)
<headius[m]> It's a little silt that it isn't there already
<headius[m]> Silly
<rg_3[m]> i'm probably getting away with it on crubys concurrency model i guess
<headius[m]> Ugh redcarpet
<headius[m]> Had JRuby support until a couple years ago and then dropped us
<headius[m]> That's not a terrible hack
<rg_3[m]> i'm using that because it understands github flavored markdown & integrates with yard basically adds github flavored makrdown support to yard
<headius[m]> Yeah nothing wrong with the library
<headius[m]> Second class citizen problems
<rg_3[m]> lol
<rg_3[m]> yeah, it's unfortunate
<rg_3[m]> but i think there's a nicer way to do that than i did, using bundler `platform` option
<rg_3[m]> the error i get back from jruby is pretty odd
<rg_3[m]> that line, 105, is Thread.new do
<rg_3[m]> i guess whatever i'm doing is probably unsafe on the jvm?
<headius[m]> no that's just a bug
<headius[m]> file that
<headius[m]> that should definitely not happen
<rg_3[m]> alright
<headius[m]> woot, reproduces
<headius[m]> yeah tracing weirdness
<headius[m]> oh neat
<headius[m]> this is some side effect of us trying to re-raise the exception in main thread I think
<headius[m]> yeah I might play with this on the plane tomorrow
<rg_3[m]> yeah, that code tries to raise on the main Thread under some scenarios
<headius[m]> aha
<headius[m]> that makes sense then
<headius[m]> ok yeah I bet I know
<headius[m]> it's trying to re-raise the exception from the thread to main
<headius[m]> but the thread has terminated and has no call stack anymore
<rg_3[m]> :D
<rg_3[m]> cool
<headius[m]> but the raise tries to trigger a :raise trace event, which captures binding... but there's no frame... soo....
<rg_3[m]> messy
<headius[m]> weird case
<rg_3[m]> ya
<headius[m]> yeah report_on_exception branch
<headius[m]> might be able to work around it by setting Thread.current.report_on_exception = false
<rg_3[m]> i was going to ask that
<headius[m]> it's a problem because it tries to print out the exception on the same thread... as it's dying
<rg_3[m]> is jruby breaking from the default there?
<headius[m]> yah
<rg_3[m]> ah o
<rg_3[m]> ok*
<headius[m]> well I mean we shouldn't break but that's why it's printing
<rg_3[m]> i mean, usually abort_on_exception is false?
<headius[m]> it is but report defaults to something true-ish now I think
<headius[m]> I requested the feature so I really should know but I don't remember what they settled on
<headius[m]> it's not off though
<rg_3[m]> lol
<headius[m]> hmm I'm not immediately sure how to fix this
<headius[m]> I think we need to print the exception using only internal code though
<headius[m]> which seems reasonable
<rg_3[m]> haha damn
<rg_3[m]> it's passing all my tests now
<headius[m]> 😎
<rg_3[m]> oh well, almost, i mean some differences about "c-return" and "c_return" from set_trace_func
<headius[m]> that's not too surprising
<headius[m]> we have different things as "c" calls... some of ours are in ruby
<rg_3[m]> but most of the failures were caused by cases where i was still calling Thread#set_trace_func on jruby
<headius[m]> oh wait underscore?
<headius[m]> we should match that
<rg_3[m]> the failure is
<rg_3[m]> more interesting tho, there's a binding-related failure
<rg_3[m]> this fails :( which sucks
<headius[m]> so it's supposed to be c-return?
<headius[m]> we've had this code for like a decade
<rg_3[m]> yep, those are reported as c-return, c-call
<rg_3[m]> not sure about the others though
<headius[m]> 😳
<headius[m]> roll for disbelief
<rg_3[m]> lol
<headius[m]> wow it is
<rg_3[m]> for sure, those specs pass pass on cruby
<headius[m]> I think it's literally just those two
<headius[m]> the others appear to be all underscores in CRuby source
<rg_3[m]> consistent -_-
<rg_3[m]> sadly the test that makes that project most useful fails, the one where code is altered
<headius[m]> I'm flabbergasted
<rg_3[m]> i would have been pretty surprised if it worked as i always assumed that project relied on MRI quirks
<headius[m]> give me your updated patch
<headius[m]> it's quirky but there's tests
<headius[m]> I'm just shocked that there's none to catch the dash vs underscore
<headius[m]> where did you disable exception reporting
<rg_3[m]> i just pushed
<headius[m]> I have a trivial patch for the dash/underscore thing, I just want to confirm
<rg_3[m]> i didn't have to disable reporting after fixing the other issue
<rg_3[m]> which was trying to call Thread#set_trace_func on jruby
<rg_3[m]> there's only 3 failures now, 2 for c-call / c-return and one binding-related one
<headius[m]> ok
<rg_3[m]> ruby --debug -S rspec spec/
<rg_3[m]> should do it
<headius[m]> I'm missing something because I still get the ArrayIndexOutOfBounds
<rg_3[m]> weird, the most recent commit should be 3f193aa643c7995f14a2fd3ae2a34691ae4032cc
<headius[m]> master?
<rg_3[m]> oh no sorry
<rg_3[m]> jruby branch
<headius[m]> ohhh
<headius[m]> ok I see
<headius[m]> one failure
<headius[m]> Failure/Error: expect(event.binding.eval('sum')).to eq(9)
<headius[m]> otherwise good
<rg_3[m]> yeah, but that is the worst failure
<rg_3[m]> it indicates that the change in the binding isn't seen
<headius[m]> I have my suspects
<headius[m]> but that's out of scope tonight
<rg_3[m]> :)
<rg_3[m]> thanks a lot for your help!
<headius[m]> if you can put that in a bug my friend enebo might see it
<rg_3[m]> sure, i'll whip up an issue in the morning with context
<headius[m]> cool, I'll look for it tomorrow... just flying
<rg_3[m]> np, thanks for all the help
_whitelogger has joined #jruby
lucasb has joined #jruby
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 258 seconds]
<headius[m]> heh
<headius[m]> no wonder
<headius[m]> looks like this has been around since 2010
<headius[m]> amazing
klobuczek[m] has joined #jruby
<klobuczek[m]> headius: in reference to https://github.com/jruby/jruby/issues/6089 when I set JRUBY_HOME to the project root the maven build fails
<headius[m]> Can you show me?
<headius[m]> Have you been able to narrow down what's slower?
<headius[m]> I really want closure on this before 9.2.11
<headius[m]> How did you launch that build?
<klobuczek[m]> sorry missed the top:
<klobuczek[m]> ```heinrich@berlin:~/mck/jruby$ export JRUBY_HOME=/Users/heinrich/mck/jruby
<klobuczek[m]> heinrich@berlin:~/mck/jruby$ ./mvnw clean```
<headius[m]> Hmm
<klobuczek[m]> ```heinrich@berlin:~/mck/jruby$ export JRUBY_HOME=/Users/heinrich/mck/jruby
<klobuczek[m]> heinrich@berlin:~/mck/jruby$ ./mvnw clean```
<headius[m]> Well I don't know why it failed but try unsetting env
<klobuczek[m]> the it works
<klobuczek[m]> but what about gems? do I have to run bundle after each build
<klobuczek[m]> * but what about gems? do I have to run bundle after each build?
ur5us_ has joined #jruby
<klobuczek[m]> I would like to get to a point where I can run rspec from a different directory than the jruby build
<klobuczek[m]> I think I have something for you: https://travis-ci.org/neo4jrb/neo4j
<klobuczek[m]> all open source
<klobuczek[m]> but the setup is not trivial
<klobuczek[m]> but it is much simpler than our commercial and confidential project. It exhibits 4 times slower tests on 9.2.10.0
<headius[m]> Oh you use neo eh?
<headius[m]> Do not need to rebundle
<headius[m]> Just rebuild
ur5us__ has joined #jruby
ur5us_ has quit [Ping timeout: 240 seconds]
<klobuczek[m]> but https://travis-ci.com/neo4jrb/neo4j-ruby-driver does not expose the same slowdown on 9.2.10.0
ur5us__ has quit [Remote host closed the connection]
<headius[m]> ok, so it's probably not in there
<headius[m]> does your test suite spin up a lot of subprocesses?
<klobuczek[m]> no, not at all
<headius[m]> ok so probably not a launching issue
<headius[m]> did you see the basic instructions I posted for getting a profile?
<headius[m]> there's another option I think works out of the box on Java 11: -Xrunhprof:cpu=samples
<headius[m]> that's a JVM option
<headius[m]> I am confused
ur5us has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]
Antiarc_ has quit [Ping timeout: 265 seconds]
Antiarc has joined #jruby
mistergibson has joined #jruby
mistergibson has quit [Client Quit]
ur5us has quit [Ping timeout: 240 seconds]