00:05
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:01
lopex has quit [Quit: Connection closed for inactivity]
05:53
sidx64 has joined #jruby
05:59
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
06:00
sidx64 has joined #jruby
06:00
sidx64 has quit [Client Quit]
06:32
sidx64 has joined #jruby
06:36
sidx64 has quit [Client Quit]
06:45
sidx64 has joined #jruby
06:57
sidx64 has quit [Read error: Connection reset by peer]
06:58
sidx64 has joined #jruby
07:05
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:10
sidx64 has joined #jruby
07:13
sidx64_ has joined #jruby
07:14
sidx64 has quit [Read error: Connection reset by peer]
07:17
sidx64 has joined #jruby
07:17
sidx64_ has quit [Ping timeout: 252 seconds]
07:18
sidx64 has quit [Client Quit]
07:20
sidx64 has joined #jruby
07:34
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:35
sidx64 has joined #jruby
08:09
<
GitHub25 >
jruby/master db8f5e3 kares: [ji] support (Java) String proxy unwrapping on a few places
08:09
<
GitHub25 >
jruby/master 23dd24f kares: minor: remove unused private method
08:31
Specialist has joined #jruby
08:47
<
GitHub45 >
[jruby] kares opened pull request #5180: [ji] RubyString implements CharSequence (master...rubystring-impl-charsequence)
https://git.io/vpjgQ
09:31
lopex has joined #jruby
09:36
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:37
sidx64 has joined #jruby
09:38
Specialist has quit [Ping timeout: 245 seconds]
09:40
<
kares >
... since we only get a chance to do 'small' breaking changes in major releases
09:57
chasm has joined #jruby
09:58
<
chasm >
re: rvm , is jruby-head jruby-9.1.17.0 ? thanks
10:05
chasm has joined #jruby
10:06
chasm has quit [Client Quit]
10:06
chasm has joined #jruby
10:07
chasm has quit [Client Quit]
10:08
chasm has joined #jruby
10:09
chasm has quit [Client Quit]
10:09
chasm has joined #jruby
10:10
chasm has quit [Client Quit]
10:11
chasm has joined #jruby
10:13
chasm has quit [Client Quit]
10:13
chasm has joined #jruby
10:15
chasm has quit [Client Quit]
10:16
chasm has joined #jruby
10:17
chasm has quit [Client Quit]
10:17
chasm has joined #jruby
10:18
chasm has quit [Client Quit]
10:18
chasm has joined #jruby
10:19
chasm has quit [Client Quit]
10:20
chasm has joined #jruby
10:21
chasm has quit [Client Quit]
10:21
chasm has joined #jruby
10:22
chasm has quit [Client Quit]
10:22
chasm has joined #jruby
10:25
chasm has quit [Client Quit]
10:25
chasm has joined #jruby
10:26
chasm has quit [Client Quit]
10:26
chasm has joined #jruby
10:27
chasm has quit [Client Quit]
10:28
chasm has joined #jruby
10:29
chasm has quit [Client Quit]
10:29
chasm has joined #jruby
10:30
chasm has quit [Client Quit]
10:30
chasm has joined #jruby
10:31
chasm has quit [Client Quit]
10:32
chasm has joined #jruby
10:33
chasm has quit [Client Quit]
10:33
chasm has joined #jruby
10:34
chasm has quit [Client Quit]
10:34
chasm has joined #jruby
10:35
chasm has quit [Client Quit]
10:36
chasm has joined #jruby
10:36
sidx64 has quit [Read error: Connection reset by peer]
10:37
sidx64 has joined #jruby
10:37
chasm has quit [Client Quit]
10:38
chasm has joined #jruby
10:39
chasm has quit [Client Quit]
10:40
chasm has joined #jruby
10:41
chasm has quit [Client Quit]
10:41
chasm has joined #jruby
10:43
kamal__ has joined #jruby
10:45
chasm has quit [Client Quit]
10:45
<
kamal__ >
Hi, I am facing one issue with activerecord-jdbc-adapter on jruby 1.7.4. Here is the question on stackoverflow.
10:45
chasm has joined #jruby
10:46
chasm has quit [Client Quit]
10:46
chasm has joined #jruby
10:47
chasm has quit [Client Quit]
10:48
chasm has joined #jruby
10:49
chasm has quit [Client Quit]
10:49
chasm has joined #jruby
10:50
chasm has quit [Client Quit]
10:50
chasm has joined #jruby
10:53
chasm has quit [Client Quit]
10:53
chasm has joined #jruby
10:54
chasm has quit [Client Quit]
10:54
chasm has joined #jruby
10:56
chasm has quit [Client Quit]
10:56
chasm has joined #jruby
10:58
chasm has quit [Client Quit]
10:58
chasm has joined #jruby
11:01
chasm has quit [Client Quit]
11:01
chasm has joined #jruby
11:02
chasm has quit [Client Quit]
11:02
chasm has joined #jruby
11:03
chasm has quit [Client Quit]
11:04
chasm has joined #jruby
11:05
chasm has quit [Client Quit]
11:05
chasm has joined #jruby
11:06
chasm has quit [Client Quit]
11:06
chasm has joined #jruby
11:07
chasm has quit [Client Quit]
11:08
chasm has joined #jruby
11:09
chasm has quit [Client Quit]
11:09
chasm has joined #jruby
11:10
jrafanie has joined #jruby
11:11
chasm has quit [Client Quit]
11:12
chasm has joined #jruby
11:13
chasm has quit [Client Quit]
11:13
chasm has joined #jruby
11:14
chasm has quit [Client Quit]
11:14
chasm has joined #jruby
11:15
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:17
chasm has quit [Client Quit]
11:17
chasm has joined #jruby
11:17
Puffball has joined #jruby
11:18
chasm has quit [Client Quit]
11:18
sidx64 has joined #jruby
11:19
chasm has joined #jruby
11:21
chasm has quit [Client Quit]
11:21
chasm has joined #jruby
11:22
chasm has quit [Client Quit]
11:22
chasm has joined #jruby
11:23
chasm has quit [Client Quit]
11:24
chasm has joined #jruby
11:24
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:25
CT-Rahul has joined #jruby
11:26
chasm has quit [Client Quit]
11:27
chasm has joined #jruby
11:27
<
CT-Rahul >
OpenSSL::SSL::SSLError: handshake alert, i am facing this error in jruby
11:29
chasm has quit [Client Quit]
11:29
chasm has joined #jruby
11:30
chasm has quit [Client Quit]
11:30
chasm has joined #jruby
11:31
chasm has quit [Client Quit]
11:32
chasm has joined #jruby
11:33
chasm has quit [Client Quit]
11:33
chasm has joined #jruby
11:35
chasm has quit [Client Quit]
11:36
chasm has joined #jruby
11:37
chasm has quit [Client Quit]
11:37
chasm has joined #jruby
11:38
chasm has quit [Client Quit]
11:40
chasm has joined #jruby
11:41
chasm has quit [Client Quit]
11:41
chasm has joined #jruby
11:42
chasm has quit [Client Quit]
11:42
chasm has joined #jruby
11:43
chasm has quit [Client Quit]
11:44
chasm has joined #jruby
11:45
chasm has quit [Client Quit]
11:45
chasm has joined #jruby
11:46
chasm has quit [Client Quit]
11:46
chasm has joined #jruby
11:47
chasm has quit [Client Quit]
11:48
chasm has joined #jruby
11:49
chasm has quit [Client Quit]
11:49
chasm has joined #jruby
11:50
chasm has quit [Client Quit]
11:50
chasm has joined #jruby
11:50
chasm has quit [Client Quit]
11:51
drbobbeaty has quit [Ping timeout: 276 seconds]
11:52
drbobbeaty has joined #jruby
11:56
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
11:59
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
12:02
sidx64 has joined #jruby
12:05
jsvd has joined #jruby
12:08
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
12:12
sidx64 has joined #jruby
12:13
sidx64 has quit [Client Quit]
12:14
<
GitHub84 >
jruby/deprecate-subclasses 83e4e76 kares: [refactor] avoid using Function1 -> replaced with Java 8 Consumer
12:14
<
GitHub84 >
jruby/deprecate-subclasses e310f43 kares: deprecate Function1 and replace its only use with a Java 8 Consumer
12:14
<
GitHub84 >
jruby/deprecate-subclasses 91ddfd8 kares: [fix] keyword extract -> don't use Hash#keySet since converts toJava
12:16
<
GitHub186 >
[jruby] kares opened pull request #5181: deprecate jruby/core_ext Class#subclasses (master...deprecate-subclasses)
https://git.io/vpj5q
12:17
<
kares >
kamal__: that might be non fixable depending on AR version you're using
12:17
<
kares >
it usually works when the AR pool is avoided -> never got to the bottom of this
12:18
<
kares >
anyways reconnect: true is really an anti-pattern on MySQL
12:38
<
GitHub191 >
jruby/master bae5d69 kares: [fix] keyword extract -> don't use Hash#keySet since converts toJava
12:39
<
GitHub28 >
jruby/deprecate-subclasses 3475604 kares: deprecate Function1 and replace its only use with a Java 8 Consumer
12:39
<
GitHub28 >
jruby/deprecate-subclasses 3fb8039 kares: [refactor] avoid using Function1 -> replaced with Java 8 Consumer
12:39
<
GitHub28 >
jruby/deprecate-subclasses 003b9ee kares: deprecate Class#subclasses from jruby/core_ext ... move it to JRuby...
12:57
jsvd has left #jruby [#jruby]
13:04
sidx64 has joined #jruby
13:04
sidx64 has quit [Client Quit]
13:06
sidx64 has joined #jruby
14:05
jrafanie has joined #jruby
14:08
kamal__ has quit [Ping timeout: 260 seconds]
14:17
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
14:35
sidx64 has joined #jruby
16:00
shellac has joined #jruby
16:02
xardion has quit [Remote host closed the connection]
16:08
xardion has joined #jruby
16:11
shellac has quit [Ping timeout: 245 seconds]
17:09
subbu is now known as subbu|away
17:23
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:27
sidx64 has joined #jruby
17:31
sidx64 has quit [Client Quit]
17:54
ahorek has joined #jruby
17:55
akp has joined #jruby
17:55
akp has quit [Client Quit]
17:57
ahorek has quit [Client Quit]
18:01
drbobbeaty has joined #jruby
19:08
subbu|away is now known as subbu
19:11
Specialist has joined #jruby
19:22
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:29
ahorek has joined #jruby
19:29
ahorek has quit [Client Quit]
19:46
jrafanie has joined #jruby
20:12
ahorek has joined #jruby
20:13
<
GitHub35 >
jruby/jruby-9.1 9d6f877 Thomas E. Enebo: Fixes #5179. On eval of Time#strftime read from file: Java::JavaLang::Error: Unknown special char: Y...
20:13
<
headius >
enebo: the problem is that the array gets accessed without going through Formt
20:14
<
headius >
so the Format enum never inits
20:14
<
headius >
so the array never populates
20:14
<
headius >
there's a previous hack in there that kares commented out, I just commented on the issue
20:14
<
headius >
same thing you did
20:14
<
headius >
I have a fix that avoids needing a hack
20:14
<
enebo >
I was hoping I had commented enough to explain that
20:15
<
GitHub163 >
jruby/master 3b228b2 Thomas E. Enebo: Merge branch 'jruby-9.1'
20:16
<
GitHub199 >
[jruby] enebo closed issue #5179: On eval of Time#strftime read from file: Java::JavaLang::Error: Unknown special char: Y
https://git.io/vphSF
20:16
<
enebo >
headius: on one hand this static side-effect is a bit clever but on the other it is sort of surprising javac cannot see that constructor writing a static field. I guess I wonder what enum semantics actually are?
20:17
<
headius >
it never accesses the enum
20:17
<
enebo >
I mean are enums defined as lazy loaded on demand
20:17
<
headius >
if ASCIIEncoding
20:17
<
enebo >
yeah I explained all of that I thought
20:17
<
enebo >
in the commit message
20:17
<
headius >
ok what are you confused about then?
20:17
<
headius >
I must not be following
20:17
<
enebo >
why Java works this way I guess
20:17
<
enebo >
not that it does
20:17
<
headius >
well the enum is never initialized...so the enum values are never constructed
20:17
<
headius >
the array accesses elsewhere don't trigger that initialization
20:18
<
enebo >
so enums being defined is a halting problem if they have side-effects
20:18
<
headius >
the array is a static field on an unrelated class so accessing it doesn't trigger the Format constructors
20:18
<
kares >
staticInitializerHack :)
20:18
<
headius >
well, it's not a halting problem
20:18
<
headius >
but you have to actually access it
20:19
<
enebo >
yeah the access part I think was confusing part for me
20:19
<
headius >
all classes in Java are lazily initialized on first access
20:19
<
enebo >
I would expect them to be like types or I have thought of them at that level
20:19
<
headius >
static inits don't run until you access the class the first time though
20:19
<
enebo >
I guess I have not see this with types themselves
20:19
<
headius >
which includes constructing all the enum values
20:19
<
enebo >
but that does make more sense
20:20
<
headius >
the bug is that accessing the array does not trigger the initialization to fill it
20:20
<
enebo >
if I have a static field in RubyString but never reference it I do not expect that field to have been hit yet
20:20
<
headius >
the fix I was working on locally forced all accesses to go through a Format method
20:20
<
enebo >
yeah I totally understand why it did not work I just had mismatched expectations on how enums come into being
20:21
<
headius >
yeah it was confusing until I saw it was empty
20:21
<
headius >
at that point it had to be a class init issue
20:21
<
enebo >
It is doubly weird in a way since the method where we have that code path will reference the enum in a few ways ... but nothing constructs until the first actual reference
20:21
<
kares >
couldn't the current fix blow if say an agresive compiler removed dead code
20:22
<
kares >
e.g. on graal - assuming in treats enums as side effect free
20:22
<
enebo >
kares: C1 runs first though
20:22
<
enebo >
kares: I would think once it is live it is ok to stay alive even if that init is DCEd
20:23
<
kares >
okay maybe that wasn't a good example
20:23
<
enebo >
kares: but generically you are right it may not work somewhere
20:23
<
kares >
maybe if it was compiled into a native image ...
20:23
<
enebo >
kares: for all I know j9 kills it before it makes bytecode
20:23
<
kares >
najs - good to know
20:23
<
enebo >
kares: excelsior may kill it as an AOT perhaps
20:24
Specialist has quit [Ping timeout: 256 seconds]
20:24
<
enebo >
I did add a FIXME: too. I just did not think this was worth a lot of time this week
20:24
<
kares >
yy np just asking :)
20:24
<
enebo >
kares: yeah np I think it is good to bring up questions
20:24
<
headius >
I'll just finish my fix for your fixmu
20:25
<
enebo >
headius: yeah cool
20:25
<
enebo >
I thought about values() for looping and doing it outside then went bleh
20:25
<
headius >
yeah I'm just cheating
20:25
<
headius >
moved the static array inside format and used static util methods to populate it
20:26
<
enebo >
headius: so it will just static init with values and take it out of the constructor
20:26
<
headius >
so now you can't get it without going through format
20:26
<
enebo >
yeah I should have just did that. I was lazy :)
20:32
<
headius >
entertaining bug though
20:32
<
headius >
java puzzler quality
20:33
<
headius >
enebo: so I was never able to get stack overflow btw
20:33
<
headius >
I messed with it on friday but never got anywhere so went back to 9.2 finalization
20:33
<
enebo >
headius: well I should rerun again but you have your result numbers?
20:34
<
enebo >
headius: my merge was bad :P
20:34
<
enebo >
I will assume you will fix as you land your fix
20:37
<
headius >
enebo: yeah I'll fix you up
20:38
<
enebo >
headius: and rerun sqlite3 since I want to see how we differ
20:38
<
headius >
give me your exact command line again
20:38
<
enebo >
headius: I did run and notice invidual files will run clean so something in testing is messing something up
20:39
<
enebo >
RAILS=`pwd`/../rails jrake rails:test_sqlite3 --trace 2>&1 > aaa
20:39
<
enebo >
I am only redirecting because it creates a couple of hundred thousand lines of backtraces
20:39
<
headius >
no --dev in env or anytthing
20:40
<
enebo >
headius: no although --dev will cause other issues
20:41
<
headius >
lopex: if we figure out this error, maybe :-)
20:42
<
enebo >
lopex: Also perhaps an AS issue
20:42
<
lopex >
as/400 ? :P
20:42
<
enebo >
active support 400
20:43
<
lopex >
enebo: I biased so forgive me
20:43
<
enebo >
lopex: forgiven
20:43
<
GitHub152 >
jruby/jruby-9.1 6b7d821 Charles Oliver Nutter: Try to avoid class init hacks by forcing accesses through Format....
20:44
<
headius >
I feel like I've done this enum pattern before without these problems
20:45
<
enebo >
headius: yeah me too
20:45
<
headius >
I guess the main difference is that the accesses of the array happen directly within this class
20:45
<
enebo >
5226 runs, 14463 assertions, 10 failures, 92 errors, 8 skips
20:45
<
headius >
normally they'd happen from outside and force some inits
20:45
<
enebo >
headius: no doubt we will access something right away so we never noticed when it was stood up
20:45
<
GitHub52 >
jruby/master 44c6157 Charles Oliver Nutter: Merge branch 'jruby-9.1'
20:46
<
enebo >
only accessing an enum indirectly from an array or other structure is probably rare without at least some check like, "is it this enum value"
20:46
<
headius >
that fix isn't great but it avoids having a poison pill lying around
20:47
<
headius >
enebo: I guess I mark that as 9.1.18?
20:47
<
enebo >
headius: yeah
20:48
<
enebo >
lowest version should always be the fix until github allows us to mark multiples
20:48
<
headius >
ok I'm trying to run sqlite3 now
20:48
<
enebo >
so running independent tests with these problems do not trigger
20:48
<
enebo >
I SMELL PREPEND IN TESTS
20:49
<
headius >
you and your jrake
20:50
<
enebo >
I only have like 2 aliases too
20:50
<
enebo >
jrake and jb for mvn -pl core
20:51
<
headius >
so first off this is way slower than I remember it, not sure if I have some env issue
20:51
<
enebo >
you said that last week too...how long do you remember these tests taking?
20:51
<
headius >
and now it gets to this point and seems to just hang
20:51
drbobbeaty has quit [Ping timeout: 252 seconds]
20:51
<
headius >
maybe I'm just not noticing the hang soon enough
20:51
<
headius >
but it never completes
20:51
<
enebo >
def test_connection_pool_starts_reaper
20:52
<
enebo >
I will exclude this
20:52
<
enebo >
headius: you hitting this again?
20:52
<
headius >
I thought I nuked that
20:52
<
headius >
ugh, and ctrl+\ doesn't work?
20:52
<
headius >
oh I see, goes to redirect
20:53
<
headius >
I added unless false to that test method def
20:53
<
headius >
I'll just delete it though
20:53
sidx64 has joined #jruby
20:54
<
enebo >
I am doing exclude...I will commit once I verify I put the exclude in right place
20:54
<
headius >
running with -v now and I'll see where it's hanging
20:54
<
headius >
test is completely deleted from my local copy now
20:54
<
enebo >
I would hope you do not hang since I don't without that test
20:56
<
headius >
oh dummy...unless false
20:56
<
headius >
I feel like a n00b
20:56
<
headius >
so yeah running running running now
20:56
<
headius >
doesn't appear to be belching stack traces yet
20:58
<
headius >
5226 runs, 14447 assertions, 12 failures, 89 errors, 8 skips
20:58
<
headius >
pretty close
20:58
<
enebo >
yeah so not backtraces in aaa?
20:58
<
headius >
I stopped appending but I see a stack issue in add_column
20:59
<
enebo >
yeah add_column and extract_backtrace I think
20:59
<
headius >
also translate_exception
20:59
<
enebo >
yeah I meant that
20:59
<
enebo >
ok same errors then
20:59
<
enebo >
I ran two files which had these independently and they pass
20:59
<
enebo >
so something is mucking up our inheritance during testing
21:00
<
enebo >
exclude pushed
21:01
<
headius >
going to try to get ancestors at that point
21:01
<
enebo >
I could add some loop state in the methods and dump ancestors once the count is highish
21:02
<
enebo >
My last look at ancestors did not show anything but I had a lot of them
21:02
<
headius >
well I'm hoping it will print out immediately before the overflow so I'll be able to find it
21:02
<
headius >
I want to confirm it's the issue my branch is supposed to fix before I spend time finishing the branch
21:03
<
headius >
yeah it works for a while doesn't it
21:03
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:03
<
headius >
and eventually kaboom
21:03
<
enebo >
your prepend branch definitely has issues
21:03
<
enebo >
I could not run AS tests at all with it as one thing I remember
21:10
<
headius >
super fixes branch I mean
21:10
<
headius >
yeah included modules aren't overriding the search logic right
21:10
<
enebo >
so I have two ancestors and I see no difference from just the list of names
21:12
<
headius >
yeah I have some output
21:12
<
enebo >
you see any difference?
21:14
<
headius >
well unsure what before and after would be
21:14
<
headius >
I just have the output immediately before a failure
21:15
<
headius >
it's not different from the output immediately before that though
21:15
<
headius >
I mean, there will be as many of these calls as there are stack overflowing super calls
21:16
<
enebo >
headius: I did a short run and captured in one which did not fail
21:16
<
enebo >
headius: then a full run where I outputted only when I saw it call add_column 10 times (put a counter in it)
21:16
<
enebo >
There are two unnamed modules in both otherwise all modules/classes are exactly the same
21:16
<
headius >
there is one def translate_exception in tests
21:17
<
headius >
actionpack/test/abstract_unit.rb
21:17
<
enebo >
so the other big data point for me is that I can run some of these failures as individual test and they work without error
21:17
<
enebo >
so some test is doing something to us at some point during the run
21:19
<
headius >
yeah or triggering something to load that messes stuff up
21:20
<
headius >
like some additional prepends somewhere
21:20
<
headius >
so the weird thing is that these should be standard supers
21:21
<
headius >
all the definitions of this method I can find are within classes
21:21
<
headius >
i.e. not unresolved
21:21
<
headius >
but something might be triggering IR to make them unresolved
21:22
<
enebo >
I wonder if somehow these definitions are being used in another type but it is remembering the impl class or something like that
21:22
<
enebo >
yeah at this point I have no real clue here past something is changing it during testing
21:22
<
enebo >
Perhaps I can more simply make a brute force tester
21:23
<
enebo >
like add one failing test and all tests before it as n runs until it fails
21:23
<
headius >
%v_30 := instance_super(%current_module, %t_exception_31, %t_message_32, %v_0, callType: SUPER, name: translate_exception, potentiallyRefined: false)
21:24
<
enebo >
unless current_module as input somehow leads to current_module as parent but something is goofy
21:25
<
enebo >
I will try this brute force idea
21:25
<
enebo >
I know first error in list and the files before it
21:25
<
enebo >
so I think I can maybe even bisect half the files and just keep eliminating
21:27
<
enebo >
funny thing is I feel like we will be surprised at whatever is wrong
21:27
<
enebo >
like it won't be prepend at all somehow
21:30
<
enebo >
stripping them away
21:30
<
enebo >
less files testing and some exclusions end up having no failures
21:33
<
enebo >
getting closer
21:35
<
headius >
they are unresolved in the test run
21:36
<
headius >
it's a module in our code
21:36
<
headius >
but a class in theirs
21:37
<
enebo >
ours is a little weirder but the class at bottom of our adapter includes that as a module
21:37
<
enebo >
but it is definitely a difference
21:37
<
headius >
well that at least explains how this can happen
21:40
<
enebo >
with luck it is just a bug from that difference on our side
21:43
<
enebo >
Ok I have it down to one file breaking another files tests: "test/cases/finder_test.rb" "test/cases/ar_schema_test.rb"
21:43
<
enebo >
so finder_test is doing something
21:45
<
enebo >
happens to be translate_excetion as first error
21:45
<
headius >
I don't see anything obvious yet
21:47
<
enebo >
it pulls in a lot of code too
21:49
<
enebo >
just deleting tests until it stops
21:53
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:58
<
enebo >
somehow I noticed as reducing this that assert_raises tests seem important in seeing this
21:59
<
enebo >
I removed different chunks of the file and it woudl go away but then as I remove I can generally keep the problem if I leave those tests in
21:59
<
enebo >
which is not super instructive since the problem is translate_exception
22:01
<
headius >
yeah I went through most of the calls that test makes but none seem to do anything weird with hierarchies
22:04
<
enebo >
I am down to like 5 tests
22:04
<
enebo >
but weirdly I have seen removing different tests will eliminate the issue
22:10
<
enebo >
so both of those test must happen or the overflow in the NEXT FILE does not happen
22:10
<
enebo >
this is super duper weird still
22:11
<
headius >
yeah I can't figure out if that helps or not :-D
22:11
<
enebo >
interesting difference in ARJDBC vs AR in that a massive id in arjdbc raises an error for us but Ar seems to ignore it
22:11
<
enebo >
so that first test probably generates an exception that perhaps we catch again somewhere (or in AR) but it is different in how it bubbles out
22:13
<
enebo >
'require "mocha/setup" # FIXME: stop using mocha'
22:13
<
enebo >
I do not see mocha being used but no doubt it uses some metaprogramming
22:14
<
enebo >
oh wait perhaps I did not save after I removed all those models
22:15
<
headius >
mocking could definitely muck something up
22:15
<
headius >
all bets are off
22:15
<
enebo >
oh ffs emacs is hanging
22:17
<
enebo >
well I had it down to those two tests with all fixtures required and loaded at top of file
22:18
<
headius >
how are you running just those tests
22:21
<
enebo >
so check out updated finder test
22:21
<
enebo >
both of those private def methods seem to also be needed
22:22
<
enebo >
It is getting creepyt
22:22
<
enebo >
It passed once
22:23
<
enebo >
yeah this is occasionally passing
22:23
<
enebo >
mostly not though
22:23
<
enebo >
headius: Can you run that and see same thing
22:24
<
headius >
enebo: so replace their finder_test with this
22:25
<
enebo >
headius: I whittled it down to as small as I thought it could go
22:25
<
enebo >
but now I wonder if perhaps I run the single ar_schema_test 100 times will it fail on its own
22:28
<
enebo >
ok I cannot actually get it on its own to fail...that small finder_test needs to be there too
22:28
<
enebo >
I was able to remove most of the requires and leave the fixture to topic and companies
22:32
<
headius >
enebo: yeah
22:32
<
enebo >
class TestCase
22:32
<
enebo >
parallelize_me!
22:32
<
enebo >
if RUBY_ENGINE == "ruby" && PROCESS_COUNT > 0
22:33
<
headius >
enebo: it works without JIT
22:34
<
headius >
oh wait no
22:34
<
headius >
it worked ok with jit with your modified test
22:34
<
enebo >
well test/cases/finder_test.rb load error: cases/helper -- java.lang.StackOverflowError: null
22:34
<
headius >
not for me
22:34
<
enebo >
I cannot bootstrap the tests with JRUBY_OPTS=-X-C
22:35
<
headius >
works ok for me
22:35
<
headius >
oh wait...-X-C works but --dev errors?
22:35
<
headius >
nevermind, they both error
22:35
<
headius >
but jit threshold=-1 is ok
22:36
<
headius >
threshold=0 fails the same way
22:36
<
headius >
something wrong with full build?
22:36
<
headius >
and by extension jit
22:37
<
headius >
so that is probably not related though
22:37
<
enebo >
headius: it is weirdly also a stackoverflow for me too
22:38
<
enebo >
just different
22:38
<
headius >
I still don't get stack error with your modified finder_test
22:38
<
enebo >
so I commented out minitest parallel stuff which I do not think is for these tests just in case
22:38
<
enebo >
headius: I am thinking it must be a race
22:39
<
enebo >
headius: and you added the larger snippet once I edited the gist?
22:39
<
headius >
I just got it running a second time
22:39
<
headius >
so yeah some background thread
22:39
<
enebo >
So something comes in and modifies something in a bad way but not always
22:40
<
enebo >
once it is in a bad way though it never seems to resolve after that point
22:40
<
enebo >
since I get pretty much the same results on full runs
22:44
<
enebo >
headius: dinner for me
22:47
<
enebo >
headius: are you on IM?
22:47
<
headius >
I have it handy
22:48
<
enebo >
I have been messaging you so I was not sure if perhaps I am not actually on hangouts
22:50
<
lopex >
what ims are you using ?
22:51
<
lopex >
enebo: btw have you seen that ebcdic video ?
22:51
<
enebo >
lopex: google hangouts
22:51
<
enebo >
lopex: going to eat dinner
22:52
<
lopex >
enebo: especially for a dinner
22:58
projectodd-ci has quit [Ping timeout: 256 seconds]
23:19
<
headius >
enebo: last message I have from you in hangouts is from Thursday
23:21
<
lopex >
so unreliable
23:21
<
lopex >
enebo: busted
23:22
<
lopex >
headius: hey, have you thought about running windows ci on that windows subsystem for linux ?
23:22
<
lopex >
I know it's dev only
23:23
<
headius >
lopex: you mean the linux for windows thing?
23:23
<
lopex >
headius: mri builds on it easily
23:24
<
lopex >
but I had problems with jruby
23:24
<
headius >
huh, do you remember what?
23:24
<
lopex >
headius: and hats down for them actually
23:24
<
lopex >
headius: I'll have to reproduce
23:25
<
headius >
I suppose this is a use case we should be looking to support
23:25
<
lopex >
headius: jvm and maven worked
23:25
<
lopex >
and all through that subsystem calls via glibc
23:25
<
lopex >
I think is quite astonishing
23:26
<
lopex >
er, like glibc calls through their impls
23:26
<
lopex >
headius: I can check that if you want
23:27
<
headius >
yeah that would be good, I don't have a windows handy right now
23:27
<
lopex >
headius: the only thing they lack is cgroups so the cannot run any docker thingies
23:28
<
lopex >
otherwise seems very complete
23:29
<
lopex >
headius: but jvm on linux is just a glibc compliant process right ?
23:30
<
headius >
lopex: well in theory, but that's a pretty big surface area
23:31
<
headius >
I remember seeing shipilev complaining about people trying to run Linux JDK on that Linux Bash environment
23:32
<
lopex >
well, not windows topic of course
23:32
<
lopex >
so many layers
23:33
<
lopex >
headius: so wrt that compliancy it's more a glibc fault or what ?
23:33
<
headius >
I don't know what issues he was running into
23:34
<
headius >
I can't guess what they were either :-) in theory if you have the right libs and kernel functions it should work
23:34
<
lopex >
headius: but sementic incomatibility for a single function concurency issue can ruin the whole thing wrt compat
23:34
<
lopex >
not just apis
23:35
<
lopex >
and how do they deal witth it
23:37
<
lopex >
I dont even know if cec applies to them
23:37
<
lopex >
and cec was always dead code for us
23:38
<
lopex >
and I vaguely understand the concept :P
23:49
<
headius >
ahh interesting
23:49
<
headius >
so there's some heuristic in there for analysing complexity and bailing out?
23:49
<
lopex >
he was here in the channel
23:49
<
lopex >
on that very issue
23:50
<
lopex >
but we havent been able to pin point the case
23:50
<
lopex >
we had a suspicious pattern though
23:51
<
lopex >
but for me it was more like a|a*|+ etc oniguruma supports
23:52
<
lopex >
but there;s nothin I'm aware for look/ahead/behind to make it happen
23:54
<
lopex >
headius: though there might be some bad look-* interactions
23:57
<
lopex >
I think we should check against engines taht support those perf wise
23:57
<
lopex >
headius: I'm clueless otherwise
23:57
<
lopex >
or just lazy :P