Timestamps are in GMT/BST.
[0:00] * shashank (~shashank@208.91.2.1) has joined #jython
[0:51] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 240 seconds)
[2:39] * whg is now known as zz_whg
[3:31] * dso__ (~dso@75-63-109-65.uvs.hstntx.sbcglobal.net) Quit (Read error: Operation timed out)
[4:08] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[6:07] * purplefox (~purplefox@host-80-43-252-143.as13285.net) Quit (Ping timeout: 240 seconds)
[6:15] * purplefox (~purplefox@host-80-43-252-143.as13285.net) has joined #jython
[7:34] * lheuer (~Adium@82.113.121.183) has joined #jython
[7:34] * lheuer (~Adium@82.113.121.183) Quit (Changing host)
[7:34] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[8:15] <topi`> any idea why the Modjy documentation says this: "You should also have jython installed and operational on your target system.
[8:15] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 240 seconds)
[8:15] <topi`> ...I thought the idea was that the .WARs are self-contained, thus the jython.jar comes in bundled. Then, there would be no requirement for a system-wide jython install.
[8:16] <topi`> (I'm still trying to find out why I get "Unable to import 'modjy_servlet' on some hosts)
[8:20] * thereisnospoon_ (~thereisno@27-33-1-87.tpgi.com.au) Quit (Quit: Leaving)
[8:22] <topi`> ...maybe this is because the Jython Registry needs to be found? and it only exists under JYTHON_HOME which is supposedly the local installation of jython.
[10:19] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[12:41] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 246 seconds)
[12:49] * zz_whg is now known as whg
[14:31] * Scorp1us (4b915e69@gateway/web/freenode/ip.75.145.94.105) has joined #jython
[14:31] <Scorp1us> where is jythponc? I just installed 2.5.3 and I don't see it. I selected option2
[14:38] <Scorp1us> restalled, option1, still don't see it
[14:42] <agronholm> Scorp1us: jythonc doesn't exist in 2.5 or any future release
[14:42] <Scorp1us> why not?
[14:42] <Scorp1us> need to output hard for hadoop
[14:43] <Scorp1us> er, output jars
[14:43] <agronholm> it's because its function was to convert python code to java and java cannot support certain new language elements introduced since python 2.2
[14:44] <agronholm> you can still produce .class files but they won't make much sense to java
[14:44] <agronholm> instead, ask jim baker on his progress on the "clamp" project
[14:44] <Scorp1us> do I can't use jython with hadoop?
[14:44] <Scorp1us> because I need to put jars on the cluster
[14:45] <Scorp1us> agronholm: what is wrong with the class files?
[14:48] <agronholm> well, python modules translate to .class files
[14:48] <agronholm> so they don't make a lot of sense to java
[14:49] <agronholm> open a .class file made by jython and you'll see
[14:51] <topi`> Scorp1us: jythonc was the "old" approach to the python/java interop problem but a long ago the jython developers decided to take another path (see the clamp project)
[14:51] <topi`> so jythonc is considered obsolete
[14:52] <Scorp1us> so i'm downgrading to 2.2
[14:52] <Scorp1us> because the new approach won't work for me.
[14:52] <topi`> a jython installation specific question: after creating a virtualenv, would it be a good idea to actually replace the jython.jar in JYTHON_HOME with the standalone version (which has Lib/ populated) ?
[14:52] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[14:53] <topi`> Scorp1us: oh, but you can't run many python modules on 2.2 (since it's obsolete)
[14:53] <Scorp1us> how obsolete is obsolete?
[14:53] <topi`> see, python 2.2 was introduced in 2001 or 2002
[14:53] <topi`> so, nobody has written any code/patches for py2.2 in about 10 years
[14:54] <Scorp1us> we're talking Jython 2.2,, not python 2.2 right?
[14:54] <topi`> jython 2.2 implements the python 2.2 language
[14:54] <topi`> so, no generators, definitely no with: statements
[14:54] <Scorp1us> so, what I don't get the ternary operator or lanbas.
[14:55] <topi`> the implication is that *very few* of the modern modules from PyPI work
[14:55] <topi`> that kind of negates the whole meaning of python
[14:55] <topi`> ok, I don't have time to lecture you, I need to do some real work
[14:55] <topi`> just understand this: you don't need jythonc, since what that accomplishes can already be accomplished by better means
[14:56] <Scorp1us> no, i need jars
[14:56] <topi`> look at it this way: even with jythonc, that wouldn't mean a working python interpreter, since you *need* the jython runtime (it's a dynamic language!)
[14:56] <topi`> you can't just compile a .py into a .class and expect it to work
[14:57] <Scorp1us> so tell me how to write jython mapreduce without using streams.
[14:57] <topi`> unless somebody comes with a statically typed .py (like RPython) , then it might work
[14:57] <topi`> why won't you write your mapreduce in javascript, like everyone else in NoSQL world?
[14:57] <topi`> or are you working with Hadoop, where js is no-go?
[14:58] <Scorp1us> hadoop
[14:59] <Scorp1us> I don't know java, but I know JS.
[14:59] <Scorp1us> I kinda got this job based on the promises of Jython
[14:59] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[15:01] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Excess Flood)
[15:03] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[15:06] <topi`> this is kinda odd. if I start java -jar jython.jar (in /dist):
[15:06] <topi`> '/home/topi/jyt/jython-ssl/dist/Lib/os.py'
[15:06] <topi`> and java -jar jython-standalone.jar :
[15:06] <topi`> '/home/topi/jyt/jython-ssl/dist/Lib/os$py.class'
[15:07] <topi`> (this is from import os; os.__file__
[15:07] <topi`> why does the -standalone work differently?
[15:08] <topi`> ah, now even the other one says that. So, after the first import, that .class gets created
[15:10] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Excess Flood)
[15:14] * r0bby_ (~wakawaka@guifications/user/r0bby) has joined #jython
[15:14] * r0bby_ (~wakawaka@guifications/user/r0bby) Quit (Remote host closed the connection)
[15:18] <topi`> odd. Created a virtualenv but now import distutils ends up in a java.lang.NullPointerException
[15:18] <topi`> however, import distutils works outside that venv, but using the same jython interpreter
[15:28] <agronholm> how do you launch jython in the virtualenv?
[16:21] <jimbaker> Scorp1us, you might want to look at pig, which does allow you to write map-reduce jobs using jython 2.5 right now
[16:22] <jimbaker> Scorp1us, i'm pretty certain my clamp project will also work for you. i haven't had time to focus on singlejar this week, but i usually find fridays very productive for the usual reasons
[16:23] <jimbaker> as for jythonc, it might work for you. i really don't know - i never used it. it's sort of an interesting oddity
[16:24] <Scorp1us> ah, thanks jim
[16:24] <Scorp1us> well, i'm writing a jython program that runs against hadoop.
[16:25] <Scorp1us> er hbase
[16:25] <Scorp1us> pig/hive in my experience is very slow
[16:25] <Scorp1us> at least in terms o UI/latentcy
[16:30] <jimbaker> Scorp1us, for what it's worth, if you need singlejar support this exact moment, you could try this program: https://github.com/rackerlabs/romper/blob/master/gen-storm-jar.py
[16:30] <jimbaker> it would need a very little modification
[16:30] <jimbaker> the relevant part is just putting together jars
[16:30] <vext01> jimbaker: I have emulated calling from python to prolog in jython now
[16:31] <vext01> next week in the reverse direction
[16:31] <jimbaker> the setup.py custom command singlejar does not use the jar command; and it's site-packages aware. so much slicker
[16:31] <vext01> then we can do some performance comparisons
[16:31] <jimbaker> vext01, very nice
[16:33] <vext01> in general the experience was very painless
[16:34] <vext01> i didnt need to write any java code really, the whole composition is in the python later calling out to Java at this stage
[16:34] <vext01> perhaps i will pay for performance for this.. we shall see
[16:35] <vext01> i may, for example, need to put type conversion at the java level...
[16:35] <jimbaker> vext01, depends on the code path. there's generally a way to avoid some performance hits. most notably by directly supporting PyObject wrappers around java
[16:36] <vext01> im hoping i can profile the code to see bottlenecks
[16:36] <jimbaker> so there are some hardcore users of jython who do this
[16:36] <vext01> jimbaker: would that be analegous to writing wrapped objects for pypy in rpython?
[16:36] <jimbaker> vext01, yeah, that sounds about right. basically there's no reflection overhead
[16:36] <vext01> so, in other words, at the interpreter level rather than the application level
[16:37] <vext01> yes, thats what we did for our other composition, albeit by necessity
[16:37] <vext01> jython has a really tempting inter-calling thing, which is a luxory :)
[16:38] <jimbaker> i have a pending project that i have mentioned here a couple of times, expose, that will enable this with very little work. but it's actually quite straightforward to do explicitly in java. just tedious
[16:39] <vext01> i see
[16:39] <vext01> i would like to revisit this jffi thing btw
[16:40] <vext01> i was a bit overloaded last time we spoke
[16:40] <jimbaker> the key takeaway is that if you give jython a class that extends PyObject (or some daughter type), it doesn't need to use reflection to adapt
[16:40] <vext01> do you plan to merge this stuff in to jython?
[16:41] <vext01> (and your ssl branch, btw :P )
[16:41] <jimbaker> vext01, i plan to do it even better than that for expose
[16:41] <jimbaker> it's going to be in pypi
[16:41] <vext01> nice
[16:41] <jimbaker> there's a small dependency that needs to be changed in core
[16:42] <jimbaker> but i want to keep clamp, expose, guava (google collection types, exposed as python types like dict), and other cool stuff out of core
[16:42] <jimbaker> so it can develop independently
[16:43] <jimbaker> as for ssl - yeah, as soon at is reasonable, i will merge
[16:43] <jimbaker> in
[16:44] <jimbaker> first need to finish clamp to a reasonable 0.1 level. ok, let me hack... :)
[16:48] <vext01> hehe
[16:48] <vext01> just found your twitter page, going to click "follow"
[17:01] <vext01> jimbaker: i have to go now, but perhaps we can talk about the jffi stuff another day?
[17:01] <vext01> i would be interested in packaging jython for openbsd if we can get jffi working
[17:03] <jimbaker> vext01, i don't actually know jffi too well, i'm just a user. it might be best to raise this issue on #jruby, or at least ask a jruby person
[17:04] <vext01> ok cool
[17:04] <vext01> will do
[17:05] <jimbaker> although it's almost certainly our own fault for including empty jars for bsd, etc
[17:09] <vext01> hehe
[17:09] <vext01> i want to avoid tons of dependencies and maven if atall possible
[17:14] <topi`> jimbaker: what kind of argument should I use for ClampProxyMaker() ? In your example, you use "bar", can I use fully qualified like "com.mycompany.acme" ?
[17:24] <vext01> also, bsd is a moving target, so i dunno how distributing a .so could work in long term ..
[17:28] <jimbaker> topi`, anything you want the package name to be prefixed with
[17:29] <jimbaker> vext01, yeah, that's a great question for the jruby guys. but i haven't used BSD (except the osx fork) for probably 15 years...
[17:31] <topi`> jimbaker: I copied your setup.py from clamped and modified it for my project, but setup.py buildjar created an empty jar (except for the MANIFEST.MF).. any idea why?
[17:33] <jimbaker> topi`, the key piece is to ensure it's searching for your modules
[17:33] <jimbaker> since it has to import them to actually build the proxies
[17:34] <topi`> jimbaker: what kind of magic does this "buildjar" do, since its output is a jar with .class files which clearly come from the python source which defines __proxymaker__?
[17:34] <jimbaker> topi`, the key piece of magic is its interaction with the ClampProxyMaker
[17:35] <topi`> so, if import ClampProxyMaker fails, then there will be no classes right?
[17:35] <jimbaker> topi`, correct
[17:35] <topi`> I can import clamp at least from jython command line
[17:36] <topi`> am not using virtualenv now.
[17:36] <topi`> (I did try using virtualenv initially, but found out that the way to make clamped work was to *not* use a venv)
[17:39] <jimbaker> topi`, yeah, i haven't started looking at virtualenv just yet
[17:39] <jimbaker> i'm sure it's a simple fix
[17:39] <jimbaker> and it will be there asap :)
[17:40] <topi`> the setup.py install phase installs the stuff correctly into ~/jython/Lib/site-packages
[17:40] <topi`> there is the __init__.py and associated .class
[17:40] <topi`> ha! now it worked!
[17:41] <topi`> what I did was: first I had an empty __init__.py and MyStuff.py and now when I renamed MyStuff.py to __init__.py (like clamped has), then it worked
[17:41] <topi`> I'm somehow used to put an empty __init__.py file into a dir so that I can do import foo.bar
[17:42] <jimbaker> topi`, you do need to have some sort of __init__.py for packaging
[17:42] <topi`> so it cannot be empty?
[17:42] <jimbaker> topi`, you should just be able to have an empty file
[17:42] <jimbaker> but it has to be there. however - i haven't looked at this case :)
[17:43] <jimbaker> as far as i know, the mechanism i use to resolve classes in the build phase is just using standard import logic
[17:43] <topi`> jimbaker: for now, I'll just go by placing my classes into __init__.py
[17:43] <topi`> maybe I made some trivial fault somewhere, but am blind to it
[17:43] <jimbaker> topi`, yeah, let's do what works, and i'll try out your case when i get around to it
[17:44] <topi`> anyhow, thanks for making this stuff work, it's amazing to watch it do its magic :)
[17:44] <jimbaker> topi`, when i add annotation magic, then that will be when we get into real interesting import stuff :)
[17:44] <topi`> with some mysterious proxy output from ClampProxyMaker on the standard output ;)
[17:44] <jimbaker> topi`, yeah, it's useful debugging output for me ;)
[17:44] <topi`> btw, why is there a serialVersionUID in the class?
[17:45] <topi`> wow, javac compiled my clamper!
[17:45] <topi`> (as expected, since the jar finally contains the class)
[17:45] <topi`> jimbaker: what I'm trying to achieve, is to create a servlet written in java, which creates a thread, and from that thread I'll be importing python classes
[17:45] <jimbaker> topi`, i should ensure that the class actually implements Serializable before placing that in
[17:46] <jimbaker> otherwise, from what i can tell, having serialVersionUUID=1 is almost always what one wants in the context of duck typing
[17:47] <jimbaker> nice, i even have a FIXME for checking Serializable
[17:47] <jimbaker> a message from the past jimbaker to the current jimbaker
[17:47] <vext01> jimbaker: oh, i built jffi
[17:47] <vext01> :P
[17:47] <vext01> cool
[17:48] <vext01> its this right:
[17:48] <vext01> https://github.com/jnr/jffi
[17:48] <vext01> sadly when i copy in the jar, jython no longer runs :P
[17:48] <jimbaker> vext01, yeah, that's the one
[17:48] <vext01> so more work yet
[17:48] <jimbaker> vext01, oh sounds like the usual updating stuff
[17:48] <topi`> jimbaker: you invented a time machine :) sometimes my brain overflows, and I need to check my cmd line history to see *how* I actually made/achieved something the past month
[17:48] <jimbaker> i'm sure it's a trivial update
[17:49] <vext01> http://paste.pound-python.org/show/sviUH74GSdK3ijgkilTn/ <- the error
[17:49] <jimbaker> topi`, indeed, that's what we are always doing :)
[17:49] <vext01> will debug it tomorrow
[17:49] <vext01> or soon, atleast
[17:49] <jimbaker> vext01, cool, yeah, don't worry, i believe in "soonish"
[17:50] <jimbaker> the only problem w/ jython is that we know what we need to get done. therefore, we are not certain when we will have it done ;)
[17:50] <jimbaker> feature-based dev, vs time-boxed dev
[17:50] <vext01> yeh time, nightmare
[17:51] <vext01> the jar has a single file inside
[17:51] <vext01> jni/x86_64-OpenBSD/libjffi-1.2.so
[17:51] <jimbaker> vext01, sounds right to me
[17:54] <topi`> jimbaker: we need to start hunting more corporate sponsors ;)
[17:54] <topi`> to hire one full-time guy releasing jython - that would help some
[17:55] <topi`> Exception in thread "Thread-12" java.lang.NoClassDefFoundError: foo/myworker/TestClamp
[17:55] <topi`> there it goes. I need to manipulate tomcat's classpath
[17:55] <topi`> hm, maybe just place the .jars into webapps/WEB-INF/lib ?
[17:56] <topi`> Exception in thread "Thread-13" java.lang.NoClassDefFoundError: org/python/core/PyProxy
[17:56] <topi`> slowly resolving what needs to be put into lib...
[17:57] <topi`> jython-standalone.jar should suffice?
[17:57] <jimbaker> topi`, i agree with that. but i'm glad rackspace is giving me a lot of time to work on this. in particular, the problems i'm solving to make python work on storm seem to be broadly useful. hence clamp
[17:58] <jimbaker> topi`, yeah you need the jython jars. iirc, jython-standalone may cause issues with site-packages usage
[17:58] <topi`> ah. the jar that buildjar creates doesn't actually have the .py file which I am importing from that java code ... so that needs to be in python.path
[17:59] <jimbaker> topi`, i find this little script super handy: https://github.com/jimbaker/clamped/blob/master/bin/alljars
[17:59] <topi`> right.
[17:59] <topi`> what are my options to set up python.path inside Tomcat? One would be to start Tomcat with the JYTHONPATH env variable...
[18:00] <topi`> how do I query python.path from the jython interpreter?
[18:01] <jimbaker> topi`, on my todo list is to look at tomcat. i know you mentioned this earlier w/ respect to war files and modjy. so modjy knows nothing about war files since it's somewhat more general
[18:01] <topi`> this seems to be on sys.path by default: '/home/topi/Lib'
[18:02] <jimbaker> topi`, correct, you would see python.path as sys.path in jython
[18:02] <topi`> jimbaker: war files are just a zipped tree, that can also be set up manually inside tomcat/webapps/
[18:05] * sinistersnare (6c1c5d99@gateway/web/cgi-irc/kiwiirc.com/ip.108.28.93.153) has joined #jython
[18:08] <jimbaker> topi`, right, just jars w/ some extra manifest info. i'm sure the django war support could extend to using singlejar as well
[18:08] <sinistersnare> im back! (jk i have to go, music auditions, and (american) football game!)
[18:11] <jimbaker> sinistersnare, sounds good, keep us posted on libgdx and jython
[18:16] <topi`> jimbaker: the problem with tomcat is that you have little or no control of things like JYTHONPATH environment variable
[18:16] <topi`> I guess I could set python.path from the java code which actually imports the clamped module...
[18:19] <jimbaker> topi`, understood. so i want to eliminate the use of JYTHONPATH type considerations and only support a standard site-packages/virtualenv type approach when working w/ django on jython :)
[18:24] <topi`> well, wouldn't it be possible to just ignore JYTHONPATH and start using standard PYTHONPATH ?
[18:24] <topi`> from jython's point of view
[18:24] <jimbaker> topi`, that's also a good idea. historically they have been separate
[18:25] <topi`> maybe that was to support using CPython at the same time?
[18:25] <topi`> Jython is an ancient project, and back then we didn't have virtualenv
[18:26] <topi`> although, ignoring JYTHONPATH is surely going to break half of existing jython appa
[18:26] <jimbaker> i have suggested on this channel earlier this week that we do some backwards breaking changes, such as os.name be what is now os._name
[18:26] <topi`> apps
[18:26] <jimbaker> yes, JYTHONPATH might be more radical
[18:26] <jimbaker> in any event, setting either PYTHONPATH or JYTHONPATH is really just for an older style usage
[18:29] <topi`> now I'm getting somewhere. If you put the python modules into tomcat7/webapps/mysite/lib/Lib then jython-standalone finds them
[18:30] <topi`> from clamp import ClampProxyMaker
[18:30] <topi`> ImportError: No module named clamp
[18:30] <topi`> can I just take the files/dirs under the clamp-0.1.egg and put them into Lib?
[18:30] <topi`> or maybe set up a .pth file that points to that .egg
[18:38] <jimbaker> topi`, that should be done in the setup.py process
[18:38] <jimbaker> in terms of setting up .pth
[18:38] <jimbaker> brb
[18:39] * cdleonard (~Crestez_D@205.168.23.154) Quit (Quit: Leaving.)
[18:40] <topi`> ah! PTH files are only processed if they are in the site-packages dir. Dang...
[18:41] <topi`> dummy solution: I just moved the clamp/ dir out of the clamp.egg/ and put that directly under Lib ... works!
[18:45] <topi`> jimbaker: is it so that if I modify that class which uses __proxymaker__, I need to go through setup.py install && setup.py buildjar again?
[18:54] * lheuer (~Adium@82.113.106.53) has joined #jython
[18:54] * lheuer (~Adium@82.113.106.53) Quit (Changing host)
[18:54] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[19:19] * Trundle (~andy@python/site-packages/trundle) has joined #jython
[19:34] * whg is now known as zz_whg
[19:42] * zz_whg is now known as whg
[19:43] <jimbaker> topi`, yes
[19:43] <jimbaker> topi`, my next step with this is to ensure that buildjar is executed as part of setup.py develop/install - it is possible to get this dependency working
[19:44] <jimbaker> also i plan to make the default location for jars that are output by buildjar go into site-packages so that one can use clamp for multiple packages, then combine together in one singlejar
[19:45] <jimbaker> topi`, i think it's rather ironic that my first pypi package is doing this sort of stuff :)
[19:50] <agronholm> jimbaker: have you run pyroma against clamp yet?
[19:51] <jimbaker> agronholm, i have not, but this looks super useful
[19:52] <agronholm> IMHO a score of 10/10 should be required for all PyPI submissions :)
[19:52] <jimbaker> i have participated in projects that use pypi, but i was not responsible for the pypi packaging :)
[20:22] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 240 seconds)
[20:34] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[20:45] <topi`> jimbaker: actually, I did modify the class which was __proxymaker__ defined, and it worked w/o any buildjar step.
[20:46] <topi`> I added a few print's there, and lo behold, when I stopped/started the servlet, I got those printouts
[20:47] <jimbaker> topi`, so long as the __proxymake__ definition is not changed and the class it extends and/or interfaces it implements, then you're fine w/o doing further buildjar
[20:47] <jimbaker> since everything is being dispatched through python code anyway
[20:47] <topi`> yeah
[20:47] <jimbaker> so a fine way to do it is buildjar; then jython setup.py develop
[20:47] <jimbaker> and just change
[20:48] <topi`> one remaining issue is the one where I created a war file using django-on-jython's manage.py war tool
[20:49] <topi`> and when deploying that to my OSX tomcat (brand new, installed via brew), I ran into the issue that the modjy servlet was not found. Or rather, the java part of it (modjyServlet.class) was loaded, but it couldn't find the python parts
[20:50] <topi`> and this had to do with the fact that for some reason, the jython.jar that was packaged into that .war (taken from my virtualenv) included very few bits in its Lib/ dir, and no modjy
[20:50] <topi`> which is kinda odd, since modjy has been integrated into jython since 2.5.x
[20:51] <jimbaker> topi`, yeah, we really need to revisit war support
[20:51] <jimbaker> i'm currently reviewing http://svn.python.org/projects/sandbox/trunk/setuptools/doc/formats.txt
[21:00] <topi`> jimbaker: I might fork django-on-jython and patch the war.py somewhat (I had to tweak it to get somewhere in the first place)
[21:00] <jimbaker> topi`, makes sense
[21:01] <jimbaker> and especially make it setuptools/virtualenv aware would make it totally rock
[21:01] <topi`> right.
[21:01] <topi`> most ppl would want to use virtualenv with django, anyways
[21:01] <jimbaker> at this point, yes
[21:01] <jimbaker> and if not, they should :)
[21:02] <topi`> when you bake the .war out of it, then of course it is self-contained in other ways and the virtualenv becomes irrelevant
[21:04] <jimbaker> topi`, right - only the manage.py integration needs to knows about it
[21:05] * dso__ (~dso@99-16-65-103.lightspeed.sprntx.sbcglobal.net) has joined #jython
[22:03] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[22:53] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 252 seconds)
[23:04] * Trundle (~andy@python/site-packages/trundle) Quit (Remote host closed the connection)
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).