Timestamps are in GMT/BST.
[0:14] * ttmrichter (~ttmrichte@221.232.82.218) has joined #jython
[0:36] * thobe (~Adium@70-89-156-205-Oakley.hfc.comcastbusiness.net) Quit (Quit: Leaving.)
[1:12] * jimbaker (~jbaker@64.134.11.248) has joined #jython
[1:43] * lopex (lopex@chello089076044027.chello.pl) Quit ()
[2:10] * jimbaker (~jbaker@64.134.11.248) Quit (Quit: jimbaker)
[2:58] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) has joined #jython
[3:11] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[5:32] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Read error: Connection reset by peer)
[5:33] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[5:41] * thobe (~Adium@70-89-156-205-Oakley.hfc.comcastbusiness.net) has joined #jython
[6:12] * lheuer (~heuer@blfd-4d08fc48.pool.mediaWays.net) has joined #jython
[6:20] * thobe (~Adium@70-89-156-205-Oakley.hfc.comcastbusiness.net) Quit (Quit: Leaving.)
[6:25] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) Quit (Quit: jimbaker)
[6:47] * lheuer (~heuer@blfd-4d08fc48.pool.mediaWays.net) Quit (Ping timeout: 245 seconds)
[7:04] * mds1 (~seiler@131.220.126.195) has joined #jython
[7:04] * mds1 (~seiler@131.220.126.195) has left #jython
[7:10] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) has joined #jython
[7:17] * agronholm (agronholm@nblzone-211-17.nblnetworks.fi) Quit (Ping timeout: 265 seconds)
[7:47] * agronholm (agronholm@2001:1bc8:102:413a:484:3c13:933f:246a) has joined #jython
[7:51] * agronholm (agronholm@2001:1bc8:102:413a:484:3c13:933f:246a) Quit (Client Quit)
[7:52] * hpk (~hpk@HSI-KBW-085-216-105-248.hsi.kabelbw.de) has joined #jython
[7:56] * agronholm (agronholm@nblzone-211-17.nblnetworks.fi) has joined #jython
[9:22] * azazel (~user@88-149-140-4.dynamic.ngi.it) has joined #jython
[9:23] <azazel> hi all
[9:30] * lucian (~lucian@188-222-55-189.zone13.bethere.co.uk) has joined #jython
[10:54] * azazel (~user@88-149-140-4.dynamic.ngi.it) Quit (Ping timeout: 258 seconds)
[10:54] * azazel (~user@88-149-140-4.dynamic.ngi.it) has joined #jython
[11:04] * juneau001 (~juneau@FESS-116326-2146591-dp.dhcp.fnal.gov) has joined #jython
[12:09] * lucian_ (~lucian@188-222-55-189.zone13.bethere.co.uk) has joined #jython
[12:09] * lucian (~lucian@188-222-55-189.zone13.bethere.co.uk) Quit (Ping timeout: 276 seconds)
[12:46] * verterok (~ggonzalez@unaffiliated/verterok) has joined #jython
[12:58] * lheuer (~heuer@unaffiliated/lheuer) has joined #jython
[13:01] * jimbaker (~jbaker@64.134.11.248) has joined #jython
[13:02] * verterok_ (~ggonzalez@unaffiliated/verterok) has joined #jython
[13:04] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Ping timeout: 265 seconds)
[13:31] <agronholm> jython seems to lack os.tmpname, os.tempname and os.tmpfile
[13:31] <agronholm> any particular reason? it's not like this isn't available in the JRE
[13:31] * sgithens (~sgithens@149-166-10-223.dhcp-in.iupui.edu) has joined #jython
[13:36] * sgithens (~sgithens@149-166-10-223.dhcp-in.iupui.edu) Quit (Ping timeout: 265 seconds)
[13:43] <azazel> jimbaker: i would like to help the porting of jython to android, but i must say that i'm a complete newbie in java land... i'm more accustomed to cpython, c/c++, make and emacs style of tools rather than java, ant and eclipse... that said, i want to "get in" this "world" so, i think it's just a matter of being accustomed to them
[13:44] <jimbaker> azazel: it's a perfect reason to work on an open source project, to learn new skills
[13:44] <agronholm> is there a version of objectweb-asm for dalvik?
[13:45] <jimbaker> :)
[13:45] <agronholm> or how do you plan on generating dalvik bytecode
[13:45] <jimbaker> that's one reason why i wrote the python bytecode vm
[13:45] <jimbaker> so we wouldn't have to
[13:45] <agronholm> hm?
[13:46] <azazel> i've checked out jythondriod just to see if it was in a "compilable" state... but i have not yet managed to compile it... f**k, eclipse is full of complaints....
[13:46] <jimbaker> jython, as of 2.5.0, has a builtin virtual machine for executing python bytecode
[13:46] <jimbaker> unfortunately we haven't gotten around to the point of writing a compiler for it - although a perfectly good one exists (cpython 2.5 ;) )
[13:47] <agronholm> I'm confused
[13:47] <agronholm> a vm on top of a vm?
[13:47] <jimbaker> of course
[13:47] <agronholm> won't that slow it down a lot?
[13:47] <jimbaker> why not? we have other VMs in jython
[13:47] <agronholm> I know regexes are built on a vm
[13:47] <jimbaker> sre (the regex engine) and cPickle are the other two
[13:48] <jimbaker> so yes it's slower. but the idea was to allow for the following:
[13:48] <jimbaker> 1. dynamic compilation for applets or other situations where we cannot create bytecode on the fly
[13:49] <jimbaker> 2. large methods
[13:49] <jimbaker> 3. environments like dalvik
[13:50] <jimbaker> the expectation would be that users would try to precompile their app as much as possible (ideally through distutils/distribute support of setup.py)
[13:51] <jimbaker> the other big thing is java integration - we need to do is support advance compilation of proxies OR support dynamic proxies (but that only works for interfaces)
[13:52] <jimbaker> re speed - it's actually not so slow on (ridiculous) benchmarks, so it's plenty fast
[13:52] <jimbaker> pystone = silly benchmark :)
[13:53] <agronholm> well compared to cpython it's really slow
[13:53] <agronholm> jython that is
[13:53] <agronholm> anything I run takes usually a few times longer than on cpython
[13:54] <azazel> jimbaker: have you ever tried to setup a "compilation toolchain" (ant build script?) targeting dex? If understand correctly the missing piecese are that proxy stuff _and_ some compilation glue of choice
[13:54] <jimbaker> it depends. it is easier to integrate in java speedups
[13:54] <jimbaker> azazel: correct, the biggest missing piece is the proxy support
[13:55] <jimbaker> this needs to be integrated in the standard compilation toolchain provided by distutils - and the related project, distribute
[13:56] <jimbaker> i would recommend any tool chain work should target distribute
[13:56] <agronholm> you mean distutils2?
[13:56] <agronholm> distribute is history
[13:56] <agronholm> it's maintained, sure, but all dev effort is concentrated on distutils2, which hopefully will make into python 3.2
[13:57] <jimbaker> sorry, not keeping up with the names here ;)
[13:57] <azazel> doh, distribute is ok for now, i use it everyday
[13:57] <agronholm> distribute and distutils2 are semantically different
[13:57] <agronholm> distribute is an add-on for distutils, while distutils2 is a whole new implementation of all that stuff
[13:58] <azazel> yeah, i know
[13:58] <azazel> but still i have too many holes to fill;-)
[13:58] * azazel really needs matrix's uploads
[13:59] <jimbaker> :)
[14:00] <jimbaker> getting packaging right is not too easy. i'm thinking of attending tarek's mini summit in dijon france in a couple of months to hash some of these ideas out
[14:00] <jimbaker> agronholm: where in the world are you btw?
[14:00] <agronholm> Finland
[14:00] <azazel> unfortunately i need to go out now, but i hope to come back here
[14:01] <azazel> tarek is pushing hard with that stuff
[14:01] <jimbaker> azazel: sounds good, you're asking some great questions and you've got the right background to help here
[14:01] <jimbaker> azazel: same question, where are you located?
[14:01] <jimbaker> (i'm in colorado)
[14:02] <azazel> northern Italy, in the dolomits
[14:02] <jimbaker> azazel: nice! one of my favorite parts of the world. as might be expected, i really like mountains
[14:05] <jimbaker> so again android is something we have long wanted to get working. we have even parked jyborg.com for this future eventuality
[14:05] <azazel> ah, one of the many places to see, if i'll be able to peace my brain with my heart and finally decide to make a trip to the 'states... i love mountains too
[14:05] <agronholm> jython has to get a lot faster to be usable on mobile devices
[14:06] <azazel> i wonder even what can i do to help... do you have any "code read guide" for latest jython sources?;-)
[14:06] <jimbaker> maybe the bigger issue is memory footprint - we need to look at stripping our jars
[14:07] <agronholm> that too
[14:07] <azazel> one step at a time, i think... speed is secondary at this point, for me
[14:07] <jimbaker> azazel: probably you want to look at PyBytecode (this is the implementation of the python bytecode vm)
[14:07] <jimbaker> and the proxy makers
[14:08] <azazel> jimbaker: thanks for now
[14:12] <jimbaker> azazel: sounds good - check out the sources here, https://jython.svn.sourceforge.net/svnroot/jython/trunk/jython/
[14:13] <azazel> jimbaker: of course ;-)
[14:14] * thobe (~Adium@70-89-156-205-Oakley.hfc.comcastbusiness.net) has joined #jython
[14:15] <jimbaker> agronholm: where do you personally see bottlenecks in jython code? (there are many, of course)
[14:15] <agronholm> I haven't profiled the code or anything
[14:15] <agronholm> but it seems that just about everything is slower
[14:16] <agronholm> startup is the most noticeable one (even with skip-cache)
[14:17] <jimbaker> agronholm: hard to do anything about jvm startup costs without doing stuff like nailgun. but i suspect we need to pay a lot more attention to jython's specific startup overhead
[14:17] <jimbaker> although that's just going to have wait for 2.6 dev
[14:17] <agronholm> java apps generally start pretty fast on my box
[14:19] <agronholm> cpython comes up instantly, jython takes between 2 and 3 secs to start up
[14:19] <jimbaker> still, there might be something really stupid we're doing at startup. worth doing some profiling i guess before we ship 2.5.2
[14:19] <jimbaker> what's jvm startup time on your box?
[14:19] <agronholm> how do I measure it?
[14:20] <agronholm> the jython version string is printed within 1-2 secs after pressing return, the command prompt comes up 1s after that
[14:20] <jimbaker> just time a java hello, world app would seem like a good first approx
[14:22] <jimbaker> jython executes a basic run of its eval machinery right before that "command prompt"
[14:22] <agronholm> I did "time java Hello"
[14:22] <agronholm> but I dunno how to interpret the results
[14:23] <agronholm> real: 0.108s user: 0.040s sys: 0.020s
[14:24] <agronholm> this is a 2.4GHz core 2 duo
[14:27] <jimbaker> as you said, you have fast jvm startup - the wall clock time is about 0.1s, which is really about i/o here
[14:27] <jimbaker> maybe you get faster with SSD... i have no experience with that
[14:28] <jimbaker> (anyone who wants to contribute to jython dev can donate SSDs to the team ;) )
[14:29] <agronholm> it's all coming from the cache at point
[14:29] <agronholm> *at that point
[14:29] <agronholm> so if the jvm startup delay is negligible, what on Earth is jython doing for that 2-3 seconds then?
[14:30] <jimbaker> because we are certainly doing too many things nonlazily
[14:32] <jimbaker> we could do better than that, although i think we have to wait for 2.6 to really make some changes, since it would introduce some breaking api
[14:33] <jimbaker> we have too many publicly accessible fields, which need to be refactored to use accessors so we can do things lazily
[14:33] * verterok_ is now known as verterok
[14:36] <agronholm> who's in charge with the jython project these days?
[14:36] * skay (~skay@pat1.orbitz.net) has joined #jython
[14:36] <agronholm> s/with/of/
[14:39] <jimbaker> agronholm: frank wierzbicki remains the lead committer, but he's been very busy. recently i personally have more time, so i've been spending more time on it. it's a standard "unfunded" open source project, unfortunately
[14:40] <jimbaker> the good thing is, we have a reasonable number of committers who know the code in depth, so as people's time fluctuates, we are still able to make progress
[14:41] <jimbaker> i know you have expressed interest in helping out, which would be awesome
[14:42] <agronholm> I took a look at the grammar
[14:43] <jimbaker> hopefully it made sense!
[14:43] <agronholm> well, it's been a while since I used antlr
[14:43] <agronholm> I don't even know which antlr version this was made for
[14:43] <jimbaker> we made a big investment in going to antlr + going for complete cpython AST compliance
[14:44] <agronholm> wasn't something missing from it? something required by "coverage"?
[14:44] <jimbaker> but it has paid off in terms of being able to use mako, sympy, and i'm sure other libraries
[14:44] <jimbaker> the missing part in coverage is line number info
[14:44] <agronholm> jython-swingutils binding uses the AST pretty heavily
[14:44] <agronholm> you should take a look :)
[14:45] <jimbaker> agronholm: i think i looked at it way back, and i liked it. but i don't recall that AST part
[14:45] <jimbaker> but since i'm responsible for pushing our AST direction, i'm glad it worked out :)
[14:45] <agronholm> http://bitbucket.org/agronholm/jython-swingutils/src/tip/swingutils/binding/parser.py
[14:46] <agronholm> I wrote my candidate's thesis on this
[14:47] <jimbaker> some sweet metaprogramming, very nice
[14:48] <agronholm> it should be usable on cpython too if you drop the swing module
[14:48] <jimbaker> agronholm: unfortunately i need to go. let's talk later, but definitely this is the sort of thing i love to see
[14:48] <agronholm> although you'd have to write new wrappers for some other event system
[14:48] <agronholm> k, cya
[14:48] * jimbaker (~jbaker@64.134.11.248) Quit (Quit: jimbaker)
[14:54] * stakkars (~tismer@i577B4C19.versanet.de) has joined #jython
[15:03] * jabley (~jabley@87-84-49-84.absolutely2.mezzonet.net) Quit (Quit: jabley)
[15:04] * thobe (~Adium@70-89-156-205-Oakley.hfc.comcastbusiness.net) Quit (Ping timeout: 240 seconds)
[15:45] * ttmrichter (~ttmrichte@221.232.82.218) Quit (Ping timeout: 252 seconds)
[15:46] * jimbaker (~jbaker@c-67-173-240-173.hsd1.co.comcast.net) has joined #jython
[15:50] * azazel (~user@88-149-140-4.dynamic.ngi.it) Quit (Ping timeout: 258 seconds)
[15:58] * lopex (lopex@chello089076044027.chello.pl) has joined #jython
[16:04] <jimbaker> agronholm: the coverage email thread is here, http://markmail.org/thread/3e2npt2pupxlyamq - still seems relevant
[16:11] <jimbaker> i added this issue so we can track. no guarantees for 2.5.2, unless someone here wants to implement
[16:12] <agronholm> what exactly is the problem here
[16:12] <agronholm> doesn't antlr supply this information?
[16:13] <agronholm> *reads*
[16:15] <jimbaker> agronholm: antlr supplies it. we simply need to build an appropriate structure in PyTableCode
[16:15] <agronholm> well I have no clue what that is and how it works
[16:16] <jimbaker> the alternative is to use use an inspect after the fact. this is not so ideal, because it's possible it's not the same underlying bytecode
[16:17] <jimbaker> PyTableCode is how we implement code modules - or any script - in jython (well, excluding PyBytecode, which already has co_lnotab support)
[16:18] <jimbaker> i recommend decompiling a $py.class file to see what that actually looks like, using a tool like jad
[16:18] <agronholm> I've done that once
[16:18] <agronholm> looks pretty...funky
[16:19] <jimbaker> basically it's very similar to the marshaling of code objects in cpython, but laid out to work with the constraints of java bytecode
[16:19] <agronholm> this thing goes beyond my current knowledge, I'm not going to touch it
[16:19] <agronholm> I have other areas where I can actually contribute something useful
[16:19] <jimbaker> yeah, it's definitely only for people who work on - or want to work on - the compiler :)
[16:19] <agronholm> I discovered a couple days ago that none of the jython builtin functions export __module__
[16:20] <agronholm> which wrecked some of my unit tests in APScheduler
[16:20] <agronholm> and they aren't exported as builtins either
[16:20] <agronholm> but as reflected java methods
[16:20] <jimbaker> interesting. i remember fixing that for functions written in python
[16:21] <jimbaker> it was necessary to support zope interfaces
[16:21] <agronholm> well it should be fixed for builtin functions too
[16:21] <jimbaker> it would be nice to support with reflected functions :)
[16:21] <agronholm> dunno how to go about it though
[16:21] <jimbaker> if you want to work on a patch on that... it would be awesome
[16:23] <agronholm> I don't know how to do it
[16:23] <agronholm> given the zero amount of developer documentation, I can't be sure any of my guesses are right
[16:24] <sabi> just post a patch for review then
[16:24] <sabi> we all had to start somewhere :)
[16:24] <sabi> and the code is mostly pretty obvious.
[16:24] <agronholm> well I have to disagree on that
[16:25] <agronholm> sometimes methods return java types, sometimes PyObject
[16:25] <agronholm> what's with that?
[16:25] <sabi> java types is generally for internal use to avoid wrapping/unwrapping stuff.
[16:30] <jimbaker> in the absence of decent dev docs - there are some on the wiki - we just have to use #jython
[16:31] <jimbaker> btw, it might make sense to have a sprint at some point. this has worked well in the past, especially for introducing developers
[16:32] <jimbaker> i do recommend http://wiki.python.org/jython/JythonDeveloperGuide - there are useful nuggets here & there
[16:38] <jimbaker> seems like the relevant code to look at for reflected functions is in org.python.core.PyBuiltinCallable - certainly this is where I would start:
[16:38] <jimbaker> @ExposedGet(name = "__module__")
[16:38] <jimbaker> public PyObject getModule() {
[16:38] <jimbaker> return Py.None;
[16:38] <jimbaker> }
[16:40] <jimbaker> None seems to be a useful placeholder, but we certainly could do better. fortunately it's just a string, so it's easy to fix without creating unnecessary refs
[16:41] <jimbaker> above, it == __module__
[16:47] <agronholm> so
[16:49] <agronholm> why do almost none of the built-in modules have @ExposedGet etc annotations? those performance reasons?
[16:50] <agronholm> some modules inherit from PyObject, some don't
[16:57] <jimbaker> agronholm: we are not necessarily consistent
[16:58] <agronholm> I can see that :)
[16:58] <jimbaker> if it works, we tend not to update the code, because it takes a lot of time
[16:58] <agronholm> which way would you recommend for new modules
[16:58] <agronholm> the PyObject way?
[16:58] <jimbaker> follow the example of itertools or _csv
[16:58] * lopex (lopex@chello089076044027.chello.pl) Quit (Ping timeout: 260 seconds)
[16:58] * lopex (lopex@chello089076044027.chello.pl) has joined #jython
[16:59] <agronholm> neither of them inherits from PyObject it seems
[16:59] <jimbaker> you want to distinguish creating a type from creating a module
[16:59] <agronholm> oh I get it
[16:59] * jabley (~jabley@cpc1-farn4-0-0-cust318.glfd.cable.ntl.com) has joined #jython
[16:59] <agronholm> modules don't inherit from pyobject
[16:59] <agronholm> but containing classes do
[17:00] <jimbaker> not certain if that's quite right - the types contained by that module extend PyObject
[17:01] <agronholm> that's what I meant
[17:01] <agronholm> s/containing/contained/
[17:01] <agronholm> what does @ExposedGet do
[17:02] <jimbaker> allows for creating a python attribute
[17:02] <agronholm> but aren't they visible anyway if they're public
[17:02] <agronholm> that's what I did before and it seemed to work
[17:02] <jimbaker> http://wiki.python.org/jython/PythonTypesInJava for more info
[17:03] <agronholm> kk
[17:03] <jimbaker> well, it allow for more precise control. so per that doc: "It can be applied to a method that takes no arguments and returns a value, or to a field."
[17:03] <jimbaker> so just like a python attribute
[17:04] <jimbaker> our exposing system is pretty nice, and minimizes calling overhead. however it's more limited than our support for reflection. no support for static methods for example. so we use both
[17:05] <agronholm> but if modules don't inherit from PyObject
[17:05] <agronholm> can I still expect @ExposedX to work?
[17:05] <agronholm> on their methods
[17:05] <jimbaker> you need to expose the type
[17:05] <agronholm> but I thought the module isn't a type
[17:05] <jimbaker> yeah, we turn it into a type later
[17:05] <agronholm> now I'm confused
[17:06] <jimbaker> :)
[17:06] <jimbaker> basically we use jython's ability to work with java code seamlessly to import in
[17:07] <agronholm> so do I need to put some @Exposed... annotations to the module, even though none of the builtin modules have those?
[17:07] <jimbaker> so i'm not 100% knowledgeable about this specific path, but it's basically using the PyJavaType machinery
[17:07] <jimbaker> no you want to use the classdictinit pattern
[17:08] <agronholm> I have no clue how to "use the classdictinit pattern", sorry
[17:08] <jimbaker> just like in _csv or itertools or whatever
[17:08] <agronholm> or what it even means
[17:08] <agronholm> I can see that the module inherits from ClassDictInit, but that means nothing to me
[17:09] <jimbaker> so modules like _csv.java implements ClassDictInit
[17:09] <agronholm> yeah, so?
[17:11] <agronholm> how does this help me
[17:11] <jimbaker> it's just a relatively simple way of creating a python module written in java
[17:12] <jimbaker> so it has the same semantics as python modules
[17:12] <jimbaker> like having a __doc__, stuff like that
[17:12] <agronholm> yeah, but I still don't see how this helps me to add __module__ to module level functions
[17:14] * jbrendel (ae8fcb1e@gateway/web/freenode/ip.174.143.203.30) has joined #jython
[17:15] <jimbaker> well, we probably need to extend our logic that supports ClassDictInit such that it pushes the containing module name into that function
[17:15] <agronholm> that sounds about right
[17:15] <agronholm> where would that logic be?
[17:15] <jimbaker> jbrendel: nice blog post
[17:15] <jbrendel> Hello Jim! Josh Juneau suggested I talk to you about this...
[17:15] <jbrendel> Nice blog? Which one?
[17:16] <jbrendel> Oh, the Python optimization one? Thank you!
[17:16] <jimbaker> yes, http://blogs.mulesoft.org/easily-optimizing-python-extending-with-java/
[17:16] <jbrendel> Jim I had asked Josh about the performance roadmap for Jython. Maybe you know something about that.
[17:16] <jimbaker> thanks for pointing out the lack of .keys on java.util.Map
[17:16] <jbrendel> Apparently. JRuby performs really well...
[17:17] <jimbaker> i added it to http://bugs.jython.org/issue1631
[17:17] <jbrendel> (keys(): no problem... wait, that wasn't by design? Didn't know...)
[17:17] <jbrendel> ... and according to various benchmarks, Jython tends to be a bit slower overall. Or a lot slower, depending on the benchmark.
[17:18] <jbrendel> Is there a push or roadmap to work on this? Maybe look at what JRuby does that makes it go so fast?
[17:18] <jimbaker> lot slower tends to because we didn't implement something in java that should be
[17:18] <jimbaker> such as datetimes or decimals
[17:18] <jimbaker> rather ironic considering good support in java for this - but we need to have it be compatible
[17:18] <jbrendel> Right. But I think there's also something about new-class object creation? I think I recall reading something about that not being particularly fast right now.
[17:19] <jimbaker> our regex implementation also botches things for HTMLParser
[17:19] <jimbaker> object creation is expensive because we use ConcurrentHashMap to implement __dict__
[17:20] <jimbaker> this gets the concurrency right
[17:20] <jbrendel> Is that needed because of the lack of GIL?
[17:20] <jimbaker> yes, among other reasons
[17:21] <jbrendel> So, nothing that can be done about that, I guess?
[17:21] <jimbaker> basically it gets the python memory semantics right
[17:21] <jbrendel> Ok.
[17:21] <jimbaker> (i should plug our book here, http://jythonpodcast.hostjava.net/jythonbook/en/1.0/Concurrency.html#python-memory-model)
[17:21] <jbrendel> I guess the strategy has to be to avoid object creation wherever possible.
[17:22] <jimbaker> the real strategy is to have a smarter compiler and let the jvm do that for us ;)
[17:22] <jbrendel> Yes, your book: I wish I would have the time to read it, it seems to be extremely interesting.
[17:22] <jbrendel> Can you give me a hint to the roadmap, though? When is the next release for Jython scheduled and will that address some of the performance issues?
[17:22] <jimbaker> well, if you want to read one chapter, please read the one on concurrency
[17:23] <jimbaker> i would love the feedback
[17:23] <jimbaker> re roadmap - we are trying to close up a number of bugs. i should publish the list i made here about a week ago
[17:23] <jbrendel> Hah! Chapter 19? Yeah, I have that open in a tab already, waiting for some time to finally read it.
[17:24] <jimbaker> that would get us to a 2.5.2rc1
[17:24] <jimbaker> although we may have another beta before then
[17:24] <jbrendel> Are any of those bugs performance related?
[17:24] <jimbaker> most of the interesting bugs concern aspects of java integration
[17:24] <jbrendel> Ok
[17:25] <jbrendel> So, focus on performance is going to be 2.5.3? Or 2.6 even?
[17:25] <jimbaker> although i'm also hoping we can get stuff like readline completers in for 2.5.2
[17:25] <jimbaker> unless there's an obvious performance improvement, it's going to get deferred
[17:26] <jimbaker> perf = time sink, unfortunately
[17:26] <jbrendel> Yes. Reimplementing lots of stuff in native Java, I assume.
[17:26] <jimbaker> also, the real way to improve performance is to pull in stuff like invokedynamic
[17:27] <jimbaker> or work with the jruby team on a new compiler
[17:27] <jimbaker> there are certainly opps to improve performance via reimplementation
[17:28] * msacks (~msacks@cpe-76-171-107-90.socal.res.rr.com) has joined #jython
[17:28] <jimbaker> for example, the regex engine could be significantly sped up if we were to implement the "polymorphic instruction" model
[17:28] <jbrendel> However, as long as JRuby does much better in benchmarks than Jython, I need to have at least a rough idea of when performance is going to be addressed in some way or the other. To justify the continued use of Jython. I like Python and don't speak Java, but right now, if performance continues to be an issue for too long, there will be more push to re-implement parts of RESTx in native Java or even JRuby. I'd like to avoid that! :-)
[17:28] <msacks> sup folks
[17:28] <jimbaker> (basically this removes using the giant switch)
[17:29] <jbrendel> I mean, I don't speak Ruby. I do speak a little Java.
[17:29] <jimbaker> yeah, it's rather hard to compete against jruby directly. they have 3 fulltime working on jython dev
[17:29] <jbrendel> JRuby dev, you mean?
[17:29] <jbrendel> How many people are working on Jython?
[17:30] <jimbaker> sorry, jruby dev ;). the good thing is, we do actively collaborate with jruby. and the python community is much more supportive of jython than ruby is of jruby
[17:30] <jbrendel> I see.
[17:30] <jimbaker> we have about 8 active committers
[17:30] <jbrendel> Do the languages (Ruby and Python) have enough in common so that maybe you could build a common compiler backend, shared by both implementations?
[17:30] <jimbaker> but at any given time, only a few of us are working on it "actively"
[17:31] <jimbaker> (sun used to fun frank wierzbicki to work fulltime, but that ended last fall, as a result of the oracle acquisition)
[17:31] <jimbaker> s/fun/fund
[17:32] <jbrendel> I see.
[17:32] <jimbaker> jbrendel: we share some code with jruby, around such stuff as posix support. we have talked with them about joint work on a backend compiler
[17:32] <jbrendel> Who is funding the JRuby team?
[17:33] <msacks> anyone in here want an easy job? i need some extra hands on an open source project.
[17:33] <jimbaker> engineyard
[17:33] <msacks> im trying to hit my next milestone.
[17:33] <msacks> its for a very small, simple, jython project.
[17:33] <jimbaker> msacks: i saw your post about the jmx project, sounds cool
[17:33] <jbrendel> msacks: Wish I could help, but I also have an open source project, also Jython, and I also have milestones coming up. :-)
[17:33] <msacks> thanks jimbaker
[17:34] <msacks> no problem jbrendel
[17:34] <jimbaker> i also have an open source project, which is jython :)
[17:34] <msacks> haha
[17:34] <jbrendel> Hey, we are all in the same boat! :-)
[17:34] <msacks> thats a little more involved.
[17:34] <msacks> hard to find good devs to help.
[17:34] <jbrendel> Jim, do you think it might be possible to have a list of the low-hanging fruit, as far as performance is concerned?
[17:35] <jimbaker> my concurrency chapter talks a little about jmx, don't know if that's helpful or not
[17:35] <jbrendel> For example, if there is some implementation of datetime or something that should really be implemented in native Java, would it be possible to describe that so that it becomes a small, self-contained, easy to work on project for some volunteer developer who doesn't have much experience working inside of compilers/interpreters/jython?
[17:36] <jimbaker> jbrendel: we know the following - builtin types are substantially much faster
[17:36] <jbrendel> Right.
[17:36] <jimbaker> so yes, datetime or decimals are good candidates, with extremely extensive unit testing
[17:36] <jbrendel> So, the tests exist already? That's wonderful!
[17:37] <jimbaker> yes, we just use the CPython unit test suite
[17:37] <jbrendel> You would be able to say: Here is the Python code, we need to have that translated to native Java. And here are the tests... ?
[17:37] <jimbaker> with very small modifications - sometimes we have to do an explicit GC because of the lack of deterministic destruction
[17:38] <jimbaker> yes, that's correct
[17:38] <jimbaker> so for example, it would be really nice to have jodatime be the backing representation for datetime
[17:39] <jimbaker> there is a minor inconstitency - jodatime has a precision of as i recall of 1 millison, whereas python datetimes have a microsecond precision
[17:39] <jbrendel> Ok. I'm currently in the process of trying to get some local universities to consider the possibility of maybe (... enough disclaimers...) to work with me on contributing to some open source projects. Specifically, contributing to RESTx. However, if some of those Jython performance improvements benefit RESTx as well then I'd be happy to recommend for some students to maybe look at that as a project.
[17:39] <jimbaker> but since python datetimes are immutable, you can just use the pure python version if the user requests such precision
[17:40] <jbrendel> However, all of this is totally up in the air and not certain yet.
[17:40] <jimbaker> jbrendel: we would really welcome your involvement on this
[17:40] <jbrendel> Still, if there would be some smart students who could take a look at this, would it be possible to wrap the description, test cases and such up so that it would be easy for the students to work on this?
[17:40] <jimbaker> definitely
[17:40] <jimbaker> this is one of the reasons we want to move to 2.6
[17:41] <msacks> just as a question, whats the best freelancer marketplace for devs? ive been using elance.com but its overrun with spontractors (spam+contractors)
[17:41] <jbrendel> Ok. Well, at this point, don't hold your breath, I can't promise anything.
[17:41] <jimbaker> because implementing new modules is much easier than subtle java integration bugs
[17:41] <jimbaker> jbrendel: are you in sweden?
[17:41] <jbrendel> No, New Zealand.
[17:42] <jbrendel> Where are you?
[17:42] <jimbaker> i'm in colorado
[17:42] <jbrendel> Ah.
[17:42] <jbrendel> Why did you ask about Sweden?
[17:42] <jimbaker> thobe (tobias ivarsson) worked with me, through the google summer of code, he's from sweden
[17:42] <jimbaker> and i have been there a couple of times
[17:43] <jbrendel> I'm originally from Germany, but I never had a chance to visit any of the Scandinavian countries. :-(
[17:43] <jimbaker> got it
[17:44] <jbrendel> Ok, thank you very much! Talk to you later...
[17:44] <jimbaker> i came close to agronholm's finland once, i once took the ferry to talinn (estonia) on the way to europython in vilnius
[17:44] <jimbaker> jbrendel: sounds good! looking forward to your feedback
[17:44] <jbrendel> See you...
[17:44] * jbrendel (ae8fcb1e@gateway/web/freenode/ip.174.143.203.30) has left #jython
[17:45] <jimbaker> msacks: anyway, i hope the command completion stuff that we should have in 2.5.2 will be useful for your work
[17:46] <msacks> thanks jimbaker. i got a message from the list asking if i had it done first to commit back. do you no longer need it?
[17:46] <jimbaker> not certain what you mean here...
[17:47] * msacks reads your original email
[17:48] <jimbaker> so basically if you overload __dir__ for jmx objects, that could be interesting
[17:48] <msacks> i see.
[17:48] <jimbaker> http://docs.python.org/release/2.5.2/lib/completer-objects.html
[17:48] <msacks> what if the mbeanserver is changing its child objects though
[17:48] <msacks> such as with data grids
[17:48] <jimbaker> yeah, that what makes it cool :)
[17:49] <jimbaker> completely dynamic
[17:49] <jimbaker> and something you can imbue with some interesting smarts
[17:49] <msacks> indeed. easy? not so much.
[17:49] <msacks> i dont think it would be super difficult though.
[17:49] <msacks> time is my enemy.
[17:50] <msacks> i was thinking of using cmd2
[17:51] <msacks> for the auto-completion that is
[17:51] <msacks> the documentation is abhorrent, so i cant say where cmd2 supports that. but i know it does.
[17:52] <jimbaker> not familiar, but looks like it could be useful
[17:52] <jimbaker> autocompletion probably relies on readline support, just like ipython
[17:53] <jimbaker> ideally that's what we would be able to support
[17:53] <msacks> i believe so, yes.
[17:53] <msacks> jimbaker
[17:53] <jimbaker> in any event, i also need to take off
[17:53] <msacks> do you happen to have an example in jython of how you do tab capture?
[17:53] <jimbaker> sorry, very interesting discussion!
[17:53] <jimbaker> not yet, because we don't support it yet
[17:53] <msacks> ill do some more digging.
[17:54] <jimbaker> but we should have a working readline emulation pretty soon, exposing our JLine, i'm working on it :)
[17:54] <jimbaker> later
[17:54] <msacks> late
[17:54] * jimbaker (~jbaker@c-67-173-240-173.hsd1.co.comcast.net) Quit (Quit: jimbaker)
[18:00] * tristanbuckner (~tristan@38.99.42.113) has joined #jython
[18:37] * lheuer (~heuer@unaffiliated/lheuer) Quit (Quit: Closing Time)
[18:42] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) has joined #jython
[18:52] * jimbaker (~jbaker@c-24-8-39-78.hsd1.co.comcast.net) Quit (Quit: jimbaker)
[19:08] * jabley catches up
[19:08] <jabley> damn jimbaker left
[19:09] <jabley> anyone know whether replacing ConcurrentHashMap __dict__ with Cliff Click's implementation has ever been considered?
[19:18] * stakkars (~tismer@i577B4C19.versanet.de) Quit (Ping timeout: 246 seconds)
[19:25] * stakkars (~tismer@i577B44D0.versanet.de) has joined #jython
[19:25] * juneau001 (~juneau@FESS-116326-2146591-dp.dhcp.fnal.gov) Quit (Quit: juneau001)
[19:37] * jabley (~jabley@cpc1-farn4-0-0-cust318.glfd.cable.ntl.com) Quit (Quit: jabley)
[19:46] * jimbaker (~jbaker@97-124-179-137.hlrn.qwest.net) has joined #jython
[19:51] * stakkars (~tismer@i577B44D0.versanet.de) Quit (Read error: Connection reset by peer)
[19:57] * stakkars (~tismer@i577B634B.versanet.de) has joined #jython
[19:58] * jimbaker (~jbaker@97-124-179-137.hlrn.qwest.net) Quit (Quit: jimbaker)
[20:00] * pigletto (~pigletto@dui241.neoplus.adsl.tpnet.pl) has joined #jython
[20:29] * pigletto (~pigletto@dui241.neoplus.adsl.tpnet.pl) Quit (Ping timeout: 276 seconds)
[20:35] * lucian_ (~lucian@188-222-55-189.zone13.bethere.co.uk) Quit (Ping timeout: 265 seconds)
[20:42] * lucian (~lucian@188-222-55-189.zone13.bethere.co.uk) has joined #jython
[21:54] * moo_ (~quassel@herd37.twinapex.fi) has joined #jython
[21:54] <moo_> has there been any recent jython experiements on android?
[21:58] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Quit: leaving)
[22:19] * skay (~skay@pat1.orbitz.net) Quit (Quit: skay)
[22:22] * hpk (~hpk@HSI-KBW-085-216-105-248.hsi.kabelbw.de) Quit (Remote host closed the connection)
[23:08] * gqlewis (~gqlewis@h242.94.82.166.static.ip.windstream.net) has joined #jython
[23:45] * gqlewis (~gqlewis@h242.94.82.166.static.ip.windstream.net) Quit (Quit: gqlewis)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).