Timestamps are in GMT/BST.
[5:53] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) Quit (Quit: Leaving)
[8:49] * pjenvey (~pjenvey@underboss.org) Quit (Quit: ZNC - http://znc.sourceforge.net)
[8:49] * pjenvey (~pjenvey@underboss.org) has joined #jython
[8:51] * chrisseaton (sid38584@gateway/web/irccloud.com/x-mztyziiayzcsxqdv) Quit (Ping timeout: 276 seconds)
[8:52] * chrisseaton (sid38584@gateway/web/irccloud.com/x-khicwclbgynxxfdv) has joined #jython
[8:53] * jorgew (sid36089@gateway/web/irccloud.com/x-geueyqthwwqcxozc) Quit (Ping timeout: 276 seconds)
[8:54] * jorgew (sid36089@gateway/web/irccloud.com/x-btfqmeuinrmskrdt) has joined #jython
[12:38] <agronholm> there is now another project under the jython umbrella: https://github.com/jython/swingutils
[12:38] <agronholm> all tests pass on jython 2.7
[13:40] * xemdetia (xemdetia@nat/ibm/x-jvqtrgafqbaacawr) has joined #jython
[15:06] * xemdetia (xemdetia@nat/ibm/x-jvqtrgafqbaacawr) Quit (Ping timeout: 252 seconds)
[15:14] * xemdetia (xemdetia@nat/ibm/x-mnjmfpothqaihfeh) has joined #jython
[15:19] * xemdetia (xemdetia@nat/ibm/x-mnjmfpothqaihfeh) Quit (Ping timeout: 255 seconds)
[15:21] * xemdetia (xemdetia@nat/ibm/x-acisnwyvnssejbnp) has joined #jython
[15:42] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[15:42] * ChanServ sets mode +o Arfrever
[15:43] * sense-non (~non@24-212-218-144.cable.teksavvy.com) has joined #jython
[16:03] * xemdetia (xemdetia@nat/ibm/x-acisnwyvnssejbnp) Quit (Quit: Leaving)
[16:11] * koo6 (~koo5@236.152.broadband3.iol.cz) has joined #jython
[16:23] * gopar (~gopar@c-73-162-171-146.hsd1.ca.comcast.net) has joined #jython
[17:09] * fwierzbicki (~Adium@99-106-169-5.lightspeed.sntcca.sbcglobal.net) has joined #jython
[17:13] * sense-non (~non@24-212-218-144.cable.teksavvy.com) has left #jython
[17:22] * xemdetia (xemdetia@nat/ibm/x-gzqnmcoosltmzgzp) has joined #jython
[18:06] * xemdetia (xemdetia@nat/ibm/x-gzqnmcoosltmzgzp) Quit (Quit: Leaving)
[21:58] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 276 seconds)
[22:46] <jimbaker> agronholm, awesome!
[22:48] <jimbaker> slides i will be presenting tomorrow in the openstack panel on alternative languages (such as go) and implementations (such as jython): https://github.com/jimbaker/talks/blob/master/jython-java-openstack.md - the panel is https://openstacksummitmay2015vancouver.sched.org/event/fec286e14d4a1adb5f38a62f59196112
[22:48] <jimbaker> (i'm in vancouver, somewhat sick with a cold, but hopefully fine enough for tomorrow's panel)
[22:49] <jimbaker> would love for any feedback on my slides
[23:06] <pjenvey> jimbaker - re the panel, I guess some of the rackspacers just tried rewriting parts of openstack swift in go
[23:06] <jimbaker> pjenvey, yeah, this is the hummingbird project
[23:06] <pjenvey> i'd always thought there might be an opportunity for pypy in openstack somewhere to help w/ perf issues
[23:06] <pjenvey> unfortunately there seems to be not too much interest
[23:08] <jimbaker> pjenvey, i think alex gaynor was working on this, but they ran into other issues. this specific chunk of openstack - the swift objectstore which just manages mapping CRUD ops to disk - is particularly suited to what golang supports out of the box
[23:10] <jimbaker> one interesting question is what else is a good target for golang. my personal feeling is that microservices like the object store or stuff like etcd are very good candidates. other stuff, especially integration code, less so
[23:15] <pjenvey> http://lists.openstack.org/pipermail/openstack-dev/2015-May/063619.html
[23:15] * pjenvey wonders if they ran into lack of interest
[23:16] <pjenvey> I don't know enough about swift workloads or how they're using, I assume they're parallelizing more work over multicore
[23:34] <jimbaker> pjenvey, yeah, i think the key issue is that pypy's GIL meant that multicore didn't help, and so they were still working around with multiprocessing
[23:44] <jimbaker> pjenvey, here's a question you might know the answer to - did pypy see a lot of problem in c extension api support because of memory related issues; or is just because of being able to do better inlining?
[23:49] <pjenvey> I know the cpyext uncovered some extensions mismanaging memory that it got away with on cpython
[23:53] <jimbaker> yeah, i'm sure those do exist! it's just too easy to get ref counting wrong :)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).