#jython IRC Log (v0.9)


IRC Log for 2016-05-31

Timestamps are in GMT/BST.

[3:46] * stewori (~stefan@ Quit (Ping timeout: 244 seconds)
[7:03] * ohumbel (5390f784@gateway/web/freenode/ip. has joined #jython
[11:42] * dzosh (~dzosh@ has joined #jython
[11:43] <dzosh> Hi there, anybody experienced with Jython 2.7, Weblogic 12.1.x and wlst Jython Module?
[12:11] * dzosh (~dzosh@ Quit (Quit: leaving)
[12:14] * maucar (~maucar@c-24-62-42-67.hsd1.ma.comcast.net) has joined #jython
[12:14] * maucar (~maucar@c-24-62-42-67.hsd1.ma.comcast.net) Quit (Max SendQ exceeded)
[12:15] * maucar (~maucar@c-24-62-42-67.hsd1.ma.comcast.net) has joined #jython
[12:15] * maucar (~maucar@c-24-62-42-67.hsd1.ma.comcast.net) Quit (Max SendQ exceeded)
[12:38] * TomA (~TomA@c-68-32-46-223.hsd1.mi.comcast.net) has joined #jython
[12:42] * maucar (~maurizioc@c-24-62-42-67.hsd1.ma.comcast.net) has joined #jython
[12:44] * maucar (~maurizioc@c-24-62-42-67.hsd1.ma.comcast.net) Quit (Client Quit)
[12:44] * maucar (~maurizioc@c-24-62-42-67.hsd1.ma.comcast.net) has joined #jython
[13:31] * TomA_ (~TomA@c-68-32-46-223.hsd1.mi.comcast.net) has joined #jython
[13:31] * TomA (~TomA@c-68-32-46-223.hsd1.mi.comcast.net) Quit (Read error: Connection reset by peer)
[13:48] * TomA (~TomA@c-68-32-46-223.hsd1.mi.comcast.net) has joined #jython
[13:48] * TomA_ (~TomA@c-68-32-46-223.hsd1.mi.comcast.net) Quit (Read error: Connection reset by peer)
[14:33] * xemdetia (xemdetia@nat/ibm/x-llryvujsplawjmop) has joined #jython
[14:33] * stewori (~stefan@ has joined #jython
[15:05] <jimbaker> stewori, it's the usual here - if there's no test to verify itertools' being a proper module, it may not be one
[15:05] <jimbaker> as in this case
[15:06] <jimbaker> modules see a variety of implementation choices, mostly due to convenience OR implementer's background/preference
[15:07] <jimbaker> in any event, observable differences like this are generally bugs. seems to be the case here. fortunately they are usually very easy to fix
[15:16] <stewori> Hey. I also gave this some more thoughts. I guess this issue (let's call it issue for now) originates from the fact that in Java classes are the equivalent of modules in Python. But classes are also always types, which leads to the collision. So far I did not encounter any problem based on this issue.
[15:16] <stewori> ...BUT
[15:17] <stewori> it also means that some type-check macros in JyNI's exposure of the C-API are inherently broken for modules coming from Jython
[15:18] <stewori> and big frameworks like NumPy actually do use the native import-API in import.c. Fortunately they don't apply PyModule_Check(op) on the resulting object. But in principle an extension might fail on this
[15:19] <stewori> (the resulting object would be mapped to a type-object by JyNI, because that's how the Java-object looks like)
[15:19] <stewori> leading also to false-positives regarding PyType_Check()
[15:21] <stewori> However. For now, as long as it doesn't cause actual trouble I am fine to leave it this way. But I would propose (for Jython 2.7.?) to provide some marker interface or annotation for Classes that are intended to function as modules. Maybe it could be as easy as extending PyModule...?
[15:27] <stewori> (the marker would be optional, leading to better integration. Of course plain classes would continue to work as modules like they currently do.)
[15:28] <jimbaker> marker interfaces are easy enough to add in java, and we use them to a certain extent in jython already
[15:29] <jimbaker> stewori, can you just collect together some of this into an issue, and we can look into what it will take to implement? still seems straightfoward
[15:30] <stewori> Alright. (Jim I have to leave now, we can continue this async. cu)
[15:30] * stewori (~stefan@ Quit (Quit: Leaving.)
[15:51] <jimbaker> stewori, sounds good. thanks for finding this problem. obviously the higher priority is getting that publication bug fixed
[19:04] <TomA> jimbaker got a weird one for ya...we are seeing stacktraces that include full paths on the machine in which our software was built (and not currently deployed).
[19:06] <TomA> (IllegalStateException) java.lang.IllegalStateException: Can't use this cluster instance because it was previously closed
[19:06] <TomA> at twisted.internet.defer$py._inlineCallbacks$54(/path/on/our/build/machine/???ripcord/opscenterd/src/../lib/py/twisted/internet/defer.py:1200)
[19:06] <TomA> at org.python.core.PyTableCode.call(PyTableCode.java:167)
[19:06] <TomA> at org.python.core.PyBaseCode.call(PyBaseCode.java:308)
[19:06] <TomA> at org.python.core.PyBaseCode.call(PyBaseCode.java:179)
[19:06] <TomA> at org.python.core.PyFunction.__call__(PyFunction.java:446)
[19:06] <TomA> at org.python.core.PyMethod.__call__(PyMethod.java:171)
[19:06] <TomA> ???
[19:07] <TomA> any initial thoughts? Wonder if something went awry during the initial setup()?
[19:34] <nickmbailey> @TomA is it cause we compile the .class files at build time?
[19:35] <nickmbailey> and perhaps thats when the string to use for stack traces is generated
[19:35] <TomA> that's what I was looking at...we use compileall.compile_dir
[19:35] <TomA> ddir: if given, the directory name compiled in to the byte-code file.
[19:36] <TomA> we don't pass it in
[19:36] <TomA> so I wonder if the default is being generated with the full path on our build machine
[19:36] <TomA> looking at it now
[19:38] <TomA> and it works as expected in python stack traces...it only surfaces in java stacktraces
[20:31] * maucar (~maurizioc@c-24-62-42-67.hsd1.ma.comcast.net) Quit (Quit: Leaving)
[20:38] <jimbaker> TomA, that makes sense. java from very early on - in part to support jython - has had support for non-java source files. perhaps this is the information that is being presented here. we do have jython-specific metadata through annotations that may account for the divergence in what is shown in the python-only stack track
[21:24] * stewori (~stefan@ has joined #jython
[22:29] * xemdetia (xemdetia@nat/ibm/x-llryvujsplawjmop) Quit (Ping timeout: 244 seconds)
[23:00] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Quit: ?????????)


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