Timestamps are in GMT/BST.
[1:09] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 264 seconds)
[1:13] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[1:13] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[1:13] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[1:13] * ChanServ sets mode +o jimbaker
[3:04] <jimbaker> ok, we have the workaround in trunk for the obj publication bug
[3:04] <jimbaker> i actually think this spinning is not such a horrible hack
[3:04] <jimbaker> but ideally we would not need it. regardless, it lets us make progress!
[4:14] <stewori> please give note at least one day or so before trunk is locked for release phase
[4:14] <stewori> (I remember this inconvenient phase from 2.7.0 release)
[4:18] <jimbaker> stewori, yes, we will definitely will want to publicize!
[4:32] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Remote host closed the connection)
[4:33] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[4:37] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 250 seconds)
[4:45] * stewori (~stefan@5.146.129.76) Quit (Quit: Leaving.)
[5:27] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 250 seconds)
[5:31] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[5:31] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[5:31] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[5:31] * ChanServ sets mode +o jimbaker
[6:25] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[6:29] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 244 seconds)
[7:12] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 244 seconds)
[7:16] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[7:16] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[7:17] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[7:17] * ChanServ sets mode +o jimbaker
[7:26] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[7:30] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 244 seconds)
[8:06] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 265 seconds)
[8:10] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[8:10] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[8:10] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[8:10] * ChanServ sets mode +o jimbaker
[8:27] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[8:34] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 244 seconds)
[9:30] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[9:34] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 240 seconds)
[10:00] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 250 seconds)
[10:04] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[10:04] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[10:04] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[10:04] * ChanServ sets mode +o jimbaker
[10:31] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[10:35] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 250 seconds)
[10:55] * jimbaker (~jbaker@python/psf/jimbaker) Quit (Ping timeout: 240 seconds)
[10:59] * jimbaker (~jbaker@8.44.156.98) has joined #jython
[10:59] * jimbaker (~jbaker@8.44.156.98) Quit (Changing host)
[10:59] * jimbaker (~jbaker@python/psf/jimbaker) has joined #jython
[10:59] * ChanServ sets mode +o jimbaker
[11:31] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[11:36] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 250 seconds)
[12:32] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[12:37] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 250 seconds)
[13:33] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[13:37] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) Quit (Ping timeout: 244 seconds)
[14:10] * TomA (~TomA@2601:402:500:8e98:30a6:b673:7902:5bb3) has joined #jython
[14:11] <jimbaker> TomA, you may have noticed we have finally pushed in the socket/ssl changes that you and nickmbailey worked on
[14:12] <jimbaker> now that darjus fixed the problem that was causing us so many issues, whether it was a deadlock or the resulting obj publication bug
[14:12] * stewori (~stefan@5.146.129.76) has joined #jython
[14:13] <jimbaker> stewori, hi
[14:13] <jimbaker> you probably noticed the last set of changes
[14:14] <stewori> hey. Yes. Great news this stuff!
[14:15] * xemdetia (xemdetia@nat/ibm/x-tfhxaaxmmxdqkgfg) has joined #jython
[14:17] <stewori> Just tested JyNI with the new commits, and it works fine.
[14:18] <jimbaker> stewori, thanks for taking a look!
[14:19] <jimbaker> i will start taking a look at the bug triage again now that we have these fixes in, just to see where we stand for 2.7.1
[14:19] <jimbaker> RC
[14:19] <jimbaker> biab
[14:19] <stewori> Only one thing: I must complain a bit that nobody cared for the NEWS-file.
[14:21] <stewori> Cleaning it up after commits accumulated right before release will be actual work and difficult to track (I did this after 2.7.1 b3 release)
[14:23] <stewori> I just started to update it according to the latest commits, I thing #2487 #2462 #2508 got fixed and the netty-update. so you needn't bother with it this time.
[14:23] <stewori> *think
[14:25] <stewori> My main concern left for 2.7.1 release is platform.uname. I really wonder, whether it shall give JVM-info like it used to or repeat info from os.uname if available
[14:27] <stewori> Jeff pointed out that since platform is Java and is also reported like this by os and platform uname should be consistent with this and provide JVM-info
[14:27] <_MylesC> will the order fix make it into 2.7.1 for subclasses?
[14:29] <stewori> I would agree with him in terms of theory and philosophy, but I think in practice it will cause much less trouble with not-explicitly Jython aware modules if uname sticked to native platform info
[14:31] <stewori> As a comromise I'd suggest to let platform.uname provide JVM-info, because it used to until now, so changing this might break some code out there
[14:32] <stewori> but let os.uname provide native info, because of better compatibility with non-Jython-aware modules. Given that os.uname didn't exist at all before Jython 2.7.1 this shouldn't break Jython-aware code.
[14:47] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[15:49] * TomA (~TomA@2601:402:500:8e98:30a6:b673:7902:5bb3) Quit ()
[15:52] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Remote host closed the connection)
[15:53] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[15:57] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Ping timeout: 240 seconds)
[16:00] * TomA (~TomA@2601:402:500:8e98:a1fa:3a47:29a6:1c56) has joined #jython
[16:00] <jimbaker> _MylesC, can you try that fix out?
[16:02] <_MylesC> sure
[16:02] <jimbaker> ideally we could have a unit test added to verify ordering. and another one to get at the weakref behavior
[16:02] <jimbaker> but since LinkedHashSet is a Set, it's not strictly necessary - it's an interesting implementation detail
[16:04] <jimbaker> a unit test would ensure we don't scramble that behavior later. but... LinkedHashSet is not something we would ordinarily remove the ordering from, if for example we wanted to switch to a concurrent set
[16:19] <_MylesC> I don't suppose you could offer me a precompiled jar with the fix, I attempted the basic install steps on a ubuntu machine and ant complains "jython/build.xml:435: Java returned: 1"
[16:33] <agronholm> _MylesC: what's the full output?
[16:34] <_MylesC> agronholm: http://hastebin.com/usemefewek.tex
[16:34] <_MylesC> might of slightly slices it oops
[16:36] <agronholm> hm, wrong antlr version on classpath? just guessing
[16:36] <agronholm> line 95 seems to be the key
[16:37] <_MylesC> I mean, I just hg clone'd and ran ant
[16:37] <_MylesC> *shrug*
[16:39] <stewori> you are not using Java8 for building, are you?
[16:39] <agronholm> ohh right.
[16:39] <agronholm> I forgot that was an issue
[16:39] <_MylesC> does it not work with java 8?
[16:39] <agronholm> not atm
[16:39] <stewori> try building twice
[16:39] <_MylesC> that would be the issue
[16:39] <stewori> that usually goes through even with J8
[16:40] <agronholm> hm indeed
[16:40] <agronholm> it's been a while for me too
[16:43] <_MylesC> yeah it compiled the second time
[16:43] <_MylesC> :p
[16:44] <jimbaker> _MylesC, yes, it would be nice if the build worked on java 8
[16:44] <jimbaker> at least the second build trick does the job
[16:44] <jimbaker> we need to get our antlr upgraded
[16:48] <stewori> I still wonder if the second build trick has hidden issues
[16:49] <stewori> So far I didn't notice a drawback with the resulting jar
[16:49] <stewori> I don't know much about ant, never used it, but couln't there be a directive that applies one retry automatically?
[16:50] <stewori> Would be a - maybe easy - transitional solution until antlr upgrade
[16:53] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[16:57] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Ping timeout: 240 seconds)
[17:03] * stewori (~stefan@5.146.129.76) has left #jython
[17:08] <_MylesC> jimbaker: your fix worked perfectly
[17:11] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[17:51] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Remote host closed the connection)
[17:52] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[17:56] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Ping timeout: 276 seconds)
[18:01] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[19:36] <jimbaker> _MylesC, thanks for confirming that!
[19:36] <jimbaker> nickmbailey, do we have all of your patches in now?
[19:37] <nickmbailey> hmm yeah i think so
[19:37] <nickmbailey> i haven't had a chance yet but i was also going to comment on that netty upgrade ticket that we are still seeing an issue in high latency scenarios
[19:38] <nickmbailey> but i think it might be something else
[19:38] <nickmbailey> because that patch made things a lot better in general
[19:38] <jimbaker> nickmbailey, cool. i'm going to review 2.7.1 RC triage and see where we stand. i'm traveling to NYC next week for the openstack operators midcycle, so that's my first priority, but i think we are close
[19:39] <nickmbailey> cool
[19:39] <jimbaker> nickmbailey, possibly related to not properly supporting SO_LINGER
[19:40] <nickmbailey> hmm maybe? i haven't had time to investigate much yet
[19:40] <jimbaker> nickmbailey, i'm just throwing that out as something i know we have not done with respect to socket lifecycle
[19:41] <nickmbailey> yeah could be a good lead to investigate
[19:42] <jimbaker> we have the events from netty to support, just need to apply
[19:42] <jimbaker> just glad that 4.1 made the send stuff much easier
[20:33] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Remote host closed the connection)
[20:33] * nickmbailey (~nickmbail@aus.internal.datastax.com) has joined #jython
[20:38] * nickmbailey (~nickmbail@aus.internal.datastax.com) Quit (Ping timeout: 265 seconds)
[20:43] * nickmbailey (~nickmbail@cpe-70-117-83-204.austin.res.rr.com) has joined #jython
[21:53] * xemdetia (xemdetia@nat/ibm/x-tfhxaaxmmxdqkgfg) Quit (Ping timeout: 276 seconds)
[22:06] * stewori (~stefan@5.146.129.76) has joined #jython
[23:50] * AndyBotwin (~Gustavo@191.251.113.134) has joined #jython
[23:50] * AndyBotwin (~Gustavo@191.251.113.134) Quit (Changing host)
[23:50] * AndyBotwin (~Gustavo@unaffiliated/andybotwin) has joined #jython
[23:56] * stewori (~stefan@5.146.129.76) Quit (Quit: Leaving.)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).