Timestamps are in GMT/BST.
[10:09] * JythonLogBot disconnected - trying to reconnect...
[10:09] -sinisalo.freenode.net- *** Looking up your hostname...
[10:09] -sinisalo.freenode.net- *** Checking Ident
[10:09] -sinisalo.freenode.net- *** No Ident response
[10:09] -sinisalo.freenode.net- *** Couldn't look up your hostname
[16:28] -morgan.freenode.net- *** Looking up your hostname...
[16:28] -morgan.freenode.net- *** Checking Ident
[16:28] -morgan.freenode.net- *** No Ident response
[16:28] -morgan.freenode.net- *** Couldn't look up your hostname
[16:28] * JythonLogBot (~PircBot@188.8.131.52) has joined #jython
[16:28] * Topic is 'Try Jython 2.7b3 at http://tinyurl.com/p2kmxod | This channel is logged: http://jython.extreme.st/irclogs/ | Please update the wiki: http://wiki.python.org/jython | Jython Book: http://jythonbook.com | Podcast: http://jython.org/jythonpodcast/'
[16:28] * Set by agronholm!~agronholm@2001:1bc8:102:6f29:ed9d:3487:3941:d41a on Fri Aug 22 22:40:30 UTC 2014
[16:48] * fwierzbicki (~Adium@99-106-169-5.lightspeed.sntcca.sbcglobal.net) has joined #jython
[20:50] <peke> jimbaker: With coupler thread being fine, do you mean that the current raise is fine or changing it to return would be fine?
[20:59] <jimbaker> peke, i mean, i don't see a bug there - it's fine as is
[20:59] <jimbaker> it's just telling us something that's not terribly interesting during jvm shutdown
[21:24] <peke> jimbaker: Sorry, I don't get it. In the problem I faced there's no JVM shutdown.
[21:25] <jimbaker> peke, ok, please explain the scenario again, apparently i didn't get what's going on in your case
[21:26] <peke> Basically I got this printed to console when I call my new Popen.kill:
[21:26] <peke> Exception in thread "_CouplerThread-4 (stdout)" Traceback (most recent call last):
[21:26] <peke> File "subproc/subprocess.py", line 749, in run
[21:26] <peke> count = self.read_func(buf)
[21:26] <peke> IOError: Stream closed
[21:28] <peke> It doesn't happen with just a simple Popen(['sleep', '10']).kill() but I can pretty reliably reproduce it (4/5 times) by running Robot's acceptance tests for Process library (IOError: Stream closed
[21:29] <peke> oops, wanted to paste this link to Process library docs: http://robotframework.org/robotframework/latest/libraries/Process.html
[21:29] <peke> I can, and plan to, investigate under what circumstances that error occurs. But I already tested that changing this raise to return avoids it:
[21:29] <peke> https://github.com/jythontools/jython/blob/master/Lib/subprocess.py#L767
[21:33] <peke> I got that error regardless do I use Java 8 (my new Popen.kill uses Process.destrouForcibly in that case) or Java 7 (os.kill(self.pid, signal.SIGKILL))
[21:36] <jimbaker> peke, i see, it sounds like an additional exception that we should suppress
[21:37] <pjenvey> it might be harmless to eat the exception but I'd be on the cautious side, I believe you can pass in a user supplied file that can end up being used in a coupler thread
[21:37] <jimbaker> unless we can come up with some sort of recovery. but i don't see where it makes sense - the stream is closed, the coupler thread is there to read the stream and provide async support. that it is dead is not terribly interesting
[21:37] <pjenvey> so maybe anything odd could happen that you'd want to show to the user
[21:37] <pjenvey> you could set a flag on the coupler threads notifying a kill was sent and only hidei t then
[21:38] <pjenvey> i'd consider that anyway
[21:38] <jimbaker> pjenvey, ack - sage advice from the author of this functionality ;)
[21:38] <pjenvey> =]
[21:40] <jimbaker> https://www.youtube.com/watch?v=Jdf5EXo6I68 seems relevant
[21:46] <peke> jimbaker: pjenvey: I agree that errors should never pass silently.
[21:46] <peke> Unless explicitly silenced, that is. =)
[21:46] <jimbaker> peke, exactly, sometimes we must appropriately silence them. per the monty python clip!
[21:47] * ebarrett (~email@example.com) Quit (Ping timeout: 245 seconds)
[21:47] <jimbaker> "regulations and all"
[21:48] * ebarrett (~firstname.lastname@example.org) has joined #jython
[21:59] * Paladiamors (~email@example.com) has joined #jython
[22:38] * Paladiamors (~firstname.lastname@example.org) Quit (Ping timeout: 252 seconds)
[23:00] * r0bby_ (~email@example.com) has joined #jython
[23:00] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 240 seconds)
[23:01] * r0bby_ (~firstname.lastname@example.org) Quit (Changing host)
[23:01] * r0bby_ (~wakawaka@guifications/user/r0bby) has joined #jython
[23:19] * enebo (~email@example.com) Quit (Quit: enebo)
[23:46] <peke> jimbaker: pjenvey: I finally figured out why the weird erroc actually occurs. Turned out I don't need to use new Popen.kill at all. It's enough to use Popen.terminate with a program that ignores SIGTERM.
[23:47] <peke> Seems to be related to this issue I submitted earlier: http://bugs.jython.org/issue2218
[23:52] <peke> Except that this error I got only when using a file as stdout. That other error I got when stdout was PIPE.
These logs were automatically created by JythonLogBot on irc.freenode.net using a slightly modified version of the Java IRC LogBot.