Timestamps are in GMT/BST.
[3:09] <jimbaker> so requests (and for its dependency, pip trunk) requires implement nonblocking ssl sockets. this is going to be a bit more work, because the builtin ssl sockets from java are blocking only
[3:09] <jimbaker> it is possible to use SSLEngine however to layer ssl support on top of arbitrary sockets
[3:10] <jimbaker> http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLEngine.html
[3:10] <jimbaker> so this is what will have to be done
[3:11] <jimbaker> so much for my feeling that we are almost there for beta 2 :( anyway, hopefully we can still get this done in nov
[3:12] <jimbaker> the good thing is, we will get nonblocking ssl sockets support :)
[3:56] * sinistersnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) has joined #jython
[7:43] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[8:35] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 240 seconds)
[10:18] * daenney (~daenney@daenney.net) has joined #jython
[11:54] * truk77 (~kurt@pool-173-73-24-197.washdc.fios.verizon.net) Quit (Ping timeout: 248 seconds)
[11:56] * truk77 (~kurt@pool-71-191-95-144.washdc.fios.verizon.net) has joined #jython
[13:39] * bru`` (~bruno`@AMontsouris-652-1-2-200.w92-163.abo.wanadoo.fr) Quit (Ping timeout: 272 seconds)
[14:17] * bru` (~bruno`@AMontsouris-652-1-82-148.w92-163.abo.wanadoo.fr) has joined #jython
[15:37] <daenney> jimbaker: Sorry for my absence as of late, life got in the wy
[15:37] <daenney> jimbaker: I'm still working on redoing the 'startup' script but I don't think bash is actually feasible. I'm probably going to break half the functionality without even realising since there's no testing framework or whatever for that
[15:38] <daenney> jimbaker: Your idea of doing it pure python might be the better way out here
[15:39] <daenney> It would also greatly simplify a lot of crap since I'd have access to argparse, os.environ etc
[15:49] <peke> jimbaker: since `python -m pip` already works, i would assume `jython -m pip` works as soon as pip works in general.
[15:52] <peke> agronholm: afaik jython scripts are installed under JYTHON_HOME/bin and not to /usr/local/bin or similar as in cpython. since you are likely to have both of these locations in PATH, `pip` obvivously will use the one that's there first.
[15:55] <peke> the main problem is documenting how to use pip w/ jython. you cannot just say `pip install package` because that is very likely to install it under cpython. since you don't know where jython is installed, using something like `jython /path/to/pip install package` wouldn't be that good, but `jython -m pip install package` is pretty good.
[15:56] <agronholm> I don't have jython's bin directory in PATH
[15:56] <agronholm> so whenever I want to install something in jython, I execute pip from jython's bin explicitly
[15:57] <peke> jimbaker: what about including pip to jython? in my opinion having it there automatically, and being able to update it with `jython -m pip install pip` would be extremely convenient.
[15:58] <agronholm> that wouldn't update it, you need -U
[15:58] <agronholm> that said, +1
[16:00] <daenney> THere's a PEP out there for CPython to ship pip with the distribution too
[16:00] <peke> jimbaker: oh, you already wrote your plan is pep 453 complience. sweeeeet!!
[16:00] <daenney> Or well, not a PEP for CPython, a PEP
[16:00] <agronholm> what plan where
[16:08] <peke> agronholm: jimbaker wrote this a little time ago: """i will ensure that we have full PEP 453 compliance re including pip ... for beta 2"""
[16:09] <peke> and that pep 453 is that daenney just referred: http://www.python.org/dev/peps/pep-0453/
[16:11] <peke> unfortunately cpython 2.7 won't get this goodness, but with it installing pip is mainly an issue on windows. elsewhere something like `apt-get install python-pip` or `wget http://.../get-pip.py && python get-pip.py` will do the trick.
[16:12] <peke> and cpython folks are planning to resolve this windows issue by having a separate installer for pip (bundled with dependencies). and later perhaps separate cpython 2.7 installer w/ pip and windows launcher.
[16:17] <peke> in my opinion jython 2.7 could, and should, support pep 453 even if cpython 2.7 won't. i understand cpython maintainers don't want to add new stuff like this in a minor release, but with jython that's not an issue because there's no jython 2.7 final yet. earlier versions of jython have also been pretty liberal in including good stuff from newer python versions. practicality definitely beats purity here.
[16:19] <agronholm> yup, I see no reason not to include pip w/ dependencies in jython 2.7
[16:24] <daenney> It makes stuff easier if you get a full 'stack'
[16:25] <daenney> It's also a bit weird that Python doesn't bundle its own package manager anyway, just about every language does. Clojure takes that to the extreme were Leiningen is actually used to bootstrap the whole thing :)
[16:26] <daenney> It's awesome being able to go 'lein run' and tah-dah, stuff done
[16:51] * sinistersnare is now known as sinsnare|away
[17:00] <topi`> jimbaker: I tried '''with closing(urllib2.urlopen(url)):''' but looking at the consumption of tomcat's FDs it seems that this does not work as expected, FDs keep leaking
[17:00] <topi`> I've limited the amount of possible code paths and either it is this or then my use of jyjdbc which is leaking file descriptors.
[17:04] <topi`> I'm beginning to doubt whether the socket code in jython has a working .close() at all
[17:12] * sinsnare|away is now known as sinistersnare
[17:52] * Oti (~ohumbel@adsl-89-217-97-146.adslplus.ch) Quit (Quit: Oti)
[17:57] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[19:16] <topi`> now my problems are solved; my servlet uses java.net.URL everywhere to make http connections, instead of urllib2
[19:16] <topi`> the amount of open FDs is stable now.
[19:32] <sinistersnare> topi`: IIRC isnt java.net.URI better than j.n.URL?
[19:35] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[20:19] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) Quit (Read error: Operation timed out)
[20:33] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[21:16] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) has joined #jython
[21:16] <vIkSiT> hey jimbaker
[21:16] <vIkSiT> around for a quick question?
[21:16] <vIkSiT> AttributeError: 'module' object has no attribute 'cast' when running setup tools on jython-ssl
[21:18] <agronholm> traceback?
[21:18] <vIkSiT> https://gist.github.com/viksit/471d37b31439f83f0cfc
[21:18] <vIkSiT> yup, was just posting :)
[21:19] <agronholm> what's on line 13?
[21:19] <agronholm> of setup.py
[21:19] <agronholm> and by running setuptools, what do you mean
[21:19] <agronholm> oh, installing blist
[21:20] <vIkSiT> yep
[21:20] <vIkSiT> just a simple easy_install
[21:20] <agronholm> so what is on line 13 of blist's setup.py?
[21:20] <vIkSiT> fails during the packaging stage
[21:20] <vIkSiT> yep checking htat now
[21:20] <vIkSiT> damn
[21:20] <vIkSiT> iv = ctypes.cast(ctypes.pointer(dv), ctypes.POINTER(ctypes.c_uint64))
[21:21] <agronholm> ctypes
[21:21] <vIkSiT> sigh. yeah
[21:21] <vIkSiT> https://github.com/DanielStutzbach/blist/blob/master/setup.py
[21:21] <vIkSiT> is there something generic that I could do here, I wonder
[21:22] <agronholm> can't use ctypes from jython, at least for the time being
[21:22] <vIkSiT> right
[21:27] * Oti (~ohumbel@adsl-89-217-97-146.adslplus.ch) has joined #jython
[21:30] <daenney> Doesn't java have some blist-like you can use, instead of blist?
[21:30] <agronholm> what is blist
[21:31] <daenney> It's a more memory effective version of python lists/dicts
[21:32] <agronholm> you mean like array.array()?
[21:32] <daenney> It's pretty handy when you're dealing with serious size stuff
[21:32] <daenney> I have no idea what array.array does
[21:32] <agronholm> more efficient arrays than python's list/tuple
[21:32] <agronholm> you should read up on it :)
[21:33] <agronholm> it's part of the stdlib
[21:33] <daenney> Ah no, not like array.array
[21:33] <daenney> blist can contain different types, not limited to one type declared at creation time
[21:33] <agronholm> how is blist more efficient then
[21:34] <daenney> Have a read: https://github.com/DanielStutzbach/blist
[21:35] <agronholm> what's the downside then?
[21:35] <agronholm> greater memory consumption?
[21:37] <daenney> No clue.
[21:44] <vIkSiT> agronholm, daenney - well, my issue is different :)
[21:44] <vIkSiT> I have some existing code that uses a cassandra libarary, which is pure python EXCEPt that it depends on blist
[21:45] <vIkSiT> so now I'm trying to figure what I can do to a) remove the dependency or b) find a similar implementation of blist in java (And then modify the cassandra lib to use it)
[21:49] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 272 seconds)
[21:54] <vIkSiT> aha found a solution
[21:54] <vIkSiT> don't use easy_install, and put a try catch, fall back to frozenset.
[22:38] <vIkSiT> hmm
[22:38] <vIkSiT> so what about concurrent.futures?
[22:38] <vIkSiT> under jython?
[22:38] <vIkSiT> it seems to rely on multiprocessing
[22:54] <agronholm> works with threads
[23:05] <vIkSiT> agronholm, how so?
[23:06] <agronholm> um, you asked about concurrent.futures under jython
[23:06] <vIkSiT> agronholm, right - but, it imports multiprocessing?
[23:06] <vIkSiT> or am I doing the wrong thing installing it using jython?
[23:06] <agronholm> only if you use the process pool
[23:06] <agronholm> if you stick to using the thread pool, it won't import multiprocessing
[23:06] <vIkSiT> ah
[23:07] <agronholm> I redid the backport a couple months ago so it should be fresh with all the latest bugfixes that got to python 3.2
[23:07] <agronholm> I mean, the latest incarnation of it
[23:08] <vIkSiT> ah I see
[23:08] <vIkSiT> but
[23:08] <vIkSiT> concurrent/futures/__init__.py - import processPool
[23:08] <vIkSiT> so even if its never used, I'm getting an error..
[23:08] <agronholm> hrm
[23:09] <agronholm> it's been a while since I touched that code
[23:10] <vIkSiT> ah ok.
[23:10] <vIkSiT> hmm, I thought jython-ssl trunk contained the big data structures code
[23:10] <vIkSiT> java.lang.RuntimeException: java.lang.RuntimeException: Method code too large!
[23:10] <vIkSiT> agronholm, I went and removed that init call to processpool
[23:10] <vIkSiT> of course, now I'm stuck with some of the large collections issues :)
[23:10] <vIkSiT> Jython 2.7b1+ (default:83fb0f8d3c98, Oct 25 2013, 15:06:36)
[23:10] <agronholm> method code too large? that has nothing to do with collections
[23:11] * sinistersnare is now known as sinsnare|away
[23:11] <agronholm> it's a rare error that occurs when there is so much code in the method that it violates java's method size limits
[23:11] <vIkSiT> I see
[23:11] <agronholm> reportlab has been known to hit this problem
[23:11] <vIkSiT> I thought jimbaker had a fix for this..
[23:11] <agronholm> yes
[23:11] <agronholm> unfortunately it's rather elaborate
[23:11] <daenney> requests has that issue too I seem to recall
[23:12] <agronholm> and very much work in progress
[23:12] <agronholm> daenney: really...?
[23:12] <daenney> agronholm: Yeah. We were looking at two things, pip's unicode woo-waa that caused it to not work on Jython and requests
[23:13] <daenney> I thought it was the Method code too large one, not entirely sure anymore
[23:13] <vIkSiT> hmm
[23:13] <vIkSiT> this is hitting thr 64k java limit?
[23:15] <agronholm> vIkSiT: catch
[23:15] <daenney> I have absolutely no idea
[23:16] <daenney> I just know it happens sometimes. As far as the Java internals go, I'm clueless
[23:16] <agronholm> vIkSiT: where'd you go?
[23:18] <vIkSiT> agronholm, here
[23:18] <agronholm> still waiting for you to accept the file transfer
[23:18] <vIkSiT> done
[23:18] <agronholm> see if that works better
[23:18] <vIkSiT> agronholm, thanks - whats the difference?
[23:18] <agronholm> processpool is imported conditionally
[23:19] <vIkSiT> sweet
[23:20] <vIkSiT> thanks! I'm trying it out now
[23:23] <vIkSiT> works
[23:49] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 272 seconds)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).