#jython IRC Log


IRC Log for 2014-08-19

Timestamps are in GMT/BST.

[0:15] * xemdetia (xemdetia@nat/ibm/x-vxzvjftgcmbwvbdg) has joined #jython
[1:14] * cjwelborn (cjwelborn@unaffiliated/cjwelborn) has left #jython
[1:59] * xemdetia (xemdetia@nat/ibm/x-vxzvjftgcmbwvbdg) Quit (Read error: Connection reset by peer)
[2:10] * xemdetia (xemdetia@nat/ibm/x-aepfgydffyrxjnht) has joined #jython
[3:12] * xemdetia (xemdetia@nat/ibm/x-aepfgydffyrxjnht) Quit (Ping timeout: 250 seconds)
[3:25] * gthank (~gthank@unaffiliated/gthank) Quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz???)
[4:51] * Oti (~ohumbel@adsl-178-39-175-168.adslplus.ch) Quit (Quit: Oti)
[5:34] * jorgew (sid36089@gateway/web/irccloud.com/x-soquvidnpbxumrqw) Quit (Ping timeout: 260 seconds)
[5:37] * jorgew (sid36089@gateway/web/irccloud.com/x-ctrprpumqjlnvjzf) has joined #jython
[9:14] * agronholm (~agronholm@2001:1bc8:102:6f29:197b:2c73:eb70:5024) Quit (Ping timeout: 260 seconds)
[9:17] * agronholm (~agronholm@2001:1bc8:102:6f29:ed9d:3487:3941:d41a) has joined #jython
[9:17] * ChanServ sets mode +o agronholm
[12:00] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 255 seconds)
[12:08] * xemdetia (xemdetia@nat/ibm/x-tsuergndfeqvruwz) has joined #jython
[12:34] * gthank (~gthank@unaffiliated/gthank) has joined #jython
[14:14] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[14:50] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[15:13] <jimbaker> paolo, i think it's a straightforward task to write a sqlite3 wrapper. this is pretty critical for ipython support fwiw
[15:58] <paolo> jimbaker: i solved using jyjdbc and http://www.xerial.org/trac/Xerial/wiki/SQLiteJDBC, for now it works pretty well but be able to type import sqlite3 would be better ;)
[15:59] <jimbaker> paolo, i think that's a very good approach
[15:59] <paolo> btw, i'm in the nosy list of http://bugs.jython.org/issue1682864 and will see what's going on with that.
[16:00] * gthank (~gthank@unaffiliated/gthank) Quit (Read error: Connection reset by peer)
[16:00] <jimbaker> from what i remember, the only reason to use sqlite3 directly is (1) there's code that assumes this; (2) using some additional features like callbacks
[16:00] <paolo> and i'm using peewee (with python/sqlite3) to generate the raw sql queries for the cursor
[16:01] <paolo> your point (1) is the reason i'd need sqlite3 in the jython std library
[16:01] <jimbaker> paolo, right. it would be nice if this were not the case, but reality
[16:01] <paolo> (peewee does import sqlite3 directly)
[16:02] <jimbaker> so it looks like i had done some analysis per that bug, and xerial is the way to go, since it supports the (2) cases
[16:02] <jimbaker> (glad i write this stuff done somewhere :)
[16:02] <jimbaker> down
[16:03] <paolo> would it worth to update the wiki saying to use jyjdbc instead of zxjdbc?
[16:04] <paolo> yesterday i was tempted to change the wiki with that
[16:06] <jimbaker> paolo, yes, i would do that
[16:06] <jimbaker> zxjdbc has not seen support, mostly because it lacks testing
[16:06] <jimbaker> and no testing means it's hard to make changes
[16:07] <paolo> jimbaker: agree. then i'll add a note on the wiki
[17:10] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Read error: Connection reset by peer)
[17:49] <agronholm> jimbaker: did you see my messages about the socket tests?
[17:50] <jimbaker> agronholm, i did not
[17:50] <jimbaker> i know we have some failures due to different ways networking can be set up. so want to fix, but failures are not interesting per se
[17:50] <agronholm> I'm seeing the same exceptions when running the socket tests as I did in the real app
[17:51] <jimbaker> ok, please tell me more
[17:51] <jimbaker> or point me to the earlier messages
[17:52] <agronholm> I just did "ant test" and when it came to the socket tests, I started seeing several of those exceptions
[17:52] <agronholm> in my real app, it was caused by trying to send() when a socket was being disconnected from the other end
[17:53] <agronholm> something's definitely off here
[17:53] <agronholm> on more thing -- enabling logging on the DEBUG level causes quite a lot of noise from the _socket module
[17:53] <agronholm> was that intentional?
[17:56] <jimbaker> agronholm, i should make that harder to enable
[17:56] <agronholm> okay
[17:56] <jimbaker> i will say that nearly every logging statement has proven to be useful for debugging socket lifecycle
[17:57] <jimbaker> so i need the spew
[17:57] <agronholm> right. but it's distracting when you're debugging something else
[17:57] <agronholm> I could just disable that logger but it shouldn't be talking at all unless asked to do so IMHO
[17:57] <jimbaker> yeah, understood. i will think about how to make harder to turn on. python's logging is not as useful as one would like
[17:58] <jimbaker> although i haven't spent too much time trying to understand its intricacies, to be honest
[17:59] <agronholm> I'm pretty familiar with how it works
[17:59] <agronholm> you can ask me :)
[17:59] <jimbaker> agronholm, feel free to make a commit :) i just want to have the ability to turn them on, much like the code change implied
[17:59] <jimbaker> with _debug() or whatever i called it
[18:00] <agronholm> yeah well if you isolate the logger from the root, that would do it
[18:00] <agronholm> disable propagation that is
[18:00] <jimbaker> agronholm, got it
[18:01] <jimbaker> agronholm, re the specific case you mention, which test is failing? not in test_socket right, some other test?
[18:01] <agronholm> I will rerun the tests
[18:02] <jimbaker> agronholm, cool. i have been very happy with how socket-reboot has worked out, but it definitely has uncovered many many corner cases that i was not aware of until doing this work
[18:03] <jimbaker> in any event, the recent discussion on fixing __del__ support should also help in other aspects of lifecycle
[18:03] <agronholm> I only joined the jython-dev mailing list today
[18:10] <pjenvey> this just occured to me so I wrote it down, probably nothing you didn't already know =] http://bugs.jython.org/msg8931
[18:13] <jimbaker> pjenvey, that's an interesting possibility
[18:14] <jimbaker> certainly would be a good test of cffi support for jython. it's something i was planning on looking at once we got a release candidate out
[18:15] <jimbaker> pjenvey, specifically this vaporware project - https://github.com/jythontools/jiffy
[18:15] <pjenvey> =]
[18:15] <pjenvey> if only it could be implemented in a jiffy
[18:16] <pjenvey> it shouldn't be too bad though, but it'll def. take some work
[18:20] <agronholm> jimbaker: http://bpaste.net/show/ncFRikEF6yvXIVARCWZU/
[18:20] <agronholm> search for IOException
[18:20] <agronholm> there's only one though
[18:20] <jimbaker> pjenvey, yeah, that's why i pushed it out accordinly
[18:21] <jimbaker> agronholm, that makes sense. did you narrow it down to a specific test?
[18:21] <paolo> wiki admin: http://sourceforge.net/p/jython/mailman/message/32736457/
[18:21] <agronholm> jimbaker: not yet, I just got the test suite results
[18:22] <jimbaker> agronholm, sounds good
[18:22] <jimbaker> paolo, cool, that should occur shortly (i hope). maybe we can have some other people be designated as wiki admins as well
[18:23] <agronholm> jimbaker: http://bpaste.net/show/L644vpYhgJnDSx7x61AZ/
[18:24] <agronholm> fwiw, the error translates to "Remote side closed connection"
[18:24] <paolo> jimbaker: no worries, i'll wait the moment :)
[18:25] <jimbaker> agronholm, thanks! so errno.ECONNRESET?
[18:25] <jimbaker> i assume that's the error you want, vs some other behavior...
[18:26] <agronholm> that warning shouldn't be there
[18:26] <jimbaker> agronholm, right. we want to provide python-specific errors, not netty default behaviors that we haven't overridden
[18:26] <agronholm> the thing is, the test passes
[18:27] <agronholm> but it spits out a warning anyway
[18:29] <agronholm> java.io.IOException: Connection reset by peer
[18:29] <agronholm> that's the English version
[18:29] <jimbaker> agronholm, right
[18:42] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[18:43] <jimbaker> anyway, i wonder if the correct solution here is to not to call ctx.fireExceptionCaught(cause) - basically we should stop with this exception in the exceptionCaught handler
[18:43] <jimbaker> i have to revisit - this is code that i wrote sometime ago, so i'm not certain why i wanted to propagate the exception, or if that's just not thinking this problem through
[18:46] <jimbaker> biab
[20:11] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 240 seconds)
[20:41] <agronholm> this is awkward
[20:42] <agronholm> after upgrading to jython 2.7, I started seeing an exception in my app that wasn't there before
[20:42] <agronholm> turns out I was relying on erroneous defaultdict behavior in jython 2.5
[20:42] <xemdetia> that's the worst :(
[20:44] <jimbaker> agronholm, yeah, sorry about the error in defaultdict, that was my coding mistake
[20:44] <jimbaker> at least it's now fixed as of the latest 2.7
[20:45] <agronholm> jimbaker: well it works correctly in 2.7, no apologies necessary :)
[20:50] <agronholm> but let's not forget to fix that sock.recv() bug
[20:50] <agronholm> the one that returns None instead of b''
[20:50] <agronholm> when the socket has been disconnected
[20:57] * mike_af (~mike_af@unaffiliated/mike-af/x-5454762) has joined #jython
[21:25] <jimbaker> agronholm, looks like i have a FIXME for this in the code - seems like it's a bit more complicated than i originally thought in terms of such transitions
[21:25] <jimbaker> but still easy enough to accommodate
[21:25] <jimbaker> (besides being the "correct" behavior!)
[21:25] <agronholm> not sure what you mean, but ok :)
[21:25] <jimbaker> agronholm, the relevant comment: # FIXME FIXME C socket semantics return a '' after the first EAGAIN (not certain if this gets reset or not)
[21:26] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[21:26] <agronholm> right
[21:27] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Client Quit)
[21:30] <paolo> what do you guys use for continuous integration? the jython book suggests hudson (now jenkins), is it still a valid suggestion?
[21:39] <jimbaker> paolo, yes, although we recently started work on getting travis-ci going against jython
[21:39] <jimbaker> trunk
[21:39] <jimbaker> really any CI system should work
[21:40] <jimbaker> more a question of how it integrates w/ versioning
[21:40] <jimbaker> (and ideally pull requests)
[21:41] <paolo> thanks, i'll check some hosted jenkins or travis (?????????)
[21:45] <paolo> jimbaker: the book says that hudson needs a plugin, so i guess not any CI system can work but the ones for which the plugin exists
[21:45] <jimbaker> paolo, so basically jenkins is only useful w/ plugins...
[21:59] * xemdetia (xemdetia@nat/ibm/x-tsuergndfeqvruwz) Quit (Ping timeout: 245 seconds)
[22:15] * mike_af (~mike_af@unaffiliated/mike-af/x-5454762) Quit (Quit: Leaving...)
[23:53] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython


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