Timestamps are in GMT/BST.
[0:15] <jimbaker> who is the admin for this channel? the psf is currently registering #python related domains with freenode, so we probably want to do the same with this channel too
[0:40] * jimbaker (~jbaker@64.134.27.206) Quit (Quit: jimbaker)
[0:57] * lopex (lopex@chello089076044027.chello.pl) Quit ()
[1:18] * maxb (~maxb@jabberwock.vm.bytemark.co.uk) has joined #jython
[1:22] * skay (~skay@c-71-239-171-114.hsd1.il.comcast.net) has joined #jython
[1:30] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) has joined #jython
[1:36] <agronholm> jimbaker: I was wondering, what are the primary reasons for running a vm on top of a vm?
[1:36] <jimbaker> you mean the python bytecode vm?
[1:36] <agronholm> yeah
[1:37] <jimbaker> support of 1) applets; 2) android; 3) long methods - i forgot the exact size, but maybe > ~32K bytecodes; 4) code that generates python bytecode
[1:38] <jimbaker> it could also be potentially be useful in certain situations because it's more compact
[1:38] <agronholm> I question the validity of 1 and 4, 2 I can somehow understand, 3 I don't understand at all
[1:39] <jimbaker> i was also thinking of implementing greenlets with it, but the jvm coroutine support is the right way to do it
[1:39] <agronholm> is it in already?
[1:39] <agronholm> I understand it was maybe coming to java 7
[1:39] <jimbaker> 1) applies to applets where we generate code on the fly. obviously better to compile ahead of time
[1:40] <jimbaker> 2) similar reason, dalvik limits us here
[1:40] <jimbaker> 3) see http://bugs.jython.org/issue527524
[1:41] <agronholm> are those restrictions still valid in java7?
[1:41] * tef (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) Quit (Quit: ffffffffffffffffffffffffff)
[1:41] <jimbaker> yes, they are a function of limits in the java lang spec for bytecode offsets
[1:42] <jimbaker> they could be readily extended. but they havent
[1:42] <jimbaker> 4) there's some code in the wild that generates python bytecode. turbogears used to depend on one such package
[1:43] <jimbaker> i believe there are others
[1:43] <jimbaker> 1,2,3 are obviously the most interesting. basically i want to have a console when programming against android
[1:43] <agronholm> for 3: couldn't such functions be implemented as several separate methods?
[1:43] <agronholm> which would share a common closure
[1:43] <jimbaker> agronholm: yes, but it's actually much harder to compile
[1:44] <jimbaker> a non-trivial thing to break an arbitrary method like that
[1:44] <jimbaker> the pbcvm is much, much easier. trust me
[1:44] <agronholm> I know, but if it's possible at all, it should be kept as an option
[1:44] <agronholm> yeah but the speed is hardly impressive
[1:45] <jimbaker> large methods almost never have any hot properties
[1:45] <jimbaker> they typically are used for initialization and are generated
[1:45] <agronholm> yeah but then we're using the pbcvm even for "hot" functions
[1:45] <jimbaker> no, the pbcvm is just one possible way to run code in jython
[1:46] <jimbaker> it's in there now, i don't believe anyone is using it, but you can use it today
[1:46] <agronholm> ok now I'm officially confused
[1:46] <jimbaker> you just need to have a python bytecode compiler. i usually use cpython 2.5 for this purpose ;)
[1:46] <agronholm> oh right
[1:46] <jimbaker> what's really cool about jython is that we can have multiple compilation strategies
[1:47] * tef (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) has joined #jython
[1:47] <agronholm> issue 527524 is still open because the pbcvm is NOT being used by default
[1:47] <jimbaker> jython doesn't care what a PyCode object, just that it supports a specific interface
[1:47] <jimbaker> the issue is open until someone like myself does the moderate amount of work to write a python bytecode compiler
[1:48] <jimbaker> that plus a small amount of work on proxies, and we get immediate support for android, applets, and large methods. cool, right?
[1:48] <agronholm> sounds cool
[1:49] <agronholm> but how will the performance be
[1:49] <jimbaker> most of the compiler work is already done too, probably the biggest part is writing an assembler
[1:49] <agronholm> my android 2.1 phone is sluggish enough as it is
[1:49] <jimbaker> agronholm: i'm not too worried about targeting your phone
[1:49] <agronholm> android tablets then?
[1:49] <jimbaker> yes
[1:49] <jimbaker> consider running processing.py on an android tablet
[1:50] <jimbaker> that would be truly nice
[1:50] <agronholm> it'd be nice to make android apps with jython too
[1:50] <agronholm> for phones that is
[1:50] <agronholm> one can dream :)
[1:50] <jimbaker> first we need to work on packaging. there's a lot of unnecessary stuff for most apps in the jython jar
[1:50] <jimbaker> need to use something like ProGuard to slim it down
[1:51] <jimbaker> most apps never need to introspect the AST
[1:51] <jimbaker> if they don't, there's goes a whole bunch of classes
[1:51] <jimbaker> and you can't use ASM, so might as well strip that out too
[1:51] <jimbaker> and so forth
[1:52] <jimbaker> i recently added guava, but we are only using a small part. strip it down too
[1:52] <agronholm> swingutils-binding uses the AST features pretty heavily, and it could be adapted for android too
[1:52] <agronholm> or any other gui toolkit for that matter
[1:53] <jimbaker> ok, then don't strip that part. it needs to based on what the app actually uses, through some sort of profiling
[1:53] <agronholm> yeah
[1:53] <agronholm> if you have a tool that does that, all is fine
[1:53] <agronholm> a tool such as jboss tattletale I guess
[1:54] <jimbaker> exactly. the one good thing is, it's something that we can share w/ jruby and other lang implementations
[1:54] <agronholm> does python limit the length of functions in any way?
[1:55] <jimbaker> tattletale looks interesting, but i don't know how much it supports dynamic/reflection environments
[1:55] <jimbaker> agronholm: no
[1:55] <jimbaker> maybe it could be useful for helping us understand osgi support
[1:56] <jimbaker> the other thing we need to do is work on startup performance
[1:56] <jimbaker> remi forax just was looking at jython using java 7's new tiered compilation
[1:57] <jimbaker> it's just what we would want. that plus profiling what's necessary to bring up jython, make it perhaps lazier, and we should significantly reduce startup time
[1:58] <jimbaker> i'm very certain that is possible, because no one has actually worked on that problem, and we've only been making startup worse over the 2.5 dev cycle
[1:58] <jimbaker> after we get a final beta, i plan to spend at least some time on this before release candidate 1
[2:00] <agronholm> I believe that once someone really starts digging into it, we'll get a vastly improved startup time
[2:00] <jimbaker> that's my belief too
[2:55] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 265 seconds)
[3:14] * verterok_ (~ggonzalez@190.188.218.58) has joined #jython
[3:14] * verterok_ (~ggonzalez@190.188.218.58) Quit (Changing host)
[3:14] * verterok_ (~ggonzalez@unaffiliated/verterok) has joined #jython
[3:14] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Quit: leaving)
[3:25] * jcp (~jw@bzflag/contributor/javawizard2539) Quit (Excess Flood)
[3:28] * hpk (~hpk@HSI-KBW-085-216-105-248.hsi.kabelbw.de) Quit (Remote host closed the connection)
[3:29] * jcp (~jw@bzflag/contributor/javawizard2539) has joined #jython
[3:37] * stakkars (~tismer@i59F7DA40.versanet.de) Quit (Quit: stakkars)
[3:45] * verterok_ (~ggonzalez@unaffiliated/verterok) Quit (Ping timeout: 260 seconds)
[3:49] * verterok (~ggonzalez@unaffiliated/verterok) has joined #jython
[4:25] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Quit: leaving)
[5:11] * hpk (~hpk@HSI-KBW-085-216-105-248.hsi.kabelbw.de) has joined #jython
[5:38] * thobe (~Adium@c83-249-252-237.bredband.comhem.se) Quit (Quit: Leaving.)
[6:10] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[6:16] * stakkars (~tismer@i59F7DA40.versanet.de) has joined #jython
[6:19] * pr3d4t0r (~cu4cu4@varenka.cime.net) Quit (Ping timeout: 252 seconds)
[6:30] * thijstriemstra (~thijstrie@h161140.upc-h.chello.nl) Quit (Quit: thijstriemstra)
[6:30] * thobe (~Adium@212-162-171-110.skbbip.com) has joined #jython
[6:57] <ohumbel> jimbaker: yes i am planning to prepare all the version specific stuff in build.xml soon
[7:09] * pr3d4t0r (~cu4cu4@varenka.cime.net) has joined #jython
[7:53] * stever (~stever@dsl78-143-230-39.in-addr.fast.co.uk) has joined #jython
[8:01] * jabley_ (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[8:05] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Ping timeout: 276 seconds)
[8:05] * jabley_ is now known as jabley
[8:30] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Quit: jabley)
[8:55] * lheuer (~heuer@unaffiliated/lheuer) has joined #jython
[9:08] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) has joined #jython
[9:50] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) has joined #jython
[10:19] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 252 seconds)
[10:25] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[10:59] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 276 seconds)
[11:04] * juneau001 (~juneau@FESS-116326-2283678-dp.dhcp.fnal.gov) has joined #jython
[11:46] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) Quit (Quit: Page closed)
[11:58] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) has joined #jython
[12:12] * seberg (~sebastian@vpn-3126.gwdg.de) has joined #jython
[12:18] * svenk (~sven@213.73.89.36) Quit (Ping timeout: 245 seconds)
[12:18] * Moo^_^ (~quassel@herd37.twinapex.fi) Quit (Ping timeout: 245 seconds)
[12:18] * svenk (~sven@213.73.89.36) has joined #jython
[12:19] * moo (~quassel@herd37.twinapex.fi) has joined #jython
[12:20] * moo is now known as Guest66615
[13:06] * seberg (~sebastian@vpn-3126.gwdg.de) Quit (Quit: Ex-Chat)
[13:07] * seberg (~sebastian@vpn-3126.gwdg.de) has joined #jython
[13:11] * pigletto (~pigletto@dut116.neoplus.adsl.tpnet.pl) has joined #jython
[13:17] * verterok (~ggonzalez@unaffiliated/verterok) has joined #jython
[13:26] * fwierzbicki (~frank@64.34.151.178) has joined #jython
[13:26] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Quit: Leaving.)
[14:07] * tef (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) Quit (Quit: ffffffffffffffffffffffffff)
[14:20] * thobe (~Adium@212-162-171-110.skbbip.com) has joined #jython
[14:24] * pigletto (~pigletto@dut116.neoplus.adsl.tpnet.pl) Quit (Remote host closed the connection)
[14:27] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) has joined #jython
[14:29] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) Quit (Quit: jimbaker)
[14:30] * lheuer (~heuer@unaffiliated/lheuer) Quit (Quit: Closing Time)
[14:42] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Quit: Leaving.)
[14:43] * tef_ (~tef@129.215.36.7) has joined #jython
[15:04] * jimbaker (~jbaker@64.134.158.2) has joined #jython
[15:07] <jimbaker> headius: in brazil?
[15:08] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) Quit (Ping timeout: 276 seconds)
[15:10] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) Quit (Ping timeout: 252 seconds)
[15:16] <jimbaker> the one issue that won't go away for us is the management of ThreadState. i'm very uncomfortable of how these objects, which are still in the ThreadLocal mapping, now require synchronization so that another thread can clean them up
[15:16] <jimbaker> in order to remove ClassLoader ref cycles
[15:19] <jimbaker> obviously it's ok for ThreadState to escape the thread confinement, Java doesn't get that wrong; but architecturally, having to synchronize on a ThreadLocal#get is just wrong
[15:21] * seberg (~sebastian@vpn-3126.gwdg.de) Quit (Quit: Ex-Chat)
[15:22] <jimbaker> my current feeling is that we should do the following: 1) move dynamically scoped fields out of ThreadState and into a real thread-confined ThreadLocal. these are initializingProxies and reprStack, at the very least; there may be others
[15:23] <jimbaker> 2) change ThreadStateMapping to use a ConcurrentMap, because as it stands now, everything that needs to do Py#getThreadState is passing through a single lock
[15:24] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) has joined #jython
[15:25] <jimbaker> headius: i was just trying to work out my thoughts on ThreadState mapping, you might have some insight
[15:25] <headius> ThreadState?
[15:25] <headius> I have about 5 minutes before lunch with some brazil folks, but go ahead :)
[15:25] <jimbaker> i think it's similar to a JRuby context that you pass around
[15:25] <headius> ahh righto
[15:26] <jimbaker> basically it keeps track of the "global" execution space - whether namespace, current exception, that sort of thing
[15:27] <jimbaker> we have been thrashing on a classloader bug that's related to this
[15:28] <jimbaker> in general, when i see so much thrashing, it means to me that we have something we don't understand well, even if it has worked out in the past
[15:28] <headius> ok
[15:28] <headius> you have two minutes to get to the point :)
[15:28] <jimbaker> you might want to take a look at the log just before you came in
[15:28] <headius> ok
[15:28] <headius> that works
[15:29] <jimbaker> and since it's not there yet - 2) change ThreadStateMapping to use a ConcurrentMap, because as it stands now, everything that needs to do Py#getThreadState is passing through a single lock
[15:29] <headius> I see some startup time stuff
[15:29] <headius> that's about all in logs recently
[15:29] <headius> oh ouch
[15:29] <headius> yeah
[15:29] <headius> so in JRuby the ThreadContext is in a threadlocal
[15:30] <headius> to get it there's two hops normally... through the Ruby instance that *is* JRuby, and then through a ThreadService which holds the threadlocal
[15:30] <headius> but even that's costly, which is why we pass it through call stack everywhere
[15:30] <headius> I suppose you're going through that lock because you lazily stand them up?
[15:30] <headius> ( I have to go real quick now)
[15:30] <jimbaker> exactly, we do the same. so we just do this for calls in/out of java
[15:31] <headius> ahhh
[15:31] <jimbaker> PySystemState is probably the equiv of your Ruby instance
[15:31] <headius> ok
[15:31] <headius> yeah, I don't think we have any locks because it's thread-local by definition
[15:31] <jimbaker> until recently
[15:31] <headius> there's no one global structure that holds all threadcontexts...they're just in threadlocals
[15:31] <headius> is your map from Thread to ThreadState?
[15:32] <jimbaker> for a permgen exhaustion bug, we introduced a workaround to cleanup ThreadState
[15:32] <jimbaker> this would be seen in a thread pool
[15:32] <jimbaker> and the ThreadState was pinning ClassLoaders
[15:33] <headius> ahhh yes
[15:33] <jimbaker> that's the root of the problem, so to punningly speak ;)
[15:33] <headius> ok, I have to run, but I'll gather thoughts on this
[15:33] <headius> we've dealt with this kind of stuff many times
[15:33] <headius> specifically with threadcontext leaks and such
[15:33] <headius> ok, bbl
[15:33] <jimbaker> sounds good, thanks!
[15:36] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) has joined #jython
[15:36] <Oti> jimbaker - i am getting closer to 2.5.2b2
[15:36] <jimbaker> Oti: sounds great!
[15:36] <Oti> is there anything special you might want to mention in NEWS or README ?
[15:36] <jimbaker> i am very worried about the bottleneck i created in the current ThreadStateMapping
[15:37] <jimbaker> but it can't be helped for this beta, correctness must be first
[15:37] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[15:37] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) Quit (Ping timeout: 240 seconds)
[15:38] <Oti> ok
[15:38] <jimbaker> so i think we should simply ask people to look at this release and determine if jython has any outstanding resource leaks, that sort of thing
[15:38] <Oti> if no one objects, i'll copy the tag in about 6 hours
[15:39] <jimbaker> i think the other thing we need to loudly mention is that if companies are using jython 2.2.1, they really should test against 2.5.2 now
[15:39] <Oti> got these
[15:39] <jimbaker> it's time to get off the fence so we can address any upgrade issues for we ship 2.5.2 final
[15:39] <jimbaker> before we ship
[15:40] <jimbaker> i don't believe anyone wants to have a 2.5.3, except critical fixes
[15:40] <Oti> but please feel free to commit NEWS or README with your own writing (since i am not native English, my results might sound funny)
[15:41] <jimbaker> sure, i will do this part. and i will need to blog on it too
[15:41] <Oti> that would be great, really
[15:44] <jimbaker> Oti: my other concern is that we now require PythonInterpreter#initialize; even though it was documented in the past, it wasn't required. that's my other concern, we are going to start seeing breakage
[15:45] * seberg (~sebastian@vpn-3207.gwdg.de) has joined #jython
[15:46] <Oti> yes, i was used to it already, but everybody else i met forgets it
[15:46] <jimbaker> we should be able to avoid this, standard singleton stuff and all, but the ClassLoader issues are causing problems here
[15:47] <jimbaker> so i hate to say this, but maybe we should push the beta2 to monday
[15:47] <jimbaker> it will give us one more weekend to look at the problem
[15:48] <Oti> no problem with me
[15:48] <jimbaker> and it will probably be more visible to people than a friday release
[15:48] <Oti> i have some hours tonight (were i would have done the beta), and probably on Sunday (Saturday is filled)
[15:48] <jimbaker> after all, we really want people to start testing against 2.5.2b2
[15:50] <jimbaker> ok, let's do that. we will put together the beta release sunday. and officially announce it monday morning (0900 UTC is probably good)
[15:51] <jimbaker> with that, i need to take off. i'm officially looking for a new job, and i have to coffee with some recruiters shortly :)
[15:53] * jimbaker (~jbaker@64.134.158.2) Quit (Quit: jimbaker)
[15:55] <Oti> bye
[15:55] * ohumbel (5390f2dc@gateway/web/freenode/ip.83.144.242.220) Quit (Quit: Page closed)
[15:57] * ohumbel (5390f2dc@gateway/web/freenode/ip.83.144.242.220) has joined #jython
[15:58] <juneau001> Oti: let me know when the beta is ready and I can post it on the website
[15:59] <Oti> juneau001: will do!
[15:59] <juneau001> let me know if you need anything else...good luck and enjoy the weekend
[16:00] <Oti> thanks! you too
[16:02] * enebo (~enebo@184-97-190-212.mpls.qwest.net) has joined #jython
[16:04] * stever (~stever@dsl78-143-230-39.in-addr.fast.co.uk) Quit (Quit: Leaving)
[16:05] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) Quit (Quit: Page closed)
[16:13] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 276 seconds)
[16:15] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) Quit (Quit: jabley)
[16:41] * thobe (~Adium@83.249.252.237) has joined #jython
[16:46] * thobe (~Adium@83.249.252.237) Quit (Client Quit)
[17:23] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[17:46] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Quit: jabley)
[18:13] * stakkars (~tismer@i59F7DA40.versanet.de) Quit (Read error: Operation timed out)
[18:16] * skay (~skay@c-71-239-171-114.hsd1.il.comcast.net) Quit (Quit: skay)
[18:20] * tef (~tef@129.215.36.11) has joined #jython
[18:21] * stakkars (~tismer@i59F7D7AA.versanet.de) has joined #jython
[18:22] * tef_ (~tef@129.215.36.7) Quit (Ping timeout: 276 seconds)
[18:24] * tef (~tef@129.215.36.11) Quit (Ping timeout: 255 seconds)
[18:36] * jimbaker (~jbaker@71-212-130-151.hlrn.qwest.net) has joined #jython
[18:57] * jimbaker (~jbaker@71-212-130-151.hlrn.qwest.net) Quit (Quit: jimbaker)
[19:01] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[19:15] * juneau001 (~juneau@FESS-116326-2283678-dp.dhcp.fnal.gov) Quit (Quit: juneau001)
[19:17] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[19:32] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 245 seconds)
[19:36] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[19:53] * yacc (~andreas@chello062178129237.5.13.vie.surfer.at) has joined #jython
[20:08] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Quit: jabley)
[20:13] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) has joined #jython
[20:40] * tef (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) has joined #jython
[20:45] * tef_ (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) has joined #jython
[20:49] * tef (~tef@cpc2-sgyl1-0-0-cust1814.sgyl.cable.virginmedia.com) Quit (Ping timeout: 276 seconds)
[20:49] * tef_ is now known as tef
[20:58] * lopex (lopex@chello089076044027.chello.pl) has joined #jython
[21:00] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[21:11] * thijstriemstra (~thijstrie@h161140.upc-h.chello.nl) has joined #jython
[21:35] * stever (~stever@dsl78-143-208-248.in-addr.fast.co.uk) has joined #jython
[22:49] * fwierzbicki (~frank@64.34.151.178) Quit (Ping timeout: 265 seconds)
[23:14] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Quit: leaving)
[23:21] * yacc (~andreas@chello062178129237.5.13.vie.surfer.at) Quit (Remote host closed the connection)
[23:25] * seberg (~sebastian@vpn-3207.gwdg.de) Quit (Ping timeout: 276 seconds)
[23:29] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) Quit (Ping timeout: 252 seconds)
[23:32] * enebo (~enebo@184-97-190-212.mpls.qwest.net) Quit (Quit: enebo)
[23:40] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) has joined #jython
[23:49] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) Quit (Ping timeout: 264 seconds)
[23:53] * headius (~headius@AS28165-187-62-212-138.wcs.net.br) has joined #jython
[23:55] * stever (~stever@dsl78-143-208-248.in-addr.fast.co.uk) Quit (Quit: Leaving)
[23:58] * jcp (~jw@bzflag/contributor/javawizard2539) Quit (Ping timeout: 255 seconds)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).