#jython IRC Log


IRC Log for 2013-09-19

Timestamps are in GMT/BST.

[0:25] * lheuer1 (~Adium@f049227141.adsl.alicedsl.de) has joined #jython
[0:27] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 264 seconds)
[1:13] * lheuer1 (~Adium@f049227141.adsl.alicedsl.de) Quit (Ping timeout: 268 seconds)
[1:15] * lheuer (~Adium@f048164123.adsl.alicedsl.de) has joined #jython
[1:15] * lheuer (~Adium@f048164123.adsl.alicedsl.de) Quit (Changing host)
[1:15] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[1:20] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 248 seconds)
[1:23] * lheuer (~Adium@f048224022.adsl.alicedsl.de) has joined #jython
[1:23] * lheuer (~Adium@f048224022.adsl.alicedsl.de) Quit (Changing host)
[1:23] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[1:29] * [Arfreve1] (~Arfrever@minotaur.apache.org) Quit (Quit: leaving)
[1:30] * [Arfrever] (~Arfrever@apache/committer/Arfrever) has joined #jython
[3:25] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)
[4:40] * thereisnospoon_ (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 245 seconds)
[5:19] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[5:40] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 248 seconds)
[5:41] * mcurve (~quassel@pop.nakinasystems.com) Quit (Ping timeout: 240 seconds)
[5:50] * lheuer (~Adium@f048224022.adsl.alicedsl.de) has joined #jython
[5:50] * lheuer (~Adium@f048224022.adsl.alicedsl.de) Quit (Changing host)
[5:50] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[5:53] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[5:54] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[5:59] * mcurve (~quassel@pop.nakinasystems.com) Quit (Ping timeout: 248 seconds)
[6:15] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[6:18] * mcurve (~quassel@pop.nakinasystems.com) Quit (Read error: Operation timed out)
[6:24] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[6:59] * supersven_ (~sven@port-30049.pppoe.wtnet.de) has joined #jython
[7:03] * supersven (~sven@port-22317.pppoe.wtnet.de) Quit (Ping timeout: 248 seconds)
[7:22] * mcurve (~quassel@pop.nakinasystems.com) Quit (Quit: No Ping reply in 180 seconds.)
[7:23] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[7:27] * mcurve (~quassel@pop.nakinasystems.com) Quit (Ping timeout: 260 seconds)
[7:30] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[7:32] * kral|off is now known as kral
[7:57] * mcurve (~quassel@pop.nakinasystems.com) Quit (Ping timeout: 245 seconds)
[8:02] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[8:08] * mcurve_ (~quassel@pop.nakinasystems.com) has joined #jython
[8:09] * mcurve (~quassel@pop.nakinasystems.com) Quit (Read error: Connection reset by peer)
[8:21] * mcurve_ (~quassel@pop.nakinasystems.com) Quit (Read error: Connection reset by peer)
[8:21] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[8:33] * mcurve (~quassel@pop.nakinasystems.com) Quit (Ping timeout: 264 seconds)
[8:38] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[8:49] * purplefox (~purplefox@88-105-150-78.dynamic.dsl.as9105.com) Quit (Quit: Leaving)
[9:00] <daenney> jimbaker: http://www.ibm.com/developerworks/java/library/j-multitenant-java/index.html
[11:06] * kral is now known as kral|off
[13:49] * kral|off is now known as kral
[16:02] * kral is now known as kral|off
[16:02] * purplefox (~purplefox@88-105-150-78.dynamic.dsl.as9105.com) has joined #jython
[16:25] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[16:26] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[16:27] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Client Quit)
[17:09] <jimbaker> daenney, wow, this is really cool
[17:12] <jimbaker> daenney, also this is something that would work much better with jython compared to jruby since all but the simplest scripts will be ahead-of-time compiled, either just being cached or compiled through the normal compileall (as used by setup.py or as part of the stdlib install)
[17:13] <jimbaker> there are also some artifacts that could also see great perf, w/o too much adjustment. in particular, i'm thinking of the jar scanner cache
[17:14] <jimbaker> anyway, this is great example of the lazy web
[17:15] <whg> Do you guys know of any unitest2 breakage?
[17:15] <jimbaker> one more thing: we will need to think about jnr-posix in this context
[17:16] <jimbaker> whg, i'm pretty certain i used uniitest2 implicitly when i was testing the mock package recently on jython
[17:16] <jimbaker> it worked fine for that purpose
[17:18] <whg> Somebody in #python is reporting that the test discovery stuff does a split on the name of the class file in an attempt to find the name of the original source file so it can scan for test methods
[17:18] <whg> The exact report was "TestLoader#_find_tests() does splitext() to go from .pyc to the base filename"
[17:19] <whg> Is there some sort of non-hacktastical way to reverse from a class file to the relevant source file?
[17:21] <jimbaker> whg, unfortunate
[17:21] <whg> And apparently there's a patch to address the issue, but it's a year old and unapplied
[17:22] <jimbaker> whg, yeah, that needs to be addressed
[17:23] <whg> jimbaker: http://hg.python.org/unittest2/rev/2b6411b9a838
[17:23] <whg> jimbaker: The whole approach to figuring out the source file by doing string hacks to the name of the class file seems??? unfortunate, but I'm not versed enough in the guts of Python to say if there's an alternative
[17:23] <jimbaker> whg, supposedly i have the power to apply this commit
[17:24] <jimbaker> i will ask michael about it - he's very friendly to jython
[17:24] <whg> jimbaker: Well it's in mercurial, there just doesn't appear to have been a release lately
[17:24] <whg> :-/
[17:24] <whg> jimbaker: Also, I wonder how this squares w/ IronPython
[17:25] <jimbaker> well, it should be ironpython aware. to be honest, i don't know really any details about ironpython
[17:26] <jimbaker> i know they have a very different compilation strategy
[17:27] <whg> jimbaker: I basically only know it exists, it just seems likely that any implementation that runs on a different, multi-language VM would be prone to such issues.
[17:28] <jimbaker> whg, btw, the jython aware piece is probably best. there should be something in pypi to help here. someone should write this :)
[17:29] <jimbaker> _jython_aware_splitext(path) may be hackish, but it's the fastest solution i can think of in python
[17:30] <whg> jimbaker: A lib to reverse classfile names to sourcefile names?
[17:30] <jimbaker> whg, no something more general purpose
[17:31] <jimbaker> collects all required stuff in place
[17:31] <jimbaker> https://pypi.python.org/pypi/six
[17:32] <jimbaker> is the sort of thing i have in mind
[17:32] <jimbaker> so you want to put naked surrogates in your file (pip?) don't, use this library
[17:32] <whg> That could get??? hairy
[17:32] <whg> Would be highly interesting/useful tho
[17:32] <jimbaker> well, solving it in one place is better than fixing multiple places
[17:32] <whg> jimbaker: True
[17:33] <jimbaker> the reason pip uses naked surrogates in unicode literals/re is simple
[17:33] <whg> But I can copy-paste the one-function lib and get it up there :-)
[17:33] <jimbaker> it makes the code faster
[17:33] <jimbaker> whg, so i'm suggesting we register a package, and starting putting stuff in there
[17:34] <jimbaker> something simple enough that a package like pip can directly incorporate, as it does in its vendor tree
[17:35] <jimbaker> for all i know, this exists, perhaps just for pypy or ironpython
[17:35] <whg> I don't mind helping with something like that, assuming I can get clearance from my manager
[17:35] <jimbaker> whg, fantastic!
[17:35] <jimbaker> in my pip/requests work, i will have some good diffs that we can put in there too
[17:36] <whg> jimbaker: Fair warning, I just got *another* new manager, so that might not be as quick as I might like.
[17:36] <whg> On a positive note, didn't IBM sponsor or contribute to Jython at one point?
[17:36] <jimbaker> whg, i don't believe they have sponsored jython, but we have worked with them on codefixes in the past
[17:37] <jimbaker> given the importance of jython in some of their products
[17:37] <whg> Good. That means there's a fair chance it isn't on the internal blacklist
[17:37] <whg> Unlike, say, Postgres (sob)
[17:37] <jimbaker> yeah, i would hope not
[17:38] <jimbaker> i can dig up the last ibm product we helped do a bugfix for
[17:39] <whg> Just found it. It's approved(ish)
[17:41] <jimbaker> whg, fantastic(ish)
[17:43] <whg> jimbaker: Heh. There's now 5 different levels of approval. It's in one of the friendlier ones.
[17:43] <jimbaker> whg, i'm perfectly fine w/ ibm not using jython in a realtime system
[17:44] <whg> Well there goes my plans!
[17:44] <jimbaker> although curiously enough, jython is used by lockheed martin to assemble the avionics package for the joint strike fighter
[17:45] <jimbaker> in terms of the metadata on how a given avionics component communicates, in realtime, etc, etc, with other components
[17:45] <daenney> You have to get through 5 levels of approval to be allowed to work on an open source project?
[17:46] <jimbaker> i also know jython 2.5.x is used to build BMWs
[17:46] <jimbaker> so it coordinates the assembly line in some way
[17:47] <jimbaker> but is not part of the actual control loop. just to make that clear
[17:48] <daenney> jimbaker: Speaking of the JSF: http://translate.google.com/translate?sl=nl&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.speld.nl%2F2012%2F07%2F09%2Fintertoys-ziet-af-van-verkoop-jsf%2F (note that De Speld is a satiric Dutch online publication)
[17:50] <whg> daenney: No, if I want to do something on my own time, I just have to ask my manager. If it doesn't compete w/ an IBM interest, it's usually a rubber-stamp.
[17:51] <whg> daenney: To **USE** FOSS packages, it's a little more complicated.
[17:52] <whg> daenney: IBM basically vets the entire history of the project on top of the license, in an attempt to make sure that nobody can hold IBM responsible for copyright infringement or force the source code to be released because of some GPL-inspired bit of license chicanery
[17:52] <jimbaker> daenney, yeah, i don't know about the JSF; but the presentation was a popular session at pycon a few years ago
[17:52] <whg> (like slipping GPL'd code into a BSD project and not telling anybody, which effectively makes the project GPL instead of BSD)
[17:53] <whg> daenney: To save time/effort/money, they do that groundwork on popular packages and categorize them for what it's OK to use
[17:53] <jimbaker> whg, yeah, we are extraordinarily careful in core python about that sort of stuff
[17:53] <jimbaker> and that extends to jython of course
[17:53] <daenney> whg: Aha, I see. Sounds a bit excessive to me but I guess they have good reason to do so
[17:54] <whg> jimbaker: It's entirely understandable, but a **MASSIVE** pain in my neck when I work on a SaaS product and they want us to be keeping up with current web trends
[17:54] <whg> There's a new JavaScript lib every other day
[17:55] <whg> jimbaker: I don't have access to the complete DB, Jython up through 2.5.3 is in one of the ones that basically say "double-check, but you're probably golden"
[18:05] <jimbaker> whg, especially with such books as http://www.amazon.com/WebSphere-Application-Server-Administration-Jython/dp/0137009526/, written by IBM employees
[18:08] <whg> Yeah. I thought I had seen some official involvement from IBM at some point, but couldn't remember any details.
[18:08] <whg> jimbaker: Speaking of books, are you updating yours soon?
[18:08] <jimbaker> whg, only after 2.7 is out :)
[18:08] <whg> jimbaker: How many of you are working on that?
[18:09] <whg> I notice you're the most active member of this channel by far, at least when I'm around
[18:09] <jimbaker> whg, i like to think of the jython development cast as a rotating set of characters
[18:10] <whg> Wonder if I could get IBM to let me contribute on their dime from time to time.
[18:10] <jimbaker> so last year, it was mostly fwierzbicki, this year jeff allen and then recently i have been very active
[18:11] <jimbaker> so jython is something we plan to use more of at rackspace, and that's why i now suddenly have a lot of time to contribute and be active
[18:13] <whg> jimbaker: Is that related to the OpenStack work, in any way?
[18:13] <jimbaker> whg, so it certainly would make a lot of sense for IBM to do this. there are many companies that use jython, that could benefit from continued investment
[18:13] <jimbaker> whg, it's related. i'm working on an internal project to support better autoscaling of rackspace cloud
[18:14] <whg> jimbaker: I know IBM's OpenStack team actually slings a lot of Python, so I was curious.
[18:15] <jimbaker> whg, so we use storm to collate in realtime (the usual soft defn for this sort of thing) data feeds with predictive modeling to drive scaling changes
[18:15] <jimbaker> whg, given that openstack is written in python, that would be generally the first choice :)
[18:16] <jimbaker> one certainly integrates w/ openstack components through REST, but customization is certainly important for large scale openstack
[18:17] <jimbaker> i would like to see openstack work well on jython. unfortunately, the use of greenlets means we would need good coroutine support in the jvm. there's experimental work for this, but nothing has come close to getting in
[18:18] <whg> jimbaker: Greenlets as in gevent? I'm not overly familiar with OpenStack on an implementation level.
[18:19] <jimbaker> https://github.com/jruby/jruby/wiki/PerformanceTuning#enable-coroutine-based-fibers
[18:19] <jimbaker> eventlet, in the case of openstack
[18:19] <jimbaker> http://docs.openstack.org/developer/nova/devref/threading.html
[18:24] <whg> jimbaker: Fancy
[18:25] <jimbaker> similar stuff could be done in jython as jruby. we will see, i'm more focused on 2.7 right now
[18:26] <whg> jimbaker: Don't le me distract you :-) I'm excited about 2.7
[18:27] <jimbaker> whg, no worries on that! hopefully the new clamp stuff will also get people excited - it's certainly is what is making jython feasible for my work
[18:27] <whg> jimbaker: clamp?
[18:28] <jimbaker> whg, clamp is a project to allow direct import and use of python classes into java
[18:29] <jimbaker> they must extend a java class and/or implement java interfaces
[18:29] <jimbaker> although we could potentially do some sugaring of that too
[18:30] <jimbaker> just as we do with single method interfaces and python callbacks, as of 2.5
[18:30] <whg> nice
[18:30] <jimbaker> this is related to such techniques as object factories, but much more versatile
[18:31] <jimbaker> anyway, i would like to explain more - but i want to go swimming today. biab
[18:31] <whg> jimbaker: Have fun
[20:28] <topi`> anyone have experience in deploying modjy servlets on tomcat? We're experiencing memory outages, could it be so that jython or modjy is keeping some RAM hostage?
[20:30] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[20:43] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Excess Flood)
[20:47] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[20:49] * r0bby_ (~wakawaka@guifications/user/r0bby) has joined #jython
[20:49] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Client Quit)
[20:56] * r0bby_ (~wakawaka@guifications/user/r0bby) Quit (Read error: Connection reset by peer)
[20:56] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[21:07] <jimbaker> topi`, in the past we have seen memory leaks on some app servers where the threadpool keeps a thread indefinitely
[21:08] <jimbaker> the bug, which should be fixed, is that a ThreadLocal has a reference to a class, which then keeps the corresponding classloader and all its other classes
[21:22] * whg is now known as zz_whg
[21:24] <topi`> so we're running out of PermGen space
[21:24] <topi`> from SO: "I can not tell the precise use of this memory pool, but it have to do with the number of classes loaded into the JVM. (Thus enabling class unloading for tomcat can resolve the problem.) If your applications generates and compiles classes on the run it is more likely to need a memory pool bigger than the default."
[21:24] <topi`> evidently Jython fits into the "generates and compiles classes on the run" description...
[21:25] <jimbaker> topi`, yes, it will certainly do that
[21:25] <jimbaker> topi, are you unloading and loading the django app on a regular basis?
[21:26] <jimbaker> we would expect that jython should settle to a steady state in terms of classes used, except in the case of eval
[21:27] <jimbaker> (and we don't do that, right?)
[21:27] <jimbaker> but unload/load, in conjunction w/ thread reuse, will certainly cause permgen issues
[21:30] <jimbaker> topi`, the stack overflow article you quoted (http://stackoverflow.com/questions/88235/dealing-with-java-lang-outofmemoryerror-permgen-space-error) references this post: http://javarevisited.blogspot.com/2012/01/tomcat-javalangoutofmemoryerror-permgen.html
[21:31] <jimbaker> so it seems that tomcat is sensitive to this type of problem (does do thread reuse); not certain why, since it's easy enough to just not reuse
[21:32] <jimbaker> topi`, having said that, my patch to fix this was pushed into jython trunk a while back. but i wasn't completely happy with it
[21:36] <topi`> what kind of patch is it?
[21:38] <topi`> what kind of threads would jython spawn when running django?
[21:39] <topi`> django itself will probably have a threadpool for incoming connections
[21:42] <jimbaker> topi`, django just its container iirc
[21:42] <jimbaker> just uses
[21:43] <topi`> jimbaker: I just saw Errno 104 from my django devel server, just like in this SO question: http://stackoverflow.com/questions/18367284/socket-error-using-boto-with-jython
[21:43] <topi`> do you have any idea what this is about?
[21:44] <topi`> it comes from socket.py
[21:44] <jimbaker> it's almost certainly an ssl issue
[21:44] <jimbaker> at least for stackoverflow, iirc you need to use ssl w/ aws
[21:46] <topi`> I think the django devel server works via http
[21:47] <topi`> yeah, ssl handshake failure on that port
[21:48] <jimbaker> topi`, my jython-ssl branch has only addressed client sockets so far, but i plan to add server support as well
[22:59] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)


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