Timestamps are in GMT/BST.
[8:38] * clajo04_ (~clajo04@pool-108-54-80-65.nycmny.fios.verizon.net) has joined #jython
[8:40] * clajo04 (~clajo04@pool-108-54-80-65.nycmny.fios.verizon.net) Quit (Ping timeout: 255 seconds)
[8:40] * clajo04_ is now known as clajo04
[12:21] * verterok (~ggonzalez@156.35.213.162.lcy-02.canonistack.canonical.com) Quit (Quit: Coyote finally caught me)
[12:23] * verterok (~ggonzalez@156.35.213.162.lcy-02.canonistack.canonical.com) has joined #jython
[12:35] * lac (~quassel@c-54c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) Quit (Ping timeout: 240 seconds)
[12:36] * lac (~quassel@c-54c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) has joined #jython
[13:12] * clajo04 (~clajo04@pool-108-54-80-65.nycmny.fios.verizon.net) Quit (Quit: clajo04)
[13:23] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[13:23] * ChanServ sets mode +o Arfrever
[13:31] * [Arfrever] (~Arfrever@apache/committer/Arfrever) has joined #jython
[13:31] * ChanServ sets mode +o [Arfrever]
[13:39] * clajo04 (~clajo04@pool-108-54-80-65.nycmny.fios.verizon.net) has joined #jython
[13:46] * xemdetia (~xemdetia@32.97.110.55) has joined #jython
[16:05] * r0bby_ (~wakawaka@guifications/user/r0bby) has joined #jython
[16:07] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 260 seconds)
[16:57] * binarybitme (~binarybit@162.243.21.247) has joined #jython
[18:06] * ELFrederich (~ELFrederi@12.54.94.108) has joined #jython
[18:07] <ELFrederich> calling gc.disable I get: NotImplementedError: can't disable Java GC
[18:08] <ELFrederich> Is there a way to ensure that no Jython objects get GC'd?
[18:09] <agronholm> ELFrederich: you will probably have to do that with JVM arguments, if it's possible at all
[18:09] <agronholm> the oracle jvm may not even support disabling GC
[18:18] <ELFrederich> agronholm, this is the commit in question. They're disabling GC because some objects with __del__ may end up calling _send while they're being GC'd which would cause a deadlock. Their solution was to disable the GC and then restore it. https://github.com/amirmiron/rpyc/commit/8c1eff86d14da8982fb292494ff613a14e3bae9e
[18:29] <jimbaker> ELFrederich, not possible to do, although there are hacks to prevent garbage collection like this one (looks like just handwaving however) - http://stackoverflow.com/a/2980093/423006
[18:30] <jimbaker> ELFrederich, incidentally the right way to fix the problem in the specific codebase is almost certainly to use weak references to manage cleanup instead of __del__
[18:30] <jimbaker> and that is a portable concept
[18:32] <ELFrederich> jimbaker, is there a common recipe for using weakrefs instead of __del__? Are you talking about the callback functionality of weakrefs?
[18:34] <jimbaker> ELFrederich, callbacks are how they exposed in python, so yes
[18:34] <jimbaker> and there are fairly common recipes i suppose. there isn't something that says, here's a direct replacement of what __del__ does
[18:36] <jimbaker> so you want to think through the lifecycle of the involved objects and methods that are being called, then build something that can use weakref to close as necessary
[18:38] <jimbaker> ELFrederich, i also gave a presentation on this subject; https://www.youtube.com/watch?v=NknSssmLk4w
[18:41] <ELFrederich> Cool... I'll have a watch. I'm just trying to think of what a "direct replacement" would look like if you want some code triggered upon deletion. This code that ran would be some callback I guess
[18:42] * ELFrederich starts watching now
[18:42] * ELFrederich will be back in 28 minutes with questions ;-)
[18:42] <jimbaker> yes, just think of a callback chain that you are managing, much like you would do with something like twisted. the big advantage: you can completely control exactly when something happens, unlike __del__ which is nondeterministic
[18:44] <jimbaker> so i'm just saying this approach makes for better python code, regardless of the implementation you run on. enjoy the presentation ;)
[18:45] <ELFrederich> Will do. I'm getting back into this now because a pull request I made for Jython got merged last night which helps Jython work better with RPyC, now I need to get RPyC working with Jython
[18:46] <ELFrederich> I think Jython is really cool as well as RPyC. Combine them both together and you have a solution for CPython to use Java Libraries
[18:47] <agronholm> ELFrederich: why not just use py4j for that? I do :)
[18:48] <ELFrederich> agronholm, with py4j I can implement a Java interface in Python, instantiate the object and call a Java method that expects that interface?
[18:49] <agronholm> ELFrederich: yes
[18:52] <jimbaker> agronholm, isn't py4j a wide open security hole?
[18:53] <jimbaker> as i understand it, if you have access to the open TCP socket it is serving against, you can do anything in the JVM
[18:54] <agronholm> jimbaker: first you have to get access to localhost
[18:54] <ELFrederich> well... using RPyC is probably a security hole as well
[18:54] <jimbaker> agronholm, sure, you can scope to that
[18:55] <jimbaker> ELFrederich, i believe that's classic mode (http://rpyc.readthedocs.org/en/latest/docs/classic.html), and you can control better since it's in a subprocess relationship
[18:56] <jimbaker> but i haven't used. just want to mention my concerns here
[18:57] <agronholm> if py4j didn't depend on sockets, it could be made to communicate over a pipe
[18:57] <agronholm> but I looked at the sources and the refactoring work is a bit too much for me
[18:58] <jimbaker> agronholm, or maybe over unix domain sockets, which would seem to be easier to do
[18:58] <jimbaker> one could use the new support in netty for UDS
[18:59] <jimbaker> (hopefully we have in place for 2.7.2... to late for 2.7.1)
[18:59] <agronholm> jimbaker: at some point I looked at UDS libraries for java, but wasn't too impressed
[18:59] <jimbaker> so UDS landed in netty early this year
[18:59] <jimbaker> basically right after i did all the major socket work in socket-reboot...
[19:00] <agronholm> :(
[19:00] <jimbaker> to be honest, i think it will be quite simple to add support for UDS... just bad timing. so that's why it should be in 2.7.2
[19:51] * sidrero (~user6233@cable-static-142-200.teleport.ch) has joined #jython
[19:52] <sidrero> hi agronholm
[19:52] <agronholm> hello?
[19:52] <sidrero> i tested jurko and my probles are gone
[19:52] <sidrero> so thanks a lot
[19:52] <agronholm> yw :)
[19:55] <jimbaker> good to know about jurko. i wonder how it would compare to jax-ws support in java and just using that from jython
[20:44] <sidrero> no idea, except that jurko is very easy to use compared to any java l:brary
[20:45] <sidrero> if you are in a hurry jurko is your thing
[20:47] <agronholm> doesn't the same apply to python generally?
[20:48] * lac (~quassel@c-54c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) Quit (Remote host closed the connection)
[20:48] * lac (~quassel@c-54c5e055.1321-1-64736c11.cust.bredbandsbolaget.se) has joined #jython
[20:56] <jimbaker> sidrero, ack. i believe java-ws client usage is pretty easy as well, but mostly i'm curious what the performance would look like vs jurko. last i looked, suds was plain awful, but this was in 2009, well before jurko i'm sure
[20:58] <sidrero> i would be happy to test a java lib from jython, but i found no examples and had no time to figure it out
[20:59] <agronholm> sidrero: you just add the jar to the class path and import as usual
[21:01] <jimbaker> or append to sys.path...
[21:02] <sidrero> yes so far i can get
[21:02] <sidrero> what i mean is
[21:03] <sidrero> i found no clear examples on hiw to use it
[21:03] <sidrero> or the exampkes were much more complucated than suds
[21:04] <sidrero> i was using soappy from cpython which is very easy so i guess i got spoiled
[21:09] <sidrero> now i am lookung at jax, yes it is not so bad
[21:15] * sidrero (~user6233@cable-static-142-200.teleport.ch) Quit (Read error: Connection reset by peer)
[22:02] * xemdetia (~xemdetia@32.97.110.55) Quit (Ping timeout: 240 seconds)
[22:47] * non-sense (~non@unaffiliated/non-sense) Quit (Read error: Connection reset by peer)
[22:49] * non-sense (~non@unaffiliated/non-sense) has joined #jython
[23:34] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 260 seconds)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).