#jython IRC Log (v0.9)

Index

IRC Log for 2013-05-07

Timestamps are in GMT/BST.

[3:15] * Juneau001 (~Juneau@50-45-105-133.dklb.il.frontiernet.net) has joined #jython
[3:16] * Juneau001 (~Juneau@50-45-105-133.dklb.il.frontiernet.net) Quit (Client Quit)
[3:22] * Juneau001 (~Juneau@50-45-105-133.dklb.il.frontiernet.net) has joined #jython
[3:50] * r0bby (~wakawaka@guifications/user/r0bby) has joined #jython
[3:53] * r0bby_ (~wakawaka@guifications/user/r0bby) has joined #jython
[3:57] * r0bby (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 272 seconds)
[4:03] * Juneau001 (~Juneau@50-45-105-133.dklb.il.frontiernet.net) Quit (Quit: Juneau001)
[4:40] * TheFunnyHorse (~purplefox@88-105-167-119.dynamic.dsl.as9105.com) has joined #jython
[4:53] * r0bby_ is now known as robbyoconnor
[5:08] * TheFunnyHorse is now known as purplefox
[7:03] * paolo (~Paolo@net-37-117-52-158.cust.dsl.vodafone.it) has joined #jython
[9:45] * msavy (msavy@redhat/jboss/msavy) has joined #jython
[9:56] * paolo (~Paolo@net-37-117-52-158.cust.dsl.vodafone.it) Quit (Ping timeout: 245 seconds)
[10:44] * paolo_ (~Paolo@net-37-117-52-158.cust.dsl.vodafone.it) has joined #jython
[11:06] * Juneau001 (~Juneau@131.225.24.156) has joined #jython
[14:15] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 260 seconds)
[15:07] * paolo_ is now known as paolo
[16:23] * msavy (msavy@redhat/jboss/msavy) Quit (Remote host closed the connection)
[16:46] * paolo (~Paolo@net-37-117-52-158.cust.dsl.vodafone.it) Quit (Quit: Leaving)
[16:58] * mritz (~textual@97.65.251.170) has joined #jython
[17:21] * Juneau001 (~Juneau@131.225.24.156) Quit (Ping timeout: 268 seconds)
[17:27] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[17:30] * msavy (~msavy@redhat/jboss/msavy) has joined #jython
[17:33] * msavy (~msavy@redhat/jboss/msavy) Quit (Client Quit)
[18:04] * msavy (~msavy@redhat/jboss/msavy) has joined #jython
[18:31] * workless (~Davide@dynamic-adsl-78-12-174-182.clienti.tiscali.it) has joined #jython
[18:34] <workless> hi! :-) i'm considering jython as language for a project rewriting, i would to like to ask few question if you don't mind
[18:36] <agronholm> workless: jython isn't a language, but other than that, go on please
[18:39] <workless> i love python, it's easy, readable and very productive, and "uncle bob" just convinced me that by using unit testing non-static typed languages can be solid too, but we're developing an extension for a java server, so we don't get to choose a language :(
[18:40] <agronholm> is high performance a requirement?
[18:41] <workless> here jython comes in... my questions are: 1) is really stable production ready? could you name a big who's using it? 2) can i really do everything i can do with ""native java""? like bad stuff with reflection and evil casts?
[18:41] <workless> agronholm: just an integration requirement, we must write an humble extension written in .jar, no more, no less
[18:42] <agronholm> reflection from python to java does not work, and casts are a compile time thing so not applicable to python code
[18:44] <agronholm> the java side has to invoke the pythoninterpreter (or use the jsr-223 interface)
[18:44] <workless> mmhmm ook, good to know _before_ facing it directly, we may still close the bad stuff in a dedicated library (where we force our way and we integrate even more with the system)
[18:44] <workless> agronholm: no problem here
[18:45] <workless> is it really stable?
[18:45] <agronholm> depends on your definition of stable
[18:45] <agronholm> it still has considerable "holes" (missing functionality when compared to CPython)
[18:46] <agronholm> like the lack of sqlite support
[18:46] <agronholm> or CJK encodings
[18:46] <agronholm> jython 2.5.x is also missing the bz2 module
[18:46] <agronholm> there are several other incompatibilities due to JVM limitations
[18:47] <agronholm> then there are subtle locking issues due to no GIL
[18:47] <agronholm> getting locking right without a GIL is damn near impossible
[18:47] <workless> we aren't doing a critical software, but we are managing backups and tons of emails and other PIM data of many public administrations
[18:48] <workless> agronholm: really? why?
[18:48] <agronholm> your best bet is probably jython 2.7b1, but you're not looking for beta software, right?
[18:48] <workless> locking without GIL should virtually work the same?
[18:49] <agronholm> ideally, yes
[18:49] <workless> agronholm: not really, but the rewrite could takes months
[18:49] <agronholm> but to lock the right things at the right times
[18:49] <agronholm> that's the challenge
[18:49] <agronholm> and getting that right takes a herculean effort
[18:49] <workless> agronholm: i'm used to pthreads as well :) it's not that bad, is it?
[18:49] <agronholm> I don't think you understand the problem here
[18:50] <agronholm> the python language comes with certain assumptions
[18:50] <agronholm> like reading/writing a single dict entry should be atomic
[18:50] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Max SendQ exceeded)
[18:50] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[18:50] <agronholm> but that's not always the case behind the scenes
[18:51] <workless> mmhmm you made your point...
[18:51] <agronholm> so the interpreter has to go to extra lengths to make sure those assumptions can be trusted
[18:51] <agronholm> and jython isn't doing a perfect job there
[18:52] <workless> we could skip the problem by using a messaging system instead of a classic multithreading but i don't know know how easy would be to maintain
[18:53] <workless> *skipping=>limiting
[18:53] <agronholm> why bother with jython then? you could just use cpython instead
[18:54] <agronholm> the only advantage would be in native java serialization
[18:54] <workless> agronholm: we need java integration with the existing system which we didn't write
[18:54] <agronholm> still, sounds like a lot of work just to write code in Python
[18:55] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 264 seconds)
[18:56] <workless> agronholm: i'm going to use the language i choose for this project for at least other 2/3 years, if i could choose python over java it would awesome
[18:56] <workless> *would be
[18:56] <agronholm> alright...well you have been warned :)
[18:57] <workless> agronholm: thank you :)
[18:57] <agronholm> also, nobody is getting paid for jython work at the moment so the release timetable isn't very clear
[18:59] <workless> too bad, my company doesn't have enough time/money/people to back jython, but we may take a couple of weeks a year to improve it if we get to use it
[19:00] <agronholm> you won't get much done in just two weeks
[19:00] <agronholm> developing jython itself is a black art
[19:00] <workless> lol
[19:00] <agronholm> one I can't claim I'm expert at
[19:04] <workless> agronholm: can't you plug in the pypy project somehow? just focus on the java backend and let pypy the language specific features?
[19:04] <agronholm> workless: it doesn't quite work that way
[19:05] <agronholm> besides, jython development may be a black art but developing PyPy requires the secrets of the elder gods
[19:05] <workless> assertions are everywhere?
[19:05] <workless> loool
[19:05] <workless> is THAT bad?
[19:05] <agronholm> yep.
[19:06] <agronholm> only a select few developers even have the capacity to comprehend the inner workings of PyPy
[19:06] <workless> like maxine :)
[19:06] <agronholm> besides, PyPy is ultimately written in C
[19:06] <agronholm> and Jython requires strong Java integration
[19:07] <agronholm> and it must run on the JVM
[19:07] <agronholm> PyPy runs on a very different kind of VM
[19:07] <workless> agronholm: yep, it's useless otherwise!
[19:07] <agronholm> so they are inherently incompatible
[19:08] <workless> have you ever heard of maxine? i heard about it few days back listening to software engineering radio (free quality podcasts!)
[19:09] <workless> it'a 100% java jvm *_*
[19:09] <agronholm> never heard of it
[19:10] <workless> kinda like pypy, but for real
[19:11] <agronholm> pypy isn't for real...?
[19:12] <workless> you just said it yourself, "it's ultimately written in C"
[19:13] <agronholm> it's not that simple
[19:13] <agronholm> pypy is really python written in python, but in that configuration it's like 25x [citation needed] slower than CPython
[19:13] <agronholm> but that's where the black magic happens
[19:15] <agronholm> when it's built, it's transformed via complex rules into C code (I think? correct me if I'm wrong)
[19:15] <agronholm> and the end result is what you get when you download a pypy binary
[19:31] <workless> agronholm: thank you for the chat, you really pointed out where the pits are, tomorrow i will discuss it with the team, to be honest i'm a little scared about using jython
[19:37] <jimbaker> well... i personally think the jython internals are straightforward
[19:38] <jimbaker> but one cannot simply just go in and fix one thing in a day unless you're in the development mindset... from previous experience (at least year's pycon), it takes me two days to get war,
[19:38] <jimbaker> warm
[19:38] <agronholm> indeed
[19:39] <agronholm> took me way longer to be able to contribute anything significant
[19:48] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[20:10] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[20:33] * workless (~Davide@dynamic-adsl-78-12-174-182.clienti.tiscali.it) Quit (Quit: bye!)
[20:33] * workless (~Davide@dynamic-adsl-78-12-174-182.clienti.tiscali.it) has joined #jython
[20:50] <jimbaker> anyway, i just joined rackspace and i personally plan to use jython for some projects. so maybe i will get in some commits soon, at least as soon as i finish with the final details of a course i taught this semester
[20:50] <agronholm> that would be nice
[20:50] <agronholm> jython hasn't seen any commits in 6 weeks
[20:53] <jimbaker> yeah, too many busy people
[20:53] <jimbaker> but at least unlike canonical, there's a good reason to use jython at rackspace
[20:54] <agronholm> what's that?
[20:54] <jimbaker> just the standard python + java stuff
[20:54] <agronholm> something that doesn't fit py4j?
[20:55] <jimbaker> well, i'm not familiar with py4j but a quick review of the FAQ suggests that it uses a RPC approach
[20:56] <jimbaker> i'm sure it's good for that sort of purpose
[20:57] <agronholm> there might be a tad more overhead in java <-> python communication but you get to use cpython on the other end
[20:57] <jimbaker> i don't have any GUI or C level integration to worry about... so jython should be fine
[20:57] <agronholm> or even pypy
[20:57] <agronholm> so it suits some of my projects very well, where I just need to use certain java libs (jasperreports) in python apps
[20:58] <jimbaker> for coarse-grained integration, that makes sense
[20:58] <agronholm> yup
[20:58] <jimbaker> for the sort of fine-grained stuff i'm interested in, nahhh
[20:58] <agronholm> but then I have the gui app I showed you at last year's pycon, and that requires jython
[20:58] <agronholm> no way around it unless I rewrite it using some other presentation tech
[20:59] <jimbaker> right
[21:02] <lopex> pypy can generate c but mostly generates assembly
[21:03] <lopex> and pypy is written in rpython which has c semantics anyway
[21:11] <jimbaker> it's an interesting idea to apply pypy against jvm... but i suspect loop-oriented optimizations are extraordinarily hard to do on something like the jvm as well
[21:11] <jimbaker> it wants to do its own optimizations :)
[21:11] <jimbaker> biab
[21:18] <lopex> there was a talk recently wrt that on #jruby lately
[21:18] <lopex> and topaz
[21:19] * workless (~Davide@dynamic-adsl-78-12-174-182.clienti.tiscali.it) Quit (Ping timeout: 246 seconds)
[21:19] <lopex> jimbaker: also lack of code specialization and frame manipulation were most noted obstacles
[21:36] * mritz (~textual@97.65.251.170) Quit ()
[22:05] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[22:13] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 264 seconds)
[22:48] <jimbaker> lopex, i worked with a masters student who finished up recently here at the univ of colorado where we looked at what we could do with optimizing jython performance using invokedynamic, and we did get some good results. but they got far better if we allowed for any form of static analysis (with suitable guards to backout to full dynamic python)
[22:49] <jimbaker> in particular, being able to mark a function in some way with @frameless would see a significant speedup, with the concession that we would have to go into a significant slowdown if the user decided to repurpose this annotation
[22:51] <lopex> jimbaker: via IR ?
[23:01] <jimbaker> lopex, yes, we have a new IR for jython in this work
[23:01] <jimbaker> pretty basic control flow graph approach, directly inspired by cpython
[23:01] <lopex> jimbaker: jython has similar challanges as jruby does, headius already pushes hotspot folks about stuff
[23:02] <jimbaker> the idea is to emit dumb idomatic java code
[23:02] <jimbaker> idiomatic
[23:02] <lopex> jimbaker: and deopts ?
[23:02] <jimbaker> the stuff the jvm likes to optimize
[23:02] <jimbaker> yes, and some deoptimization work too :)
[23:03] <lopex> btw wrt pypy http://tratt.net/laurie/research/pubs/html/bolz_tratt__the_impact_of_metatracing_on_vm_design_and_implementation/
[23:03] <lopex> pypy folks always paste this paper
[23:03] <jimbaker> lopex, it's not at all complete. in particular a big deoptimization that needs to be implemented is a new backend for python bytecode, so we can go into interpreter mode - pretty necessary for any agressive optimziations
[23:03] <lopex> jimbaker: and generators are also a challange right ?
[23:04] <lopex> *challenge
[23:04] <lopex> jimbaker: headius also uses his own prettified indy apis
[23:04] <jimbaker> lopex, well they can be readily identified... but only some of them can be readily optimized. basically anything that's a generator expression
[23:04] <lopex> jimbaker: I think it would come handy to you as well
[23:05] <lopex> jimbaker: right, so the stack problem goes away
[23:05] <jimbaker> lopex, yeah, the next iteration is definitely to use that support
[23:05] <jimbaker> we like sharing - generally that means just using - jruby's work
[23:05] <jimbaker> ;)
[23:06] <lopex> we're really happy since our regexp engine is being included in nashorn
[23:06] <jimbaker> since our own resources are fairly inadequate
[23:06] <jimbaker> lopex, i remember looking at that a while ago, the only problem is that python has a fairly demanding regex requirement, so for now we are sticking with our port of that
[23:09] <lopex> jimbaker: the indy subject was hot again since topaz numbers appeared
[23:11] * msavy (~msavy@redhat/jboss/msavy) Quit (Remote host closed the connection)
[23:11] <jimbaker> topaz is a great development. btw, alex gaynor is joining rackspace
[23:12] <jimbaker> i assume that's public :)
[23:12] <jimbaker> good, he tweeted that
[23:12] <lopex> hah
[23:13] <jimbaker> i was just in some meeting - we were talking jython vs pypy
[23:13] <jimbaker> but of course it's all good with different reasons for both

Index

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