#jython IRC Log


IRC Log for 2014-03-12

Timestamps are in GMT/BST.

[8:03] -kornbluth.freenode.net- *** Looking up your hostname...
[8:03] -kornbluth.freenode.net- *** Checking Ident
[8:03] -kornbluth.freenode.net- *** No Ident response
[8:03] -kornbluth.freenode.net- *** Couldn't look up your hostname
[8:03] * JythonLogBot (~PircBot@ has joined #jython
[8:03] * Topic is 'Try Jython 2.7b1 at http://tinyurl.com/d4s8qvd | This channel is logged: http://jython.extreme.st/irclogs/ | Please update the wiki: http://wiki.python.org/jython | Jython Book: http://jythonbook.com | Podcast: http://jython.org/jythonpodcast/'
[8:03] * Set by Juneau001!~Juneau@50-45-119-204.dklb.il.frontiernet.net on Tue Feb 12 23:33:36 UTC 2013
[8:11] * zimmermann (~user@178-24-50-233-dynip.superkabel.de) has joined #jython
[8:20] * zimmermann (~user@178-24-50-233-dynip.superkabel.de) Quit (Ping timeout: 246 seconds)
[10:45] * Tycale_ (~Tycale@tycale.be) has joined #jython
[10:45] <Tycale_> Hi
[10:46] <Tycale_> I'm new to Jython and I'm asking myself how I can call a java function in python with this argument in java "new Object[]{}" ?
[10:47] <Tycale_> Sorry for my poor english
[10:48] <Tycale_> My question is how to translate "ddp.subscribe("allPositions", new Object[]{});" (java) in jython.
[10:55] <agronholm> Tycale_: you want to construct an array
[10:55] <agronholm> use array.array for that
[10:55] <agronholm> although I'm surprised that simply [] wouldn't work
[10:56] <agronholm> (I'm sure you've tried that already)
[11:53] <Tycale_> Perfect :)
[11:53] <Tycale_> Thanks you agronholm :)
[12:42] * thereisnospoon (~thereisno@113-61-86-28.static.qld.dsl.net.au) has joined #jython
[12:44] * thereisnospoon_ (~thereisno@113-61-86-28.static.qld.dsl.net.au) Quit (Ping timeout: 265 seconds)
[14:01] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[15:53] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[16:21] * enebo (~enebo@mobile-198-228-233-109.mycingular.net) has joined #jython
[16:22] <jimbaker> i wonder if i will get any takers on sre work (our underklying regex engine, implemented as a mini vm with its own bytecode)
[16:23] <jimbaker> similar to what enebo occasionally works on with joni :)
[16:23] <jimbaker> btw, enebo, i did go through that codebase just now to see what we might learn/steal
[16:23] <enebo> jimbaker: nashorn did that and forked it
[16:24] <enebo> jimbaker: JS has some variation in regex over what was provided
[16:24] <jimbaker> yeah, it would make sense to do that except the python compliance tests are just too tough
[16:24] <enebo> jimbaker: We are working with dynjs to incorporate that into joni though
[16:24] <jimbaker> just enough of a dialect variation
[16:24] <enebo> jimbaker: I did not do the port (lopex) did but the underlying engine itself seems pretty hackable
[16:25] <enebo> jimbaker: I imagine most of the underlying machine probably works right?
[16:25] <jimbaker> yes, we actually looked at using joni, about 5 years ago
[16:26] <enebo> time flies :)
[16:26] <jimbaker> so clearly a lot changed. nicholas riley spent a lot of time on it then, but it was the usual last bits that confounded that usage
[16:28] <jimbaker> what i did find useful in looking at joni is it confirmed my thoughts on having some sort of encoding aware way of going forward/backward in the string being matched; and also it was useful seeing how the switch statements were structured in the vm
[16:29] <enebo> jimbaker: I see yeah. Joni is sort of a little odd in being a C port but the basic engine design seems sound
[16:30] <jimbaker> right now our sre engine does a direct conversion to codepoints for every string, which is result in O(n^2) type performance in sophisticated regex usage, like seen in beautiful soup
[16:30] <jimbaker> our sre engine is a direct port of cpython's, so it's even more c like, since it retains the indexed array ops against the codepoint string
[16:30] <enebo> jimbaker: How are things in Jython land anyways? I have not been following unfortunately
[16:30] <jimbaker> (this matches better cpython, which uses ucs-2/ucs-4)
[16:31] <enebo> jimbaker: I like the potential of joni and making a bytecode compiler for it
[16:31] <enebo> jimbaker: I think nashorn had even started on one (but I don't know if they finished or not)
[16:31] <enebo> jimbaker: ah I see
[16:32] <jimbaker> python actually has, in python itself, a bytecode compiler to sre
[16:32] <jimbaker> that's one should always cache regexes in python
[16:32] <jimbaker> why
[16:33] <jimbaker> re jython status - it's been slower than i would have hoped. we hit a major snag in terms of supporting ssl, which for obvious reasons is kind of essential these days
[16:33] <enebo> jimbaker: in cases where vm cannot see it is static I guess
[16:33] <enebo> jimbaker: yeah SSL blows for everyone :)
[16:33] <jimbaker> specifically how it's exposed in python, which is very C like
[16:34] <enebo> jimbaker: We do have jruby-openssl which is far from perfect but it does enough to keep people !angry
[16:34] <jimbaker> this is blocking jython because we really need to support standard tooling. it's like a ruby w/o gems
[16:35] <jimbaker> so jython w/o pip/virtualenv is not ready for release
[16:35] <enebo> jimbaker: I am unsure how portable it is but it is meant to mimick openssl at some level
[16:35] <jimbaker> i should take a look. the workaround i have chosen is to use netty and bouncy castle
[16:36] <enebo> jimbaker: yeah jruby-openssl also uses bouncy castle
[16:36] <enebo> jimbaker: but the original motivation was to make something more like openssl because Ruby's API was too C like :)
[16:36] <jimbaker> and this seems to work quite well, even if it's great abuse to implement such low level semantics on much cleaner, higher level code
[16:37] <jimbaker> one thing you probably do is fully support file descriptors
[16:37] <enebo> jimbaker: openssl support is still a massive magnet for issues over time
[16:38] <jimbaker> fortunately windows support is important enough in the python community that we can just offer a subset of full socket support. although i think one could do most of it in netty regardless
[16:38] <jimbaker> sorry. that's really full select support
[16:39] <jimbaker> but it's all of the same piece - socket/select/ssl
[16:40] <enebo> yeah
[16:40] <jimbaker> anyway, i got a spike that basically works. just finishing up getting it to work against our unit tests, and i hope to have a beta by end of this month
[16:41] <jimbaker> beta 2 to be precise
[16:42] <jimbaker> the good thing is, rackspace is supporting my work here, so i have had some time. it will be interesting to see if this merges in w/ red hat at some point - i know we work together on openstack
[16:42] <jimbaker> and there are obvious and interesting directions there w/ jython ;)
[16:43] <enebo> cool.
[16:47] <jimbaker> anyway, i'm sure we will have a chance to discuss much more. i do feel that 2.7b2 will be a good milestone for us, especially with related work like clamp (better integration from java to jython)\
[16:48] <jimbaker> and did i mention how much fun it is to be back working on jython? good stuff indeed :)
[17:05] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)
[17:10] * smaudet (~smaudet@206-51-157-254.nktelco.net) has joined #jython
[17:29] <lopex> jimbaker: nashorn uses java.lang.String for joni internally so it doesnt pay conversion penalty
[17:32] <jimbaker> lopex, right, something i would hope to do with jython. jython backs both unicode and str types with java.lang.String, so it should just work with appropriate step/stepBack type functionality
[17:32] <jimbaker> (when we get to jython 3.x, we can get actually make str do the right thing, and back with a byte array)
[17:33] <jimbaker> (but it's just much easier to pay the penalty given how python 2.x allows implicit conversions)
[17:34] * lheuer (~Adium@f048013073.adsl.alicedsl.de) has joined #jython
[17:34] * lheuer (~Adium@f048013073.adsl.alicedsl.de) Quit (Changing host)
[17:34] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[17:35] <lopex> jimbaker: oniguruma has configurable syntaxes/features which they stripped off so that's another issue
[17:36] <jimbaker> lopex, i think it's pretty tough to do dialects in regexes, at least in my limited exploration
[17:37] <smaudet> So actually using these jython clamped files inside a Tomcat instance (which was my end goal), is way to finnicky - not that it can't be made to work, but feature is probably post beta, in the second minor version or something. It looks like it is at least working, but I'm having to manually copy things into and out of Lib and lib directories and jars and such. It is, quite a mess.
[17:39] <jimbaker> smaudet, it is definitely very early. we have high hopes for clamp, but there's a fair amount of work to be done
[17:39] <smaudet> Yeah. It IS alpha so plenty of groundwork left.
[17:39] <smaudet> At least I don't want to use anything in the JyNI
[17:39] <smaudet> ;)
[17:40] <jimbaker> i think we at least figured out most of the setuptools issues, which was a big pain
[17:40] <smaudet> Are you getting your msdn license tomorrow?
[17:41] <jimbaker> i have no visibility into that process. brian curtin who arranges this says it generally takes 3-5 days
[17:42] <jimbaker> in the meantime - i should look at jar construction, and resolve the path separator issue. obviously this only pops up on windows, but i'm pretty sure i can find what would cause the issue
[17:43] <jimbaker> the other thing that i haven't explored since we last talked is the old singler jar stuff, which doesn't allow us to do site-packages support in that case
[17:43] <jimbaker> this should simply require some work around supporting an appropriate class loader
[17:46] <smaudet> Well I got the clamped files to run in Tomcat at least, its impressive that it works as much as it does.
[17:47] <smaudet> Now, for a clamped file, I'm presuming that you can't live reload this as well?
[17:47] <jimbaker> smaudet, in principle you could
[17:47] <smaudet> Since the generated bytecodes correspond to some actual python method
[17:47] <smaudet> Unless you were to add something like JRebel into the mix.
[17:47] <smaudet> X_X
[17:48] <jimbaker> right, let's exclude jrebel for the moment
[17:48] <jimbaker> so w/o jrebel, the java-facing part is fixed. however, the python code is still dynamic
[17:49] <jimbaker> so let's use the clamped example for the specific namespaces
[17:49] <smaudet> Yeah. I have a feeling something will be cached somewhere on the bridge
[17:49] <smaudet> Oh and ftr on Tomcat I'm using bean-style loading, so that's already compatible
[17:50] <jimbaker> smaudet, oh nothing is cached
[17:50] <jimbaker> python semantics are definitely maintained
[17:51] <smaudet> Having looked through the code, I would say that there are two parts, the mypython.py$.class and the phony.package.mypython.class
[17:51] <jimbaker> so it's certainly possible for me to reach into clamped.BarClamp, and monkeypatch any of its methods
[17:51] <smaudet> And I don't know if/when the monkey patching occurs for the bridge
[17:51] <smaudet> I agree that it is possible, is it implemented though.
[17:51] <jimbaker> correct, the proxy in the case of clamped would be bar.clamped.BarClamp, following that narrative
[17:52] <jimbaker> it is already implemented given that it's just stock jython
[17:52] <jimbaker> which in turn follows python semantics
[17:52] <smaudet> mm ok so monkeypatching should work
[17:52] <smaudet> but I can't add or remove functions
[17:53] <smaudet> not to the bar.clamped.BarClamp
[17:53] <jimbaker> you can add/remove functions, just wouldn't be known to java
[17:53] <smaudet> Yeah, that's exactly what I"m saying
[17:53] <jimbaker> because those methods strictly come from the fact that BarClamp implements java interfaces
[17:54] <jimbaker> (optionally it could also extend a java class)
[17:54] <smaudet> functions are added/removed from the clamped.BarClamp.py$.class, but not the bar.clamped.BarClamp.class
[17:54] <jimbaker> so that's the fixed part
[17:54] <jimbaker> smaudet, if you monkeypatch, you are actually getting methods defined potentially in some other piece of bytecode
[17:55] <smaudet> jimbaker: what do you mean when you say 'bytecode' Java bytecode? or pyc?
[17:55] <jimbaker> so $py.class is fixed, just like any other java bytecode
[17:55] <jimbaker> smaudet, of course you could use pyc as well :)
[17:56] <jimbaker> you may know of the pycimport module, it's occasionally brought up on this channel
[17:56] <jimbaker> suffice to say, that's true pre-alpha ;)
[17:56] <smaudet> Actually I'm not that familiar with it, I know of pyc but not much about it
[17:57] <jimbaker> jython has an experimental python bytecode virtual machine bundled in it
[17:57] <jimbaker> it can be accessed a number of ways. most easily through pycimport
[17:57] <jimbaker> which allows for direct import of pyc fiels
[17:57] <jimbaker> files
[17:58] <smaudet> I understand the potential use, but I feel as if at that point JyJy should be a thing
[17:58] <smaudet> JVM implementation of PyPy
[17:59] <smaudet> or something along those lines
[17:59] <jimbaker> there is
[17:59] <jimbaker> the zippy project. two phd students at uc irvine are working on it. runs on graal/truffle
[18:00] <jimbaker> graal is a self-hosting jvm, written in java. truffle adds type specialization infrastructure. they have demonstrated on some benchmarks better than pypy perf
[18:01] <jimbaker> so graal/truffle is closest to the pypy infrastructure. zippy is one example of what can be done w/ it. there's also similar work on javascript and ruby
[18:01] <jimbaker> on graal/truiffle
[18:02] <jimbaker> i'm sure there will be more updates by the time of the next jvm lang summit
[18:02] <smaudet> Interesting.
[18:02] <jimbaker> http://openjdk.java.net/projects/mlvm/jvmlangsummit/
[18:05] <jimbaker> smaudet, here are the slides for ruby: http://www.oracle.com/technetwork/java/jvmls2013wimmer-2014084.pdf
[18:05] <jimbaker> zippy is pretty much the same approach
[18:05] <jimbaker> they plan to use more of jython at some point. we will see!
[18:06] <jimbaker> topaz is the ruby implementation running on pypy
[18:07] <smaudet> I'd bet you 5 bucks they have a JSR for a standardized bytecode format, and use ASN1 or something.
[18:07] <smaudet> Just postulating.
[18:08] <smaudet> (machines on the networks of the future send around packets of bytecode)
[18:08] <smaudet> But pretty cool, yeah.
[18:09] <jimbaker> sounds like the original vision of hotjava
[18:09] <jimbaker> but it's certainly what we sort of see w/ hadoop or storm
[18:09] <smaudet> Yeah, but this is the IETF version
[18:10] <jimbaker> sure, with mime types
[18:10] <smaudet> HTTP 2.0 is still in the works, so hey.
[18:10] <smaudet> Give them time.
[18:13] <smaudet> jimbaker: anyways thanks for your all your help! I'll probably be back with some patches (lets hope).
[18:14] <jimbaker> smaudet, definitely!
[18:14] <smaudet> btw where is the JVM summit usually?
[18:14] <smaudet> I might try to convince my company to let me go.
[18:14] <jimbaker> smaudet, it's well worth attending. and always sells out
[18:15] <jimbaker> santa clara, 100 people max, at the old sun campus (a former mental hospital)
[18:16] <jimbaker> it will be a good chance to discuss java 9, how java 8 works out, and such things as the future of sun.misc.unsafe
[18:17] <jimbaker> with that, bbl, time for a run!
[18:17] <smaudet> take care!
[19:17] * shashank (~shashank@ Quit (Remote host closed the connection)
[19:18] * shashank (~shashank@ has joined #jython
[19:45] * swilcox (~swilcox@ has joined #jython
[19:50] * swilcox (~swilcox@ has left #jython
[20:56] * enebo (~enebo@mobile-198-228-233-109.mycingular.net) Quit (Ping timeout: 264 seconds)
[21:14] * smaudet (~smaudet@206-51-157-254.nktelco.net) Quit (Ping timeout: 246 seconds)
[21:25] * enebo (~enebo@ has joined #jython
[21:43] * enebo (~enebo@ Quit (Ping timeout: 246 seconds)
[22:41] <jimbaker> started this project, because it is a real need - https://pypi.python.org/pypi/logbridge
[22:42] <jimbaker> just a skeleton now, but having a sl4j provider for python's logging package seems to be the right thing to do
[22:42] <jimbaker> especially for integrating w/ frameworks like storm
[23:08] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)


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