<headius> dinnertime for me now too
<headius> bbl
xardion has quit [Ping timeout: 245 seconds]
xardion has joined #jruby
rdubya has quit [Ping timeout: 276 seconds]
sidx64 has joined #jruby
Puffball has quit [Quit: Puffball]
Specialist has joined #jruby
sidx64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
sidx64 has joined #jruby
sidx64 has quit [Client Quit]
sidx64 has joined #jruby
sidx64 has quit [Client Quit]
sidx64 has joined #jruby
sidx64_ has joined #jruby
sidx64_ has quit [Client Quit]
sidx64 has quit [Ping timeout: 268 seconds]
sidx64 has joined #jruby
bga57 has quit [Quit: Leaving.]
bga57 has joined #jruby
claudiuinberlin has joined #jruby
Specialist has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
jsvd_ has joined #jruby
jsvd_ is now known as jsvd
<GitHub150> [jruby] kares pushed 6 new commits to master: https://git.io/vhvo5
<GitHub150> jruby/master bbc8542 kares: [refactor] use method exception param + review keyword extraction
<GitHub150> jruby/master 2ab6bc3 kares: [refactor] dry-out exception: keyword extraction in socket classes
<GitHub150> jruby/master 838e22c kares: [spec] cleanup some of the regression specs -> no RUBY > '1.9' checks
jsvd has left #jruby [#jruby]
drbobbeaty has joined #jruby
shellac has joined #jruby
sidx64 has quit [Quit: Textual IRC Client: www.textualapp.com]
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<GitHub31> [jruby] kares pushed 2 new commits to master: https://git.io/vhvSR
<GitHub31> jruby/master 8c3a669 kares: replace if-else with switch + use call-sites on to_i/int conversion
<GitHub31> jruby/master c5f8834 kares: [refactor] avoid 19 suffixed methods as Kernel native impls
rdubya has joined #jruby
<travis-ci> jruby/jruby (master:8c3a669 by kares): The build was fixed. (https://travis-ci.org/jruby/jruby/builds/382071173)
<travis-ci> kares/jruby (master:8c3a669 by kares): The build was fixed. (https://travis-ci.org/kares/jruby/builds/382046838)
drbobbeaty has joined #jruby
shellac has quit [Ping timeout: 252 seconds]
ahorek has joined #jruby
ahorek has quit [Client Quit]
ahorek has joined #jruby
ahorek has quit [Client Quit]
jrafanie has joined #jruby
shellac has joined #jruby
<headius> bleh, yakyak refuses to connect
<headius> good morning all
<nirvdrum> Howy.
<nirvdrum> *Howdy.
<headius> enebo: I got a different one today
<headius> NoMethodError: super: no superclass method `simple' for #<ActiveRecordSchemaTest:0x599e4d41>
<enebo> yay
<headius> enebo: I have cut out more of that test but I'm still no closer to an answer
<headius> the private methods seem to have no impact, nor do the asserts
<enebo> yeah the private methods I realized were not important after I confirmed it was race-based
<enebo> but I could not remove both tests and ever have it fail
<enebo> have you seen that?
<enebo> also can you see my IM
<headius> no IM
<enebo> ok restarting pidgin since I see you writing to me in it
<headius> removing either test's main line of code and it seems to go
enebo has left #jruby [#jruby]
<headius> go away
<headius> I have both lines in a single test method with no asserts and still get it
enebo has joined #jruby
<headius> and only topics and companies fixtures
<enebo> yeah I removed all that too
denially has joined #jruby
<headius> frame class is null? o_O
<denially> hey
<headius> denially: hello there
<headius> ok no, not null...just cleared and I was looking too far down stack
<enebo> oh
<enebo> headius: ok pretty good lead
<enebo> could this be that we run a method n times and when it JITs we think we can eliminate a frame
<enebo> I have not been able to run these in interp period
<denially> i am new here
<headius> well ignore most of that
<denially> i am single age 24
<enebo> JITting would explain why we need two tests in that first one
<enebo> we need some threshold number of calls to something
<headius> denially: unless you are here to chat about JRuby you probably are in the wrong place
<enebo> denially: if you are single and have free time you can work on this project
<headius> enebo: try turning off parallel jit and see if it's more consistent
<denially> that is great
<enebo> headius: hey can you see my IMs now?
<headius> I tried threshold 0 but it didn't seem to help
<headius> yes
<denially> ok
<headius> enebo: this is strange
<headius> I'm catching stack overflow in UnresolvedSuperInstr so I can breakpoint there
<enebo> we loosened some framing...is there a way to completely remove it
<enebo> so we always frame
<headius> but when it breakpoints it not in the overflowing call anymore...it's in DatabaseStatements.exec_update
<enebo> I like that theory
denially has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
<headius> well ignore most of that...I'm not sure if there's a frame suspect yet
<enebo> no maybe not but we get klazz from frame
<headius> we don't completely clear the frame objects out so I was confused which one was top
<headius> we only clear what we don't want to retain
<headius> so I see a stack of translate_exception frames that used to be live but by the time I can catch this SOE they're already popped
<enebo> so my perspective right now is we need both those tests to get something racy
<enebo> I am weirded out why we need both present
<headius> running in debug seems to cause it all the time
<headius> perhaps giving some background thread time to mess up
<enebo> setting threshold 10k
<enebo> ran 5/5
<headius> oh I know why
<enebo> with threshold 10 I got more than 1E I got 8E
<GitHub183> [jruby] kares opened issue #5182: Java types should simply toString on inspect? https://git.io/vhfoR
<headius> I'm breakpointing in interpreter
<enebo> This is definitely from JITting
<enebo> I think we set in IRScope whether we can eliminate frame right? Do I need more tweaks?
<enebo> REQUIRES_CLASS,
<headius> there's no flag to turn off frame opto
<enebo> yeah I was just seeing if I could get JIT to not remove it with a simple state change
<enebo> unresolved super does set REQUIRES_CLASS
<headius> enebo: you can tweak it in AddCallProtocol
<headius> just remove the paths that are "only backref" and just fully frame every time
<enebo> I will do this and see what changes
<headius> I don't think that's the issue though...if klass is null and name isn't it raises an error
<headius> there's a guy here having a conversation on his phone with earbuds, but he's talking really quietly so all I hear is whispering
<enebo> I was just wondering if it is grabbing previous frame and it is not null but same klazz
<headius> it's like a mosquito buzzing
<enebo> or parent perhaps
<headius> ok I have debug at SOE
<enebo> so I ignore requireFrame and always push/pop method frame
<headius> frame klazz is our SQLite3
<enebo> oh so parent is the module
<enebo> errr next in line
<enebo> or is it?
<enebo> my experiment did not seem to work
<headius> it's re-finding SQLite3 module
<headius> so that's not too surprising
<headius> hmm
<headius> ick
<headius> there's some anonymous module it's finding as superclass
<headius> one method in it... valid_alter_table_type?
<enebo> yeah so anon is right about the module with the super in it
<enebo> deprecate :valid_alter_table_type?
<enebo> perhaps this will make a warn shim
<headius> that could be
<enebo> removed that line to see
<enebo> I wish I could trivially print out that ancestor
<enebo> 4/4 working with that removed
<headius> aha
<headius> something has been prepended into SQLite3
<headius> that anon module I believe
<enebo> deprecate impl will be a clue
akp has joined #jruby
akp has quit [Remote host closed the connection]
<headius> yeah poop
<headius> I think this is it
<headius> I don't know why it's not consistent though
<headius> so a theory
<enebo> target_module.prepend(mod)
<enebo> in method_wrappers.rb in AS
<headius> mmm used by that deprecate?
<enebo> defined module as block with methods as blocks then prepends it
<enebo> It would be a hoot if our "special" super logic somehow was responsible
<enebo> but it does not explain the non-100% aspect
<enebo> something with JIT as well
<headius> well I have a JRuby patch that makes it go away
<enebo> the special logic
<enebo> for finding proper module jumping off point
<enebo> we probably should have removed it a long time ago but I found it a testament to subbu and his ability to do the right thing
<headius> do you mean the find implementer thing?
<headius> that's what my branch tries to eliminate, but carrying implementer along with CacheEntry as in MRI
<headius> by
<enebo> no I meant super in closure we retain all closures and try and find proper stepping off point for which block is really the method boundary
* subbu pops up
claudiuinberlin has quit [Quit: Textual IRC Client: www.textualapp.com]
<enebo> this is not what MRI does. They basically I think error in some fashion
<headius> this isn't a super in closure
<subbu> oh, the darn super thing again .. :)
<subbu> is this a generic discussion or a bug-specific one?
<enebo> headius: yeah I guess that is correct but I notice a super in this deprecate method
<enebo> but this is not the method which is erroring so it is only about prepend
<enebo> subbu: sorry nothing you did
<headius> yeah I am trying to make a simpler repro based on theory
<subbu> ok .. i'll go back to preparing for this meeting then.
<enebo> I am going to do a full run now to see if removing that deprecate shows for full run
<enebo> subbu: good luck
<subbu> :)
<headius> my patch does seem to work but it's rearranging the deck chairs
<enebo> headius: so prepend, racy, and JIT threshold
<enebo> the racy bit I don't get
<enebo> unless a test runs something a variable number of times perhaps
<headius> did you turn off background jit?
<enebo> well I hadn't. I forgot to try it
<enebo> but that would be a +1 sort of issue
<headius> did disabling frame opto help?
<enebo> no did not seem to
<enebo> Assuming ACP is called it should have method framed everything
<headius> yeah threshold 0 is definitely busted :-\
<headius> that's not going to be fun
xardion has quit [Remote host closed the connection]
<enebo> 5031 runs, 14235 assertions, 9 failures, 6 errors, 8 skips
<headius> background off seems to consistently SOE
<enebo> so good news is with deprecate removed we mostly run these
<headius> huh
<headius> well I'm confused about this now
<headius> -X-C fails to boot the same way as threshold=0
<enebo> yes
<headius> -X-C threshold=-1 is no better
<enebo> so two issues I would think
<enebo> -X-C is running with that deprecate removed
<headius> that's really odd
<enebo> although I did not recompile since I ACP hacked
<enebo> I shoudl remove that
<headius> ok this isn't turning jit off
xardion has joined #jruby
<enebo> yeah -X-C will full build
<enebo> but full interp
<headius> I'm doing JRUBY_OPTS=-X-C and it's still jitting
<enebo> jit messages should be about full compiles not jit compiles
<enebo> unless we somehow hobbled full builds
<headius> yeah threshold -1 makes it stop logging
<enebo> makes sense to me
<headius> but it still doesn't boot
<enebo> maybe the message is not specific enough about what jitting means
<headius> so wtf
<enebo> ok I will stash and try again
<enebo> oh so close to finishing though
<headius> so strange
<headius> it's like I can't get any of them to start up
<headius> but if I let it jit it will start up
<enebo> stashed. Going to try again
<headius> something's unrelated to jit?
<enebo> -X-C will maybe run ACP too
<enebo> for full interp
<enebo> but why is it soooo soon
<enebo> these do appear to be similar errors
<enebo> timing is way off though
<headius> but I can't make it boot with any of them
<enebo> HAHAHA
<headius> -X-C with threshold=-1 or 0, normal jit with -1 or 0
<enebo> remove deprecate from adapter.rb in sqlite3
<enebo> It runs
<enebo> with -X-C
<headius> so it calls deprecate which prepends and then every super gets scrrewed up
<headius> but why does startup interp not work
<enebo> yeah but why earlier with full or even --dev
<headius> why does none of them work
<enebo> since startup appears to be working
<enebo> I mean in mixed it must
<enebo> -X-C thres=-1 is working for me too now
<headius> try -X-C with threshold -1
<headius> ok
<enebo> but but but
<headius> I do not understand
<enebo> yeah -1+interp should be JIT before the JIT so why would it fail
<enebo> It is a different method type as a Java class
<headius> what about threshold 0
<headius> does that work ok too?
<enebo> I will try
<headius> they all use the same logic for unresolved super
<headius> I'm confirming that though
rdubya1 has joined #jruby
<enebo> headius: seems to be working ok
rdubya has quit [Ping timeout: 245 seconds]
<headius> module M; end; module Foo; prepend M; def foo; super; end; end; class A; def foo; p :A; end; end; class B < A; include Foo; end; B.new.foo
<headius> I don't have an answer for why jit mode matters though
<enebo> what I don't get is why -1 interp does not work
<enebo> when it does in mixed
<headius> yeah
<headius> my jruby patch appears to introduce some other issues
<headius> maybe I just need to finish that branch
<enebo> oh one difference
<enebo> call in mixed does getMethodLocation on impl class but not in startup interp
<enebo> Err interpretedIRMethod
<headius> that could do it
<headius> yeah that would explain it I think
<enebo> I will see
<headius> if mixed mode it will go through getMethodLocation path either way
<headius> if specifically -X-C it will go through other
<headius> regardless of threshold
<headius> and then the jit probably doesn't do method location again
<GitHub2> [jruby] headius pushed 1 new commit to super_fixes: https://git.io/vhfST
<GitHub2> jruby/super_fixes 106dc09 Charles Oliver Nutter: Merge branch 'master' into super_fixes
<headius> so the patches on my branch basically move the impl finding to method lookup time and then carry it along
<enebo> headius: yeah so this is one mystery explained
<headius> that helps
<enebo> I can run full tests with that change
<enebo> I will commit
<headius> I had a branch where I unified all those methods and I never finished it :-(
<headius> interp, full build, jit, and mixed
<enebo> yeah so moving back to this though
<headius> that would have avoided this particular issue
<enebo> JIT perhaps needs new location or something?
<enebo> I don't know why it would change
<enebo> it should be same type
<enebo> now that we eliminated startup as an issue
<headius> well at this point I'm not sure how to fix without super branch
<enebo> -X-C fails same or no? I don't remember
<enebo> I am still not entirely sure what is wrong
<enebo> I mean why does it stop on JIT
<enebo> stop working
<headius> where do you see mixed doing getMethodLocation?
<headius> or vice versa, I didn't see it in interp
<enebo> oh well I only see it for interp
<enebo> all INTERPRET_METHOD calls seem to do it
<enebo> jit'd method call does not do it but it is unclear since we pass in different # of params
<headius> I don't see that at all
<headius> am I going insane
<enebo> return INTERPRET_METHOD(context, ensureInstrsReady(), getImplementationClass().getMethodLocation(), self, name, arg0, block);
<enebo> MixedModeIRMethod?
<headius> ok I think I removed those calls on this branch
<enebo> headius: ah well they definitely make interp work
<enebo> jit passes clazz through but that is calling class not impl class right?
shellac has quit [Ping timeout: 260 seconds]
<enebo> ok this is weird
<enebo> oh no it isn't
<enebo> yeah so -X-C and -1 all go through interpreted method and -X-C with a threshold is now working with the method location changes
<enebo> JIT in mixed mode does not do method location to the jit'd method
<enebo> but does to startup
<enebo> startup works
<headius> ok well that's promising for 9.2
<enebo> should we maybe just pass method location to jit'd method assuming clazz is for impl method
<enebo> I will try it I guess
<headius> try it
<enebo> yeah recompiling
<headius> it should be the same across all of them
<headius> jit doesn't do anything different than full here
<enebo> yeah if this works we shall see if any red appears elsewhere
<enebo> running full suite
<enebo> not to trouble spot yet
<enebo> just look at that optimism
<enebo> we should try AS after this too
<headius> superclass on the included class from a prepended module seems borked
<headius> the included module wrapper's superclass is the prepend
<headius> and then null
<enebo> uh oh...I see the EEEEEEEEEs
<enebo> aborting and going back to simpler run
<enebo> yeah still broken
<headius> I'm trying to figure out the proper implementer for this hierarchy
<headius> the MRI code for this stuff is so hard to follow
<enebo> headius: so I pushed that interpretedirmethod change
<GitHub87> [jruby] enebo pushed 1 new commit to master: https://git.io/vhfHb
<GitHub87> jruby/master 7ce8544 Thomas E. Enebo: Matching up interpreted method with mixed mode method that interpreter should...
<enebo> headius: you should verify things are working for you with -X-C, -X-C+-1
<enebo> headius: seemingly just mixed mode is broken upon JITting
<enebo> fact that full interp is working is interesting since all three modes call the same helper
<enebo> but I guess full no longer runs lots of passes like ACP
<headius> full should be running acp too
<enebo> It is not in its default list
<enebo> unless it is hardcoded elsewhere
<headius> what default list?
<enebo> IRManager has lists of passes
<headius> yeah I know that
<headius> so it's not running local optimization, dead code, none of that?
<enebo> ok well full build is running an empty list
<headius> I thought we'd turned on all that stuff so full and jit would be consistent
<enebo> well that was the goal
<enebo> I don't know why it is not like that
<headius> bleh
<enebo> adding jit.passes explicitly
<enebo> see if it breaks
<headius> I'm confused
<headius> so full interp never has protocol now
<enebo> it appears not
<enebo> I don't know why but it has been this way a long time now
<enebo> If I pass in those passes manually via ir.passes I am not seeing the problem though
<headius> aha
<headius> // Always add call protocol instructions now since we are removing support for implicit stuff in interp.
<headius> if (!isUnsafeScope()) new AddCallProtocolInstructions().run(this);
<enebo> ah yeah hardcoded then
<headius> full explicitly runs protocol
<headius> just not the other jit passes
<headius> whew I'm glad I wasn't crazy
<enebo> "
<enebo> enebo: unless it is hardcoded elsewhere"
<enebo> this is a data point at least
<enebo> full interp runs with ACP
<enebo> I can see mixed does pass in a different value to the jitted method clazz vs method_location
<enebo> but changing that did not fix it
<headius> you are testing with my snippit or test run?
<enebo> full test
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<enebo> not that prepend stuff above
<enebo> I will try it
<enebo> headius: your snippets runs all but compiled
<enebo> -e will use CompiledIRMethod though and not mixed
<headius> -e dispatches directly into the compiled script
<headius> oh but method defs will be compiled
<headius> yes
<enebo> oh ho ho ho
<enebo> I changed CompiledMethod from implementationClass to add getMethodlocation and your snippet passes
<enebo> it is still begs why that did not work for MixedModeIRMethod
<headius> hmm
<headius> yeah
<enebo> maybe I missed something
shellac has joined #jruby
<headius> I'm looking at my branch
<headius> need to grab lunch shortly
<enebo> yeah I will eat soon too
Puffball has joined #jruby
<GitHub54> [jruby] headius pushed 1 new commit to super_fixes: https://git.io/vhfd6
<GitHub54> jruby/super_fixes 4992a5a Charles Oliver Nutter: Pass host through to super calls properly.
<enebo> ok so it does appear to fix us
<GitHub45> [jruby] enebo pushed 1 new commit to master: https://git.io/vhfF3
<GitHub45> jruby/master 3cb5f89 Thomas E. Enebo: Whoo? Seemingly, retrying something tried a few minutes before seems to work...
<enebo> headius: going to lunch but pull and see if you see any problems anywhere
<enebo> I don't get it. Unless somehow CompiledMethod was also part of why it did not work before
subbu is now known as subbu|away
jrafanie has joined #jruby
<GitHub128> [jruby] kares opened pull request #5183: [ji] support Java time APIs with Time/Date/DateTime (master...date-time_to-java) https://git.io/vhJfK
<headius> enebo: what don't you get
<headius> this feels like dej vu all over again
<headius> deja
<headius> love this keyboard
<headius> now I'm trying to determine if I should be doing getMethodLoc on the super branch for all host classes
<headius> the whole structure of prepend throws me off
<headius> of course all super specs pass
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
<enebo> headius: I don't get that I made the change a second time and it worked the second time. unless compiledmethod (which I did not change first time) somehow affected things.
shellac has quit [Client Quit]
<headius> hmm ok
<headius> enebo: in any case the super fixes won't be in 9.2
<headius> if that looks good we should add a spec for that case
rdubya1 has quit [Quit: Leaving.]
rdubya has joined #jruby
<enebo> headius: yeah I guess so. Unless we have something excluded
<headius> ok some things starting to come back into focus
<headius> method location is needed to know that the methods from the original class need to super from the prepend level
<headius> it's not used while walking the module tree as far as I can tell
<headius> and any attempts I made to use it seemed to go off on the wrong branches
<headius> gonna have to poke around a bit more...seems like we have the right structure but this handling of super and prepend is still not quite right
<GitHub58> [jruby] aryeh-looker opened issue #5184: `true.dup` and `false.dup` blow up (Inconsistent with MRI) https://git.io/vhJ4v
<headius> kares: soft code freeze ok? I think we're going to go for it
<headius> unless something is critical path, push to a branch until after 9.2
<enebo> kares: please find problems if you can
<enebo> kares: confidence level is not massive today but we do not really have many big known issues atm either
subbu|away is now known as subbu
drbobbeaty has quit [Ping timeout: 260 seconds]
<headius> enebo: how long do AS tests take for you btw
<enebo> headius: well they hung so forever
<headius> I'm up to these slow-running hiredis things with maybe 20 Fs
<enebo> I made it past a series of redis failures
<enebo> it just stopped
<enebo> finalization thing by looks of it
<enebo> no doubt a bad threading test
<headius> I don't see a ton of failures, just a lot of warnings
<enebo> yeah with those redis just a few
<enebo> other than not finishing
<enebo> which could be many after that point
<headius> I don't remember these running this slow
<headius> perhaps they moved a lot more out to "isolated" test runs
havenwood has quit [Quit: ZNC 1.6.6 - http://znc.in]
havenwood has joined #jruby
havenwood has joined #jruby
jrafanie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jrafanie has joined #jruby
jrafanie has quit [Client Quit]
jrafanie has joined #jruby
<GitHub93> [jruby] enebo closed pull request #5178: WIP: resolv ffi prototype (master...resolv_ffi) https://git.io/vphvp
<GitHub150> [jruby] enebo pushed 2 new commits to master: https://git.io/vhJ6w
<GitHub150> jruby/master 1e26677 Thomas E Enebo: Merge pull request #5178 from ahorek/resolv_ffi...
<GitHub150> jruby/master 105a417 pavel: resolv ffi
jrafanie has quit [Client Quit]
<enebo> well he says WIP but it worked for me...
shellac has joined #jruby
ahorek has joined #jruby
<ahorek> @enebo, are you here? :)
<enebo> ahorek: hehe
drbobbeaty has joined #jruby
<enebo> ahorek: interesting I applied the patch and it seemed to make bundler happy
<enebo> ahorek: so it is giving some result back perhaps but not a valid one
<ahorek> require 'resolv'
<ahorek> Win32::Resolv.send(:get_dns_server_list)
<enebo> ahorek: ah yeah I can see it giving me the error bacjk
<enebo> ahorek: amazingly maybe bundler accepts this exception and moves on.
<enebo> ahorek: I will look at this quickly to see if I can figure it out
<enebo> ahorek: you have any particular thing which confused you when you got to this point?
<ahorek> https://github.com/jruby/jruby/pull/5178/files#diff-f65e2fc567d87e2331ef404a20e95668R38 at this line, there should be something like malloc
<ahorek> on failure it should raise Win32::Resolv::Error not runtime error
<ahorek> and some of the datatypes like IP_ADDR_STRING -> Next should be pointers
<enebo> ahorek: I see first if does not continue on success
<enebo> it fails if not buffer_overflow
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<enebo> ahorek: ok I see thing you could not figure out...I will see how to make n element out buffer
Antiarc has quit [Quit: ZNC 1.6.6+deb1 - http://znc.in]
Antiarc has joined #jruby
shellac has quit [Ping timeout: 245 seconds]
ahorek has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]