#jython IRC Log (v0.9)

Index

IRC Log for 2010-11-16

Timestamps are in GMT/BST.

[0:00] <jimbaker> sure, this makes sense for pdb
[0:00] <jimbaker> but it doesn't say anything about the problem you're seeing
[0:00] <jimbaker> in terms of exception mgmt
[0:01] <agronholm> yeah
[0:01] <agronholm> I'm just trying to figure out how to even start debugging it
[0:01] <jimbaker> agronholm: i personally prefer logging and/or prints
[0:02] <jimbaker> but that's definitely the other school of thought from debuggers
[0:02] <agronholm> that's what I've been trying to do, but even when I print to stderr, the timing of the errors is really weird
[0:02] * jimbaker can't generally stand using debuggers, too limited of a perspective
[0:03] <agronholm> to me, debuggers are the lifeline
[0:03] <jimbaker> you may need to use some form of logging
[0:03] <agronholm> and ideally does not force me to alter the source code
[0:03] <agronholm> jimbaker: other than print to stderr?
[0:04] <jimbaker> if printing is introducing timing problems or other access
[0:04] <agronholm> I don't think it's introducing any problems
[0:05] <jimbaker> ok. in any event - my normal flow when i'm working with code is that i find it very easy to revert out these sort of modifications
[0:05] <jimbaker> this assumes having access to source of course
[0:09] * shanka1 (~shashank@c-98-245-87-8.hsd1.co.comcast.net) Quit (Ping timeout: 260 seconds)
[0:13] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Ping timeout: 240 seconds)
[0:16] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[0:16] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Client Quit)
[0:32] <agronholm> jimbaker: this is getting stranger and stranger
[0:33] <agronholm> apparently my try...except IS catching the exception
[0:33] <agronholm> but it's still printing the traceback
[0:33] <jimbaker> agronholm: does sound strange. do you have a paste?
[0:35] <agronholm> the exception itself reveals nothing strange
[0:35] <agronholm> the traceback that is
[0:35] <agronholm> what do you wish to see?
[0:36] <jimbaker> just the code that's producing this. otherwise it's too abstract
[0:36] <agronholm> I'll try to simplify the test to remove the context from it
[0:36] <agronholm> let's see what happens if I deliberately raise a java exception
[0:37] <jimbaker> sounds good
[0:43] <agronholm> jimbaker: ok, getting even stranger
[0:44] <agronholm> it happens when I manually raise an org.hibernate.LazyInitializationException, but not when I raise a java.lang.Exception
[0:45] <agronholm> if this wasn't restricted to a jws environment, I'd say there was a code that manually printed a traceback when this exception is raised
[0:45] <agronholm> but it doesn't happen in the dev environment
[0:45] <agronholm> trying again with java.lang.RuntimeException
[0:46] <agronholm> no traceback
[0:47] <agronholm> trying with a raw HibernateException
[0:48] <agronholm> jimbaker: ok I think I nailed it
[0:48] <jimbaker> agronholm: what is it?
[0:49] <agronholm> http://pastebin.com/PuTgSUG0
[0:49] <agronholm> so not a jython problem -- sorry for wasting your time
[0:49] <agronholm> it is strange that it doesn't occur in development though
[0:50] <jimbaker> yeah, this is the opposite problem - java code is often over instrumented :)
[0:51] <agronholm> too bad avoiding the exception in the application is impossible
[0:53] <jimbaker> unless you use eager loading - but that's probably not going to help your app's perf
[0:54] <jimbaker> massive workaround
[0:54] <agronholm> yeah...
[0:54] <agronholm> hibernate's eager loading configuration really sucks
[0:55] <agronholm> I'm rapidly migrating the client to Python
[0:55] <agronholm> right now it's about 50% python 50% java
[0:55] <agronholm> then I'll migrate the server app
[0:55] <agronholm> sqlalchemy ftw
[0:56] <agronholm> migrating to python has made the client considerably slower though
[0:56] <agronholm> but the code is far more manageable
[0:56] <jimbaker> agronholm: glad to hear it. i do think SA is a huge adv for jython
[0:57] <jimbaker> agronholm: have you tried profiling to find hot spots in your client code? or are there other sources of problems? (beyond the startup issues, sorry we couldn't address before 2.6)
[0:57] <agronholm> using a java profiler?
[0:59] <jimbaker> probably just use the python profile module
[0:59] <agronholm> I'll check it out
[0:59] <jimbaker> actually uses about the same instrumentation as pdb
[0:59] <agronholm> http://pastebin.com/GpfjxYLw <- this shows how I'm taking advantage of Python in the client
[1:00] <jimbaker> twisted i take it?
[1:00] <agronholm> no
[1:00] <agronholm> jython-swingutils
[1:00] <jimbaker> ahh, you added inlineCallbacks for that? cool
[1:01] <agronholm> yes -- it allows to write synchronous-looking code that does not block the event dispatch thread
[1:01] <jimbaker> reactor speed is pretty important for that
[1:01] <agronholm> I'm fairly proud of this :)
[1:01] <agronholm> reactor speed?
[1:02] <jimbaker> your event dispatch loop
[1:02] <agronholm> that is the AWT event dispatch loop
[1:02] <jimbaker> of course - but it's a reactor like in twisted
[1:02] <agronholm> yeah
[1:03] <agronholm> can you see what happens here?
[1:03] <jimbaker> so it tends to be hotspot. could be a problem. you might want to look at something like niosted
[1:03] <agronholm> well I can't switch to a different reactor
[1:03] <agronholm> this function is the event handler for the "print labels" button
[1:04] <jimbaker> sorry, i mean just look at their code
[1:04] <jimbaker> yeah, i think it's pretty cool code. i definitely like the approach
[1:04] <agronholm> I really don't understand how that would help me since I have no control over the reactor stuff
[1:06] <jimbaker> agronholm: i think it's just a question of seeing if there are any ideas that might be used to make the event dispatch faster. i'd have to look at your swingutils again
[1:07] <agronholm> http://bitbucket.org/agronholm/jython-swingutils/src/tip/swingutils/threads/defer.py
[1:07] <agronholm> there's the relevant module
[1:07] <agronholm> lines 105->
[1:07] <agronholm> and this too: http://bitbucket.org/agronholm/jython-swingutils/src/tip/swingutils/threads/swing.py
[1:07] <jimbaker> but in general - like in python in general - there's going to be some hot code that can be identified by profiling and sped up
[1:08] <jimbaker> either by doing some easy tricks in the python code, or writing a piece in java
[1:08] <jimbaker> especially if you do some work to go directly against PyObject
[1:09] <agronholm> yup
[1:11] <jimbaker> agronholm: this code does look hot. it doesn
[1:11] <jimbaker> not look like it does too much, but it might be worth trying to optimize
[1:12] <agronholm> what code in particular
[1:12] <agronholm> and by hot I assume you mean slow
[1:16] <jimbaker> hot here means frequently executed
[1:17] <agronholm> well yeah
[1:17] <agronholm> but I don't see much room for optimization
[1:17] <jimbaker> for now, jython will be slower than java. the question is, is there enough execution time spent in these methods to justify writing in java?
[1:17] <jimbaker> right
[1:18] <agronholm> I don't think this can be written in Java
[1:18] <agronholm> since it involves generators
[1:19] <agronholm> even so, this isn't "hot" enough to warrant that
[1:19] <jimbaker> generators certainly interoperate w/ java :)
[1:19] <agronholm> http://bitbucket.org/agronholm/jython-swingutils/src/tip/swingutils/beans.py <- this on the other hand contains some really hot code
[1:19] <jimbaker> agronholm: probably. i would profile to verify
[1:19] <agronholm> ok
[1:46] <agronholm> fixed my problem -- replaced slf4j-simple.jar with slf4j-nop.jar
[1:46] <agronholm> so the webstart client uses no-op logging :)
[1:46] * lopex (lopex@chello089076044027.chello.pl) Quit ()
[1:57] * adiroiban (~adiroiban@89.137.108.176) Quit (Ping timeout: 240 seconds)
[2:45] * Alex_Gaynor (~alex_gayn@ahwahnee-71.dynamic2.rpi.edu) has joined #jython
[2:47] <Alex_Gaynor> jimbaker: Hey, I'm looking at http://code.djangoproject.com/ticket/14298 ATM, and unfortunately I can't find a clean way to make it happen, right now this is the main cursor handling place: http://code.djangoproject.com/browser/django/trunk/django/db/models/sql/compiler.py#L729, as you can see we return just the iterator, so I'm not sure how to handle this sanely?
[2:47] <Alex_Gaynor> One solution is some sort of iterator wrapper that calls close before raising StopIteration, but this code is obviously written in a performance conscious manner and I'd hate to add anything more there
[2:48] <jimbaker> Alex_Gaynor: looking...
[2:50] <jimbaker> Alex_Gaynor: as sort of implied by the workaround in the bug report, this is a fundamental problem in any non ref counting impl (so all impls except cpython)
[2:50] <jimbaker> i think the challenge here is that the code path allows for either the return of the cursor or a result
[2:50] <Alex_Gaynor> yup, I agree completely, I already fixed a bunch of bug in the test suite WRT to ref-coutning
[2:51] <jimbaker> regardless it needs to be scoped such that the cursor closes
[2:52] <Alex_Gaynor> right, the problem is we can't close it in this method
[2:52] <Alex_Gaynor> it needs to be closed after iteration
[2:52] <jimbaker> exactly. caller owns that responsibility
[2:53] <Alex_Gaynor> the caller never sees the cursor though, since it gets an iterator over it (or a list)
[2:53] <jimbaker> oh i see. that's the implication of the stopiteration you mentioned at the start
[2:54] <jimbaker> so presumably there aren't problems with the iterator being half consumed or whatever?
[2:55] <jimbaker> maybe just some sort of decorator or other functional on execute_sql if the impl is not cpython?
[2:55] <jimbaker> to go and add the wrapper?
[2:57] <jimbaker> that would then have zero perf implication for cpython and make it work at least under this convention. it's still best if there's a habit of always-be-closing in the usage of this method since it's so easy to hold ref for longer than expected even in cpython
[3:00] <Alex_Gaynor> I agree, I'll think about the wrapper, I hate seperate code paths for seperate impls thoug
[3:01] <jimbaker> me too, but this is a perf optimization, so it's ok for us to violate that rule in this special case ;)
[3:02] <jimbaker> but there are no other workarounds, other than to call gc.collect()
[3:06] <Alex_Gaynor> that's a worse hack :)
[3:09] <jimbaker> Alex_Gaynor: exactly. only for some sort of testing. like __del__
[3:30] * juneau001 (~juneau@pool-72-69-204-203.chi01.dsl-w.verizon.net) has joined #jython
[3:56] * Alex_Gaynor (~alex_gayn@ahwahnee-71.dynamic2.rpi.edu) has left #jython
[4:11] * jcp (~jw@bzflag/contributor/javawizard2539) Quit (Excess Flood)
[4:12] * jcp (~jw@bzflag/contributor/javawizard2539) has joined #jython
[4:13] * groves (~groves@nat.earth.threerings.net) Quit (Ping timeout: 245 seconds)
[4:45] * juneau001 (~juneau@pool-72-69-204-203.chi01.dsl-w.verizon.net) Quit (Quit: juneau001)
[5:20] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 240 seconds)
[5:24] * yacc (~andreas@84.113.164.165) Quit (Ping timeout: 240 seconds)
[5:24] * yacc (~andreas@84.113.164.165) has joined #jython
[5:42] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) has joined #jython
[5:46] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Ping timeout: 272 seconds)
[5:52] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[7:19] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) Quit (Ping timeout: 240 seconds)
[7:28] * raymondh (~raymond@76.89.181.64) Quit (Quit: Nettalk6 - www.ntalk.de)
[8:07] * thobe (~Adium@c83-249-247-186.bredband.comhem.se) Quit (Quit: Leaving.)
[8:26] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) has joined #jython
[8:27] * thobe (~Adium@212-162-171-110.skbbip.com) has joined #jython
[8:39] * groves (~groves@2002:47cc:b55b:0:221:e9ff:fee5:eac1) has joined #jython
[8:39] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) has joined #jython
[8:43] * seberg (~sebastian@89.204.153.14) has joined #jython
[9:11] * groves (~groves@2002:47cc:b55b:0:221:e9ff:fee5:eac1) Quit (Ping timeout: 260 seconds)
[9:53] * Imek (~joe@host-195-188-251-108.reversezone.co.uk) has joined #jython
[10:33] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) has joined #jython
[10:48] * seberg (~sebastian@89.204.153.14) Quit (Quit: Ex-Chat)
[10:49] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[10:55] * adiroiban (~adiroiban@89.137.108.176) has joined #jython
[11:54] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 240 seconds)
[12:05] * lmek (~joe@host-195-188-251-108.reversezone.co.uk) has joined #jython
[12:08] * Imek (~joe@host-195-188-251-108.reversezone.co.uk) Quit (Ping timeout: 255 seconds)
[12:09] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[12:09] * juneau001 (~juneau@FESS-116326.dhcp.fnal.gov) has joined #jython
[12:12] * lmek (~joe@host-195-188-251-108.reversezone.co.uk) Quit (Quit: Bye)
[12:39] * seberg (~sebastian@134.76.218.194) has joined #jython
[12:42] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 240 seconds)
[12:45] * Taggnostr (~quassel@dyn57-495.yok.fi) Quit (Remote host closed the connection)
[12:45] * Taggnostr (~quassel@dyn57-495.yok.fi) has joined #jython
[13:11] * stakkars (~tismer@ip-178-203-81-220.unitymediagroup.de) has joined #jython
[13:17] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Ping timeout: 265 seconds)
[13:18] * thobe (~Adium@212-162-171-110.skbbip.com) has joined #jython
[13:25] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Read error: Connection reset by peer)
[13:25] * thobe (~Adium@212-162-171-110.skbbip.com) has joined #jython
[13:43] <shanka> hi all, I'm trying to run a test case on the jython tree
[13:43] <shanka> the test case passes in the verbose mode
[13:43] * thobe1 (~Adium@212-162-171-110.skbbip.com) has joined #jython
[13:43] * thobe (~Adium@212-162-171-110.skbbip.com) Quit (Read error: Connection reset by peer)
[13:44] <shanka> (i.e. when i do: ../Lib/test/regrtest.py -v test_pbcvm) with the usual warning that stdout is not compared
[13:44] <shanka> but when i run it in normal mode (non-verbose), it fails to import the module diffLib
[13:44] <shanka> the module is right there in the Lib folder
[13:45] <shanka> any pointers on how to debug?
[13:47] <shanka> nevermind, i fixed it. I added the path to lib folder to sys.path
[13:47] <shanka> sorry for the noise
[13:50] <Oti> shanka - no problem
[14:05] <shanka> jimbaker: Hi. I've got the execnet working. I've also completed (hopefully) the enum translation.
[14:07] <shanka> jimbaker: The two previous test cases that were present (test_types and test_exceptions) work fine. when i try to run pcbvm on the whole regrtest suite, I have some issues with it.
[14:07] <shanka> some programs seem to require user input. I don't know how they are handled in the original test suite
[14:13] <pr3d4t0r> Hoi.
[14:38] * jcp (~jw@bzflag/contributor/javawizard2539) Quit (Quit: Later)
[14:42] * jcp (~jw@bzflag/contributor/javawizard2539) has joined #jython
[15:11] * lucian_ (~lucian@78-86-217-168.zone2.bethere.co.uk) has joined #jython
[15:38] * seberg (~sebastian@134.76.218.194) Quit (Quit: Ex-Chat)
[16:05] <jimbaker> shanka: sounds great. probably the next thing you should try is pystone since it's a somewhat reasonable test of the vm's dispatch loop
[16:06] <jimbaker> re regrtest - definitely there are "interactive" pieces, but it should all be automated. maybe paste something in our pastebin?
[16:21] * jbaker (~jimbaker@c-24-8-39-78.hsd1.co.comcast.net) has joined #jython
[16:21] * jimbaker (~jimbaker@c-24-8-39-78.hsd1.co.comcast.net) Quit (Read error: Connection reset by peer)
[16:21] * jbaker is now known as jimbaker
[16:40] * gqlewis (~gqlewis@h242.94.82.166.dynamic.ip.windstream.net) has joined #jython
[16:41] <shanka> jimbaker: here is the test case itself http://pylonshq.com/pasties/da38589bbcb551a9b760378030fb9f03
[16:41] <shanka> and here is the output: http://pylonshq.com/pasties/2852f0368674d2b2af0df9d9b3b85d66
[16:41] <shanka> jimbaker: yes i'll try pystone today
[16:42] * enebo (~enebo@184-97-205-152.mpls.qwest.net) has joined #jython
[16:43] * gqlewis (~gqlewis@h242.94.82.166.dynamic.ip.windstream.net) Quit (Client Quit)
[16:45] <jimbaker> shanka: that looks like a problem in setting up sys state. in all likelihood, it's because you have some sort of context mgmt problem. (to get the sys state, it's something like frame -> thread state -> sys state)
[16:48] <shanka> jimbaker: thanks for the pointer, i'll look into it later today. Have to rush to a class now :)
[16:56] * lopex (lopex@chello089076044027.chello.pl) has joined #jython
[17:02] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Read error: Connection reset by peer)
[17:02] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[17:34] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[17:43] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) Quit (Ping timeout: 272 seconds)
[17:44] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) Quit (Quit: jabley)
[17:46] * thobe1 (~Adium@212-162-171-110.skbbip.com) Quit (Quit: Leaving.)
[17:46] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) Quit (Ping timeout: 240 seconds)
[17:51] * Oti (5390f2dc@gateway/web/freenode/ip.83.144.242.220) Quit (Quit: Page closed)
[18:08] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 240 seconds)
[18:24] * thobe (~Adium@83.249.247.186) has joined #jython
[18:32] * fwierzbicki (~frank@c-69-181-229-66.hsd1.ca.comcast.net) has joined #jython
[18:39] * Imek (~joe@host-195-188-251-108.reversezone.co.uk) has joined #jython
[18:43] * headius (~headius@216-250-174-225.static.iphouse.net) has joined #jython
[18:55] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[19:14] * Oti (~ohumbel@adsl-89-217-202-198.adslplus.ch) has joined #jython
[19:16] * enebo (~enebo@184-97-205-152.mpls.qwest.net) Quit (Quit: enebo)
[19:19] * juneau001 (~juneau@FESS-116326.dhcp.fnal.gov) Quit (Quit: juneau001)
[19:36] * fwierzbicki (~frank@c-69-181-229-66.hsd1.ca.comcast.net) Quit (Ping timeout: 264 seconds)
[19:52] * groves (~groves@nat.earth.threerings.net) has joined #jython
[20:11] * lucian_ (~lucian@78-86-217-168.zone2.bethere.co.uk) Quit (Remote host closed the connection)
[20:14] * apexi200sx (~bhicking@cpc2-salf4-0-0-cust701.10-2.cable.virginmedia.com) has joined #jython
[20:25] * shanka (~shashank@c-98-245-87-8.hsd1.co.comcast.net) has joined #jython
[20:29] * lucian_ (~lucian@78-86-217-168.zone2.bethere.co.uk) has joined #jython
[20:34] * fwierzbicki (~frank@99-106-170-105.lightspeed.sntcca.sbcglobal.net) has joined #jython
[20:35] * apexi200sx (~bhicking@cpc2-salf4-0-0-cust701.10-2.cable.virginmedia.com) Quit (Read error: Connection reset by peer)
[20:42] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[20:46] * MarderIII (~marderii@enneman.demon.nl) has joined #jython
[20:55] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) Quit (Ping timeout: 245 seconds)
[20:56] * jabley (~jabley@cpc1-farn4-0-0-cust318.6-2.cable.virginmedia.com) has joined #jython
[20:56] * MarderIII (~marderii@enneman.demon.nl) Quit (Quit: leaving)
[20:57] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Read error: Connection reset by peer)
[20:57] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[21:22] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Ping timeout: 240 seconds)
[21:23] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[21:23] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Read error: Connection reset by peer)
[21:24] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) has joined #jython
[21:25] * lolsuper_ (~super_@unaffiliated/lolsuper-/x-9881387) Quit (Read error: Connection reset by peer)
[21:45] * Imek (~joe@host-195-188-251-108.reversezone.co.uk) Quit (Quit: Bye)
[22:18] * luckman212 (~quassel@pool-96-246-172-198.nwrknj.fios.verizon.net) has joined #jython
[22:40] * Oti (~ohumbel@adsl-89-217-202-198.adslplus.ch) Quit (Quit: Oti)
[22:48] * jimbaker (~jimbaker@c-24-8-39-78.hsd1.co.comcast.net) Quit (Quit: jimbaker)
[22:56] * headius (~headius@216-250-174-225.static.iphouse.net) Quit (Quit: headius)
[23:01] * stakkars_ (~tismer@ip-178-203-81-220.unitymediagroup.de) has joined #jython
[23:01] * stakkars (~tismer@ip-178-203-81-220.unitymediagroup.de) Quit (Read error: Connection reset by peer)
[23:02] * stakkars_ is now known as stakkars
[23:02] * luckman212_b (luckman212@pool-96-246-172-198.nwrknj.fios.verizon.net) has joined #jython
[23:03] * luckman212_b (luckman212@pool-96-246-172-198.nwrknj.fios.verizon.net) Quit (Client Quit)
[23:04] * luckman212_b (luckman212@pool-96-246-172-198.nwrknj.fios.verizon.net) has joined #jython
[23:11] * luckman212_b (luckman212@pool-96-246-172-198.nwrknj.fios.verizon.net) Quit (Quit: luckman212_b)
[23:47] * lucian_ (~lucian@78-86-217-168.zone2.bethere.co.uk) Quit (Remote host closed the connection)

Index

These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).