anianna has quit [Remote host closed the connection]
anianna[m] has joined #jruby
<anianna[m]>
Hi,
<anianna[m]>
This is regarding JRuby tests. Multiple JRuby tests fail with "NoMethodError: undefined method `exclude' for main:Object". I am running on docker
<anianna[m]>
nearly 284 tests fail due to this error
<headius[m]>
enebo: first pass through the PR looks reasonable to me
<headius[m]>
I saw johnphillips31416 posted something about a deadlock but would that be related to your stuff at all?
<headius[m]>
anianna: hello!
<headius[m]>
9.2.0.0 is over two years old now I believe, you should try to use current sources from jruby-9.2 branch on Github
<headius[m]>
Also, the tests in test/mri should be run using test/mri/runner, which loads support for "excludes" we use to filter out tests known to be failing
<headius[m]>
runner.rb
<headius[m]>
the files in test/mri/excludes are the place we put those excludes, and they're loaded automatically if you run with the runner.rb and pass --excludes=test/mri/excludes
<headius[m]>
If this isn't documented in the BUILDING.md file it should be
ilikeorangutans[ has joined #jruby
<enebo[m]>
headius: yeah I just had some lunch and have been pondering how anything could cause this
<enebo[m]>
prepareXXX are the only two methods which use synchronize
<headius[m]>
it doesn't seem to be deadlocked anywhere near those if I read the trace right
<enebo[m]>
at this point they probably do not even need to now but I do not see how those could be the cause at all
<headius[m]>
and prepare is pretty leafy so it shouldn't be held long
<enebo[m]>
Well no but it is just one thread on a sleep
<headius[m]>
yeah
<enebo[m]>
I did not get a direct answer to my question so I am still wondering
<ilikeorangutans[>
hi friends, i'm running into some surprising behaviour with BigDecimals that I don't understand. For reasons I don't quite understand our codebase uses `BigDecimal` but also import `java.math.BigDecimal` and to keep the ruby version available, it assigns `RubyBigDecimal = BigDecimal` before the java import (i know, i know). Now, this happens:
<ilikeorangutans[>
```
<enebo[m]>
When not on this branch does warbler load work. I guess it is implied a yes
<headius[m]>
first off I'd recommend leaving the Ruby one in place and aliasing the Java one... there are other places throughout JRuby that expect "BigDecimal" to be the Ruby one
<enebo[m]>
and those two lines are literally in a row like that or is that a before/after
<headius[m]>
enebo: yeah I assumed it's working otherwise
<headius[m]>
but that is not 100% clear
<ilikeorangutans[>
<headius[m] "first off I'd recommend leaving "> can i alias the java version just like the ruby version? like `JavaBigDecimal = BigDecimal`?
<ilikeorangutans[>
wait, java_import takes a block??
<headius[m]>
yeah actually the block takes |package, classname| but usually you're just giving it a new name altogether
<ilikeorangutans[>
neat!
<headius[m]>
it's an older form before you could just assign a constant with the dotted package, which I like better personally
<enebo[m]>
In examining other commits on 9.2.12.0 and IR changes I do not see what would cause this
<enebo[m]>
The only possible thing I see which made me pause is we synch prepareXXX
<enebo[m]>
We have done that forever though
<enebo[m]>
The main difference now is fullInterpreterContext is set later within those methods
<johnphillips3141>
Sorry for the confusion. I've tested previously with 9.2.12.0 and had no issues, and Ive tested the ir_concurrency branch previously
<johnphillips3141>
But in my latest testing my Warbler jar hangs at startup.
<headius[m]>
consistently?
<johnphillips3141>
Yes, I've built and tried several times
<headius[m]>
ok
<headius[m]>
mysterious
<johnphillips3141>
Can u think of anything I should try?
<enebo[m]>
bisecting might since it seems to have worked at some point during the branch
<johnphillips3141>
I thought maybe since Warbler has a different jruby entry point some initialization got skipped
<enebo[m]>
I am not sure what it would uncover since I have no ideas atm
<enebo[m]>
Well it is possible there is extra synchronization and with multiple threads maybe calling in somehow something locks?
<enebo[m]>
I am just spitballing
<johnphillips3141>
I'm building locally off the branch so possibly I'm not doing it right
<johnphillips3141>
But I've been successful previously
<johnphillips3141>
I build the jruby jars and gem install into my dev env
<enebo[m]>
The least sophisticated way of building which will work is 'mvn clean; mvn'
<enebo[m]>
I always force full builds in this case
<enebo[m]>
does warbler use jruby-complete?
<johnphillips3141>
I'll try a clean build
<johnphillips3141>
Not sure I know what that is
<enebo[m]>
johnphillips31416: ah jruby-complete.jar can get generated which is jruby.jar and all of stdlib packaged together
<enebo[m]>
yeah. ScriptingContainer has multiple execution modes too so I should grab warbler and see which one it uses
<johnphillips3141>
Warbler pulls in jruby via jruby-jars gem
<johnphillips3141>
I posted a link to the Warbler code in the ticket
<enebo[m]>
newScriptingContainer appears to use default no-arg constructor via reflection
<enebo[m]>
So it is run in SINGLETON mode which means it will only enable one JRuby runtime
<enebo[m]>
The stack is just not really close to what we have been changing...Some ruby code calls Kernel#sleep and then there it sits
<enebo[m]>
A git bisect might help if it identifies a consistent commit but only because nothing it jumping out
<enebo[m]>
The basic question of what is different with ScriptingContainer will probably end up being the right question but my answer at this point would be nothing
<enebo[m]>
This particular mode does store the runtime as a static field and does not run any runtime teardown
<enebo[m]>
If we think of those two things and how it affects startup though?
<enebo[m]>
I see this is doing a send to something which is doing a sleep
<enebo[m]>
I will look around send a little bit
<johnphillips3141>
We've been using Warbler for several years, currently w jruby 9.2.9.0
<enebo[m]>
yeah I am sure our changes on this branch is doing it somehow
<enebo[m]>
At some level I could see if somehow we were reading the wrong variable scope it could change what argument sleep is getting and it is just sleeping a loooong time or something
<enebo[m]>
which would imply not a deadlock at all...OTOH why would it work from jruby commandline but not from embedding
<johnphillips3141>
Is there a jruby jar gem artifact from this branch? I can try using it instead of my own
<headius[m]>
nothing pushed as part of our builds but it shouldn't be very different... how are you building it?
<johnphillips3141>
Just ./mvnw -Pjruby-jars
<headius[m]>
should be fine, I don't think there's anything else required right enebo ?
<johnphillips3141>
We set BUNDLER_VERSION to 2.0.2
<headius[m]>
so if you swap the ir_concurrency jar for one from a 9.2.12 build it works ok, no other changes
<headius[m]>
looking at your trace again now
<johnphillips3141>
I built and tried ir_concurrency last week
<johnphillips3141>
Successfully
MattPattersonGit has quit [Ping timeout: 244 seconds]
alfred[m]1 has quit [Ping timeout: 244 seconds]
TimGitter[m]1 has quit [Ping timeout: 244 seconds]
<headius[m]>
ok
MattPattersonGit has joined #jruby
alfred[m]1 has joined #jruby
ilikeorangutans[ has quit [Ping timeout: 244 seconds]
TimGitter[m]1 has joined #jruby
kalenp[m] has quit [Ping timeout: 244 seconds]
shiri[m] has quit [Ping timeout: 244 seconds]
chrisseaton[m] has quit [Ping timeout: 244 seconds]