Timestamps are in GMT/BST.
[0:15] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 245 seconds)
[0:29] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[0:35] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 264 seconds)
[1:06] * jimbaker_ (~jbaker@c-75-71-81-32.hsd1.co.comcast.net) has joined #jython
[1:10] * jimbaker_ (~jbaker@c-75-71-81-32.hsd1.co.comcast.net) Quit (Client Quit)
[1:50] * paolo (~Paolo@net-37-117-0-21.cust.dsl.vodafone.it) Quit (Ping timeout: 246 seconds)
[1:55] * whg is now known as zz_whg
[3:49] * [Arfrever] (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 246 seconds)
[5:16] * [Arfrever] (~Arfrever@apache/committer/Arfrever) has joined #jython
[6:59] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[7:46] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[8:29] * [Arfreve1] (~Arfrever@minotaur.apache.org) has joined #jython
[8:31] * xymox (lechuck@unaffiliated/contempt) Quit (Disconnected by services)
[8:32] * xymox (lechuck@unaffiliated/contempt) has joined #jython
[8:35] * JStoker_ (jstoker@unaffiliated/jstoker) has joined #jython
[8:35] * sinsnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) has joined #jython
[8:36] * [Arfrever] (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 260 seconds)
[8:36] * JStoker (jstoker@unaffiliated/jstoker) Quit (Ping timeout: 260 seconds)
[8:36] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 260 seconds)
[8:36] * sinsnare|away (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) Quit (Ping timeout: 260 seconds)
[8:37] * JStoker_ is now known as JStoker
[11:51] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[12:17] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 250 seconds)
[12:29] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[12:36] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[12:36] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Client Quit)
[12:55] * scavenger (c2ce95e6@gateway/web/freenode/ip.194.206.149.230) has joined #jython
[12:55] <scavenger> hello juser :)
[12:56] <scavenger> anybody available to help me implement readline with jython 2.5.3 for ibm AIX ?
[13:05] <scavenger> hello ?
[13:35] <scavenger> i'll stay here for 2 more hours
[13:59] <scavenger> is it possible to have a bash like command completion/call back with jython shell ?
[13:59] <scavenger> with arrow keys
[14:10] * zz_whg is now known as whg
[14:15] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) Quit (Quit: oscar_toro)
[14:25] <scavenger> hello !!
[14:25] <scavenger> anybody ?
[14:48] <jimbaker> scavenger, we use jline in jython 2.5.3, which emulates the usual gnu readline
[14:50] <jimbaker> re arrow keys and tab completion, this should work w/ rlcomplete
[14:50] <jimbaker> i blogged about this a while ago, http://zyasoft.com/pythoneering/2010/09/jython-2.5.2-beta-2-is-released/
[14:52] <jimbaker> the ipython work was never completed, sadly. i found myself doing other things back then. but there's been some recent work on ipython for 2.7
[14:52] <jimbaker> (this is because ipython dev moved to requiring a min of 2.6 roughly around this time)
[14:53] <scavenger> oh
[14:53] <jimbaker> anyway, i just verified the steps of import readline; import rlcompleter; readline.parse_and_bind("tab: complete") work just fine for our jython 2.7 trunk, and i cannot imagine that's not the case for 2.5
[14:53] <jimbaker> unless aix is not compatible w/ jline
[14:54] <scavenger> i get an error importing readline with jython 2.5.3 and 2.5.2
[14:54] <scavenger> raise ImportError("Cannot access JLineConsole")
[14:55] <scavenger> the error stands on line 20 of Lib/readline.py : _reader = sys._jy_interpreter.reader
[14:56] <scavenger> AttributeError: '<reflected field public org.python.core.PyObject o' object has no attribute '_jy_interpreter'
[14:56] <jimbaker> scavenger, sounds like jython could not use jline on your system
[14:57] <jimbaker> the first thing is to figure out if jline 1 (we are in the process of moving to jline 2 for jython 2.7) works on aix
[14:57] <scavenger> wow: that would be why it cannot load the class jline : Ignoring argument class_path: /usr2/exploit/etc/was/plugins/jline-1.0.jar
[14:57] <jimbaker> iirc, it should be using stty
[14:57] <scavenger> it says Context classloader is not ExtClassloader
[14:57] <jimbaker> scavenger, yes, this can be restricted by the ClassLoader
[14:58] <scavenger> hmm what should the problem comes from ? kernel ? tty ? other ?
[14:59] <jimbaker> scavenger, well usually such ClassLoader restrictions are put in place by a container
[14:59] <scavenger> IBM AIX sure misses some gnu libraries but mostly they can be compiled
[14:59] <scavenger> if only i knew what's missing...
[15:00] <jimbaker> so we actually use jline because it's not gnu
[15:00] <jimbaker> and so we can redistribute under python license
[15:01] <scavenger> hmm so i should run the client on Linux ?
[15:02] <jimbaker> scavenger, well that would work :)
[15:02] <scavenger> even on Fedora 16 ? :)
[15:05] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[15:05] <jimbaker> scavenger, i don't know??? i'm working off of basic java 5 and stty support as the minimum here
[15:06] <scavenger> ok 'ill give a try on a distant client that's not IBM AIX
[15:06] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[15:07] <jimbaker> scavenger, after that, please take a look at in the context of the ExtClassLoader problem
[15:08] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[15:14] <jimbaker> scavenger, what little googling i did suggests that it's used w/ ibm's version of java, although there were some false positives - given the convenient name of Ext*** - for third party projects
[15:15] <jimbaker> ok, back to reading on SSLEngine??? today i would like to get it running with https://gist.github.com/jimbaker/7752779
[15:16] <jimbaker> just so i have some baseline for the socket/ssl reimpl
[15:17] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 250 seconds)
[15:24] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 246 seconds)
[16:07] * fluxdude (~fluxdude@unaffiliated/fluxdude) has joined #jython
[16:23] * paolo (~Paolo@net-37-117-0-21.cust.dsl.vodafone.it) has joined #jython
[16:46] <scavenger> hmm
[16:47] <scavenger> with jdk1.6.0_45/jdk1.7.0_45 i get Unrecognized option: -Xj9
[16:47] <scavenger> i'll have to extract the jdk from IBM's Linux 64 websphere version 7 before triing to even launch an interpreter :)
[16:48] <scavenger> that's what's nice with java: u begin something, u never ever know when it's going to end
[16:48] <scavenger> lol thanks jimbaker
[16:49] <scavenger> i'll try more on monday
[16:49] <scavenger> ++
[16:49] <jimbaker> scavenger, sure, glad i could be of assistance in beginning this journey :)
[16:55] * sinsnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) Quit (Ping timeout: 264 seconds)
[16:55] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 264 seconds)
[16:55] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[16:56] * sinsnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) has joined #jython
[18:00] * fwierzbicki (~Adium@99-106-170-162.lightspeed.sntcca.sbcglobal.net) Quit (Quit: Leaving.)
[18:01] * fwierzbicki (~Adium@99-106-170-162.lightspeed.sntcca.sbcglobal.net) has joined #jython
[18:01] * fluxdude (~fluxdude@unaffiliated/fluxdude) Quit (Quit: fluxdude)
[18:41] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[19:00] * fwierzbicki1 (~Adium@99-106-170-162.lightspeed.sntcca.sbcglobal.net) has joined #jython
[19:03] * fwierzbicki (~Adium@99-106-170-162.lightspeed.sntcca.sbcglobal.net) Quit (Ping timeout: 260 seconds)
[20:11] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 272 seconds)
[20:11] * lheuer (~Adium@f048044249.adsl.alicedsl.de) has joined #jython
[20:11] * lheuer (~Adium@f048044249.adsl.alicedsl.de) Quit (Changing host)
[20:11] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[20:14] * fluxdude (~fluxdude@unaffiliated/fluxdude) has joined #jython
[20:15] * lheuer (~Adium@unaffiliated/lheuer) Quit (Client Quit)
[20:16] * lheuer (~Adium@f048044249.adsl.alicedsl.de) has joined #jython
[20:16] * lheuer (~Adium@f048044249.adsl.alicedsl.de) Quit (Changing host)
[20:16] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[20:37] * mike_af (~mike_af@50-77-49-46-static.hfc.comcastbusiness.net) has joined #jython
[20:39] <mike_af> Hey, I have a question regarding memory usage. I'm running into some issues in Python 2.6 with high memory usage persisting even after a large object has been garbage collected. I'm investigating alternatives like Python 3.3 and Jython. I put together a short benchmarking script, and it appears that jython never releases anything back to the system.
[20:40] <mike_af> The memory usage just climbs and climbs and never falls. Am I simply doing something wrong?
[20:40] <mike_af> I'm not all that familiar with Jython or Java in general
[20:41] <mike_af> I should mention that I'm using Jython 2.7b1
[20:46] <mike_af> Same behavior seems to happen in 2.5.3 as well.
[21:00] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[21:01] * fluxdude (~fluxdude@unaffiliated/fluxdude) Quit (Quit: fluxdude)
[21:09] * [Arfreve1] (~Arfrever@minotaur.apache.org) Quit (Quit: leaving)
[21:11] * [Arfrever] (~Arfrever@apache/committer/Arfrever) has joined #jython
[21:37] <jimbaker> mike_af, can you post your benchmark script on a tool like gist.github.com?
[21:37] <mike_af> jimbaker: yeah just a sec
[21:38] <jimbaker> mike_af, in general, jython and cpython should have the same behavior in terms of gc, given that cpython also does periodic mark & sweep gc
[21:38] <jimbaker> and generational strategies tend to look like ref counting
[21:39] <mike_af> The problem I ran into in 2.6 is outlined here: http://deeplearning.net/software/theano/tutorial/python-memory-management.html#internal-memory-management
[21:40] <mike_af> I read various places that python 3 and jython did not suffer the same problem due to different memory management
[21:40] <topi`> jimbaker: your ASC gist seems to work, although first it failed to load AsynchronousSocketChannel but then I realized I was running java1.6 :)
[21:40] <jimbaker> topi`, yeah, this will force java 7
[21:40] <jimbaker> which is a good thing
[21:41] <topi`> jimbaker: these ASC's always need an associated ByteBuffer, right?
[21:41] <jimbaker> topi`, correct
[21:42] <mike_af> jimbaker: https://gist.github.com/mikeokner/7832559
[21:42] <topi`> jimbaker: do you have a plan how to masquerade that short piece of ASC usage into a pysocket implementation?
[21:42] <topi`> ASC.open() returns something which is really not a socket; so that needs a wrapper object
[21:43] <topi`> it does work and act like a socket, though
[21:43] <jimbaker> topi`, so my thinking is that when we are in blocking mode, we simply use the Future.get() to simulate, otherwise we use completions and channel through BlockingQueues
[21:44] <jimbaker> topi`, yeah, we will wrap in something that provides python socket semantics, and manages the appropriate state transitions
[21:44] <jimbaker> eg the support seen in python socket for not having to commit to server or peer socket until listen/connect
[21:45] <jimbaker> so a fair amount of work to provide a python oriented view, but i think if we have one underlying scheme, namely Async*Channel, it's going to be much much easier
[21:45] * whg is now known as zz_whg
[21:45] <jimbaker> also Async*Channel has a fairly simple and uniform api
[21:48] <topi`> mike_af: I have not heard that python 3 would introduce any differences to memory mgmt
[21:49] <jimbaker> mike_af, i have tried running your code - w/o yet reading it - against jconsole, and i do observe on my laptop that it's hanging on to approx 330 MB of memory, no gc
[21:49] <jimbaker> right before "ready to exit"
[21:50] <jimbaker> so clearly no deletion is occurring. ok let me read
[21:50] <mike_af> jimbaker: yeah, however everything is created within that function and the function returns None after explicitly del'ing everything, so it shouldn't hold any memory
[21:51] <jimbaker> mike_af, i could instrument with a gc.collect
[21:51] <mike_af> I've tried putting one right before that "ready to exit" point and it didn't make a difference
[21:51] <mike_af> topi`: I'm looking for where I read that...
[21:52] <topi`> jimbaker: I have noticed this earlier, that del'ing objects won't release anything in jython
[21:52] <jimbaker> ok, i will try. on jython we could use some the cool heap analysis tools, but nothing here looks complicated
[21:52] <topi`> jimbaker: however, I've also observed that running my jython stuff under Tomcat consumes plenty of memory, *but* at some point hitting the "Perform GC" button on jconsole actually frees stuff up
[21:53] <topi`> mike_af: where python 3 is different, is that many functions like range(), zip() now return iterables instead of (big) lists.
[21:53] <jimbaker> topi`, mike_af - well on jython, saying gc.collect() does free up
[21:53] <topi`> it does have an impact on memory usage
[21:53] <jimbaker> so there we go
[21:54] <mike_af> jimbaker: where did you put the gc.collect()?
[21:54] <topi`> jimbaker: ...so the actual GC happens very rarely in real-life jython
[21:54] <jimbaker> immediately before raw_input
[21:54] <jimbaker> topi`, yeah, i think it depends on *memory pressure*
[21:54] <jimbaker> so long as there's no memory pressure, it might be a while :)
[21:55] <jimbaker> like a really long while
[21:57] <topi`> I think those are JVM parameters
[21:58] <mike_af> jimbaker: I do see minor downward fluctuations as it runs with gc.collect before each raw_input, but I still sit at 568 MB of real memory used when it hits "ready to exit" and everything has been deleted/GC'd which is absurdly high
[22:00] <jimbaker> mike_af, on java 7 on my os x laptop, it goes down to 130MB
[22:00] <jimbaker> as reported by jconsole. i don't actually know how to ask os x for actual resident usage??? let me figure that out
[22:00] <mike_af> Interesting. I'm on CentOS 6
[22:01] <mike_af> jimbaker: /Applications/Utilities/Activity Monitor.app should show you
[22:04] <mike_af> topi`: http://stackoverflow.com/a/15457947
[22:07] <topi`> jimbaker: I "wrapped" your ASC code into a "Mysocket" class which now pretends to be a python socket object. It seems the timeouting from a read works!
[22:08] <jimbaker> topi`, cool!
[22:08] <topi`> I did a sock.read() without first writing anything, and it timed out after a while
[22:08] <jimbaker> mike_af, so i can control with some tuning options
[22:08] <jimbaker> eg jython27 -J-XX:MaxHeapFreeRatio=20 -J-XX:MinHeapFreeRatio=10 memtest.py
[22:08] <jimbaker> activity monitor still reports large memory usage, but jconsole is showing very reasonable marks
[22:08] <topi`> jimbaker: at least, the asynchronous sockets class is ripe for experimentation :)
[22:09] <jimbaker> interesting stuff. to be honest, i have not needed to play with gc tuning, but seems quite worthwhile playing with, and finding tradeoffs
[22:09] <topi`> d'oh, AttributeError
[22:09] <jimbaker> http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html
[22:10] <jimbaker> mike_af, so right now, my jvm is running in steady state between 20-30 MB
[22:10] <mike_af> jimbaker: yeah, ultimately it's the overall size reported to the system that matters to me since that's memory that the server can't use elsewhere
[22:10] <jimbaker> mike_af, right, i don't what if any java has done to reduce its footprint of memory allocs from the underlying os
[22:11] <jimbaker> iirc, it didn't in the past
[22:11] <jimbaker> in the steady state, this doesn't matter of course ;)
[22:11] <jimbaker> anyway, this is a jvm issue, not a jython one
[22:11] <topi`> whee
[22:11] <topi`> >>> sock.write(s1)
[22:11] <topi`> 1
[22:11] <topi`> >>> sock.read(80)
[22:11] <topi`> 'HTTP/1.1 408 Request Time-out\r\nDate: Fri, 06 Dec 2013 22:05:19 GMT\r\nServer: Apac'
[22:11] <topi`> >>> sock.read(80)
[22:12] <topi`> 'he/2.2.22 (Debian)\r\nVary: Accept-Encoding\r\nContent-Length: 304\r\nConnection: clos'
[22:12] <jimbaker> topi`, yeah, it's pretty easy to use
[22:12] <jimbaker> in blocking mode
[22:12] <mike_af> Ok, that's good to know. Do you have a link where I can read more about those jython -J-XX options you passed? Or a name for them I can look up?
[22:12] <topi`> jimbaker: how do you know if it's in blocking or nonblocking mode?
[22:12] <jimbaker> topi`, https://wiki.python.org/jython/NewSocketModule talks about this stuff
[22:13] <jimbaker> basically this is all written targeting java 1.4
[22:13] <jimbaker> now we get to revisit :)
[22:13] <jimbaker> in particular the hack for zero timeout no longer applies, https://wiki.python.org/jython/NewSocketModule#Differences_in_the_treatment_of_zero_timeout_values
[22:15] <jimbaker> this is a function that the code is mixing actual underlying impl of nonblocking and blocking sockets. but if we use Async*Channel, we don't care, we just change how we call, either using Future or completions
[22:15] <topi`> so we should emulate CPython behavior about returning a non-blocking socket when timeout=0?
[22:15] <jimbaker> exactly
[22:15] <jimbaker> so we transition our socket encapsulation class to be non-blocking
[22:15] <topi`> what are these "completions"?
[22:16] <topi`> I need to browse thru the documentation on Java 7
[22:16] <topi`> (it's vast)
[22:16] <jimbaker> topi`, by completions, i mean calls like this one: http://docs.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html#read(java.nio.ByteBuffer[], int, int, long, java.util.concurrent.TimeUnit, A, java.nio.channels.CompletionHandler)
[22:16] <jimbaker> specifically of course supporting this interface, http://docs.oracle.com/javase/7/docs/api/java/nio/channels/CompletionHandler.html
[22:17] <jimbaker> so this is just a simple dispatcher that support the select/poll emulation
[22:17] <jimbaker> by going through an appropriate heavy lifting concurrent data structure
[22:18] <jimbaker> (i call stuff like this heavy lifting where we throw copious amounts of java concurrent util - or guava - magic at what is done in a very *simplistic* fashion in cpython, because of stuff like the GIL)
[22:18] <topi`> ah, completionHandler is like a callback?
[22:18] <jimbaker> topi`, yeah w/ success OR failure
[22:19] <jimbaker> so just 2 paths
[22:19] <jimbaker> should like very familiar, in a twisted sort of way
[22:19] <jimbaker> ;)
[22:20] <jimbaker> so to support a naive interface like select, we need a fairly complex amount of machinery, whereas poll is terribly trivial - it's; just a BlockingQueue
[22:21] <topi`> I wonder how that select/poll stuff is done in PyPy, which also lacks GIL
[22:21] <pjenvey> pypy has a GIL actually
[22:21] <jimbaker> topi`, but PyPy does have a GIL
[22:21] <topi`> I'm misinformed :)
[22:21] <jimbaker> that's where i get to get up and dance, haha, PyPy has a GIL ;)
[22:22] <jimbaker> anyway, they are trying to get rid of it with software transactional memory
[22:22] <jimbaker> and if they succeed there w/ good performance - pjenvey might have more recent insight - they will have truly the last laugh
[22:22] <pjenvey> hopefully not for long if the pypy STM effort pans out
[22:22] <topi`> yeah, I've watched some presentation of Armin Rigo
[22:23] <pjenvey> we'll see how it goes, it's still early on I think
[22:23] <topi`> jimbaker: well, if they will succeed, it'll just mean good things for the future of Python :)
[22:23] <jimbaker> no question it's a good approach. but then again, i'm really looking forward to seeing Spliterator from java 8
[22:23] <jimbaker> topi`, yeah, we are cool w/ their success, don't get me wrong ;)
[22:23] <topi`> jimbaker: a little bit of competition cannot hurt anyone ;)
[22:24] <jimbaker> topi`, indeed it cannot
[22:24] <topi`> anyway, jython has one important advantage - it runs on Tomcat, Glassfish, other containers :)
[22:24] <jimbaker> topi`, or Storm or Hadoop
[22:24] <jimbaker> topi`, so what do you think? Async*Channel is pretty darn cool
[22:25] <topi`> I tried out the Macropy project, but couldn't get the experimental macros working
[22:25] <jimbaker> topi`, i did a little design exploration of implementing select, let me clean that & post a gist
[22:25] <topi`> if anyone knows how to get PINQ stuff going on, let me know ;)
[22:25] <topi`> jimbaker: good, I'll check it out
[22:25] <jimbaker> topi`, i think the problem is, this was a class project. a very well done class project
[22:26] <jimbaker> but still a class project. someone should pick it up, because macropy has a fantastic premise
[22:27] <topi`> at some point, we'll get it running on jython ;)
[22:27] <topi`> ...after some major module loading voodoo
[22:27] <topi`> it basically has to intercept imports, and then rewrite the AST, and then import
[22:28] <jimbaker> topi`, does it do setuptools integration?
[22:28] <topi`> I doubt that
[22:28] <jimbaker> because that's the obvious place to define specific intereception
[22:29] <jimbaker> i mean it can be all dynamic, but better if there is a specific point in time for stuff like this
[22:29] <topi`> agree
[22:35] <topi`> the Async*Channel is easy enough to use, but I'm baffled as always by the myriad of ways the different methods can be called :)
[22:36] <jimbaker> topi`, au contraire, it is a very good thing
[22:37] <jimbaker> so if blocking (but no timeout), we use Future; otherwise completionhandler
[22:38] <jimbaker> actually we might want to just use completionhandler, and block on a condition variable
[22:38] <jimbaker> even for blocking
[22:38] <jimbaker> just to keep uniform
[23:15] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[23:17] <jimbaker> topi`, now i remember why we should only use completionhandlers - it's perfectly possible for select to work on blocked sockets (presumably in a separate thread)
[23:17] <jimbaker> https://wiki.python.org/jython/SelectModule#Only_sockets_in_non-blocking_mode_can_be_multiplexed is a current limitation
[23:18] <jimbaker> but we don't need to have that likmitation
[23:19] <jimbaker> so the completiohandler can simply notify the select, along with the condition variable we will use for blocking; which can be done w/ timeout - http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/Condition.html#await(long, java.util.concurrent.TimeUnit)
[23:29] * mike_af (~mike_af@50-77-49-46-static.hfc.comcastbusiness.net) Quit (Remote host closed the connection)
[23:30] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[23:52] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 246 seconds)
[23:59] * oscar_toro (~Thunderbi@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 250 seconds)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).