subbu has joined #jruby
subbu has quit [Ping timeout: 255 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 260 seconds]
razetime has joined #jruby
kares[m] has quit [Quit: You have been kicked for being idle]
razetime has quit [Ping timeout: 268 seconds]
razetime has joined #jruby
razetime has quit [Remote host closed the connection]
subbu has joined #jruby
<headius> good morning
<byteit101[m]> Hmm....
<byteit101[m]> 2.6.2 :003 > def zfoo; 0; end; 9.zfoo
<byteit101[m]> => 0
<byteit101[m]> jruby- :024 > def zfoo; 0; end; 9.zfoo
<byteit101[m]> NoMethodError (private method `zfoo' called for 9:Integer)
<byteit101[m]> I'm not sure what to think of this
<byteit101[m]> Both options seem somehow wrong
<byteit101[m]> 3.0 does the same as jruby
<headius> Interesting that 3.0 matches
<headius> I think this is due to how default visibility is handled in IRB
<enebo[m]> jruby -e 'def zfoo; 0; end; 9.zfoo'
<enebo[m]> <main> at -e:1
<enebo[m]> NoMethodError: private method `zfoo' called for 9:Integer
<enebo[m]> but I can confirm 2.6.2 only works due to irb
<enebo[m]> as it gives the same error with -e
<headius> Right I may have filed an issue about that
<enebo[m]> headius: I have some comments above (3pm yesterday) on timeout 0.3.0 and our embedded test
<enebo[m]> It would appear 0.2.0 of timeout would join on the thread made for the timeout and 0.3.0 does not do that which makes the behavior dependent on the timeout thread going away on its own
<enebo[m]> I do not find this to be a problem personally but it makes the testTimeoutCleanup mostly fail (and sometimes work)
<headius> Oh I missed your messages
<headius> Ah that makes sense
<enebo[m]> yeah no problem. I did not tag you
<enebo[m]> It is the only reason -Ptest fails
<enebo[m]> So should we remove the test or advocate for explicit #join added back into timeout?
<headius> Hmmm
<enebo[m]> as it stands timeout clean is non-deterministic now
<headius> I'll have a look
<enebo[m]> ok
<enebo[m]> I am guessing MRI kills that thread right away and when they rearranged code it meant saving raise state since I think the join causes something else to raise
<enebo[m]> "MRI kills" == just happens to work that way due to non-native threading
<headius> I am not sure how this would sometimes pass
<headius> there does not seem to be a way to clean up the timeout thread... it just runs forever
<headius> the new timeout is implemented similarly, with a single timeout thread that handles all requests, but there's no way to shut it down
<headius> hmmm
<headius> we do have code to shut down Ruby threads but we don't do it for adopted threads, which I think applies in this case
<headius> enebo: I think we should file an issue with timeout about there being no way to cleanly terminate it
<headius> I'm looking into making such a mechanism now
<headius> registering a thread killer as a shutdown item might be enough
<byteit101[m]> but dynamic methods in 3.0 and jruby are public
<byteit101[m]> define_method(:afoo) { 6 }; 9.afoo
<byteit101[m]> => 6
<byteit101[m]> Oops, though I sent that earlier
<headius> oh no I'm wrong... this is a normal Ruby thread so it won't be seen as an adopted thread, like the old executor version was
<headius> so it is probably due to the kill of the threads not completely finalizing their termination during shutdown
<headius> but we can also make it more robust by having the timeout library register something to kill the timeout thread directly
<headius> I have a snippit of code that adds an at_exit thread killer and it is passing so far
<headius> it's not much more than we were already doing but it is done earlier in the shutdown sequence to the thread has more time to clean up before we test for it
<headius> there's also been some minor tweaks to timeout that could use a release
<enebo[m]> cool. That looks reasonable to me and it should have no affect on MRI from a performance standpoint
<enebo[m]> well not one that could matter
<headius> yeah might get some pushback since we are supposed to shut down threads at termination, but I think it is just too close to the test
<headius> we do kill+join but the native thread may take a bit more time to no longer show up in JDK lists
<enebo[m]> We may never shut down too
<enebo[m]> Not in this case but we just had that backedge fix
<enebo[m]> There are cases where we cannot know we can kill something
<enebo[m]> like possibly a Ruby thread which is calling into a Java method which never comes back
<headius> yeah true
<headius> we do no more than try a Ruby kill, which won't interrupt everything
<enebo[m]> Maybe that is too generic but it just is saying we have less control over a threads lifetime than C Ruby.
<enebo[m]> Another random thought on this whole gemification is that we perhaps need more ability to inject specific impl behavior when not all impls need the same thing
<enebo[m]> we can RUBY_ENGINE protect this of course
<enebo[m]> but maybe there is a nicer way
<headius> inject atop the installed gem or within it?
<enebo[m]> something. I am not sure.
<headius> there are other gemified libraries that ship special code for JRuby already, like digest
<enebo[m]> maybe RUBY_ENGINE is the way
<headius> or io/wait which is FFI-based for us but an ext for others
<enebo[m]> if they do not like this for MRI we can at least add it for only us and then it will be committed there
<enebo[m]> It is just too bad there is not an impl hook all gems could use which would allow impl-specific additions or an additional require or something
<headius> enebo: do you have a repro for that null block thing you changed?
<headius> hey we could just stub out all the gems and ship whatever we want
<enebo[m]> heheh
<enebo[m]> headius: just revert and run this
<enebo[m]> It would appear indy is seeing NullBlock as an actual usable block.
<enebo[m]> but it is just some method handle snafu
<headius> got it
<headius> 0: %v_3 := call_1ob(%v_5, fix<1>, noblock<>, callType: NORMAL, name: v=, potentiallyRefined: false, flags: 0)
<headius> the v= call seems to be getting compiled as a call with a block
<headius> call_1ob
<enebo[m]> hmm
<enebo[m]> I see
<headius> aha
<enebo[m]> Interesting it works in all other modes but that should not happen
<headius> boolean hasClosure = closure != null;
<headius> CallInstr.create uses
<enebo[m]> yeah
<enebo[m]> I think this should be fixed in IR
<headius> yeah I am also wondering about the handle error though tooo
<enebo[m]> although there is no guarantee this won't happen in the future
<enebo[m]> not everything is made with .create
<headius> ah I think it is a mismatch in how each determines if a closure is being passed
<enebo[m]> and not all callbase is a call
<enebo[m]> attrasgn and whatnot
<enebo[m]> but it should still be fixed here
<headius> yeah it should
<enebo[m]> I can do it if you are not doing it
<headius> I think I see why it fails in indy
<headius> it detects that this is an attr assignment and omits block, but then a block is in the signature because of the way it was set up
<headius> so the target attr assignment doesn't want the block that's in the MH chain and it blows up
<headius> it would be a bug if attr assignment could take a block, but it can't so this should be a safe assumption
<headius> it is perhaps not guarded well enough though... it could deopt to a normal call if it is an attr assignment but a block is given
<headius> dunno if that is worth the work
<headius> I will fix the IR and test that reverting your change still works
<enebo[m]> ok. yeah I don't have a feel on this past it could happen in the future somehow
<headius> boolean hasClosure = closure != null && !(closure instanceof NullBlock);
<headius> sufficient?
<enebo[m]> I think may want to search for closure != null in ir package
<enebo[m]> I could see it somehow happening in super for unknown reasons
<enebo[m]> It would not surprise me if we do it in a compiler pass either
<headius> there are a few other places
<headius> may be more with other names for the closure var
<headius> feels gross to do this null check though
<enebo[m]> can you make a static on CallBase which has this logic?
<enebo[m]> It unfortunately is not always on a field but it would then hide that null check
<enebo[m]> we could also audit all possible constructions and make sure it is never null :)
<enebo[m]> but those can happen at different times too
<headius> Yeah
<headius> I will try to audit better
subbu has quit [Quit: Leaving]