#jython IRC Log (v0.9)

Index

IRC Log for 2013-10-30

Timestamps are in GMT/BST.

[0:00] * bru` (~bruno`@AMontsouris-652-1-86-95.w92-163.abo.wanadoo.fr) Quit (Ping timeout: 245 seconds)
[0:01] <peke> same launcher working both on windows and unixes out-of-the-box would be handy, but c++ is pretty low level. at least by c++ fu is too weak to hack it.
[0:02] <peke> outside windows cpython ought to provide most of the same benefits and would be a _lot_ easier to maintain.
[0:02] <sinistersnare> i think anyone who is looking to install Jython has CPython
[0:02] <peke> sinistersnare: not necessarily on windows.
[0:02] <sinistersnare> most generally
[0:02] <sinistersnare> at least, but youre right
[0:03] <sinistersnare> we could do it in nimrod, which compiles down to C then to native code :p
[0:03] <sinistersnare> and is python like!
[0:04] <peke> also, on windows the script needs to be named `jython.py`, extension cannot be dropped. somewhat annoying.
[0:05] <sinistersnare> what an interestingly annoying problem
[0:06] <sinistersnare> why not java?
[0:06] <sinistersnare> if youre installing jython, you have java
[0:06] <sinistersnare> and its cross platform
[0:06] <sinistersnare> its no scripting language though
[0:06] <sinistersnare> but can be used like one, somewhat
[0:06] * [Arfreve1] (~Arfrever@minotaur.apache.org) Quit (Quit: leaving)
[0:07] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[0:09] * [Arfrever] (~Arfrever@apache/committer/Arfrever) has joined #jython
[0:09] <peke> java is definitely there and would work on different platforms. finding stuff on the file system and command line argument parsing aren't its strongest use cases, but i guess that would be doable.
[0:10] <peke> i would be concerned about the start-up time, though. also, i'm not sure does java allow starting another process so that it can exit itself. having an extra jvm running wouldn't be nice.
[0:11] <peke> this could be prototyped, but i guess jruby folks would have used it if it was feasible. shame that enobo just quit, he probably would have known.
[0:12] * Arfrever (~Arfrever@apache/committer/Arfrever) has joined #jython
[0:13] <peke> sinistersnare: do you have experience from nimrod? could it really work?
[0:30] <sinistersnare> peke: i really dont, i spent a night setting up the compiler and writing a couple hello world scripts
[0:30] <sinistersnare> yes it may not be the fastest or the most elegant, but its there. C++ isnt amazing with its CLI parsing and stuff like that either :p
[0:33] <sinistersnare> i think that a ~4 second startup time is ok for an installer, its not that necessary (we are talking about an installer, right?)
[0:49] <peke> sinistersnare: no, we are talking about the launcher. current jython.sh and jython.bat are rather horrible. daenney has started porting them to cpython. that ought to work fine on unix platforms but i'm worried about windows users.
[0:50] <peke> not sure would requiring them to install cpython be that bad, though. the script being `jython.py` instead of `jython` would be annoying, but that could be possibly worked around with `jython.bat` that just calls `jython.py`.
[0:52] <peke> sinistersnare: definitely an interestingly annoying problem. anyway, i must go to bed. burnt too much midnight oil already.
[2:55] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) Quit (Quit: This computer has gone to sleep)
[3:04] <jimbaker> cpython also gets us easy functionality like daemonization. not as good as doing it in jython itself, but still useful
[3:22] <sinistersnare> yep CPython is good, but i think that the people who use jython will most likely have CPython or Java, so those are probably the 2 best options
[3:22] <sinistersnare> because its a startup script java might not be best
[3:22] <sinistersnare> so ist CPython (or C++ if you hate yourself :P )
[4:50] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[5:27] * valtih_ (~chatzilla@sushi.pld.ttu.ee) Quit (Ping timeout: 240 seconds)
[5:34] * valtih (~chatzilla@sushi.pld.ttu.ee) has joined #jython
[6:03] * valtih (~chatzilla@sushi.pld.ttu.ee) Quit (Ping timeout: 240 seconds)
[7:16] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[7:21] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) Quit (Quit: Oti)
[7:27] <daenney> peke: I don't do C++ I'm afraid :P
[7:30] <daenney> We could compile it down to javascript though with one of the LLVM backends and emscripten if that's any help
[8:23] * valtih (~chatzilla@sushi.pld.ttu.ee) has joined #jython
[9:03] <peke> daenney: i don't do c++ either. did you check jruby-launcher project introduction? their motivation to use c++ makes sense.
[9:05] <daenney> peke: Hmm, I guess. We could always use py2c or something similar :P
[9:06] <peke> for jython cpython is much more compelling, though. implementing executable detection and argument parsing only once would be great though. requiring windows users to install cpython starts to sound more and more appealing.
[9:08] <peke> the problem that on windows the launcher must be 'jython.py' can probably be solved well enough by having 'jython.bat' that runs 'jython.py' that is in the same directory with it.
[9:10] <daenney> Or we can simply ship a jython.py and have setuptools create the 'normal' jython script
[9:12] <peke> daenney: then users would need both cpython and setuptools.
[9:12] <daenney> Well, at least on *NIX they would
[9:13] <daenney> But then again, you always have setuptools in *NIX
[9:13] <peke> do you?
[9:13] <daenney> Yeah... Just about every distribution ships with setuptools
[9:14] <peke> ok. but on unix we don't have this problem anyway. the script can be just `jython` with correct shebang.
[9:14] <daenney> Most packages depend on it anyway
[9:14] <peke> this is, again, a windows only problem. did i already mention that i dislike that platform very much?
[9:16] <peke> daenney: if, on windows, you have `jython.bat` with content `@%~dpn0.py`, it will execute `jython.py` on the same directory.
[9:20] <peke> to pass arguments forward and to handle possible spaces in the directory path, the content actually needs to be this:
[9:20] <peke> @"%~dpn0.py" %*
[9:21] <peke> daenney: jimbaker: does this jython-launcher approach sound valid:
[9:22] <peke> 1) use cpython everywhere
[9:23] <peke> 2) on unixes, have 'jython' with '#!/usr/bin/env python' shebang
[9:24] <peke> 2) on windows, installer should create 'jython.py' instead. and it should additionally create 'jython.bat' with content '@"%~dpn0.py" %*'.
[9:55] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[10:18] * PRISMBITCH (~PRISMBITC@178-85-121-235.dynamic.upc.nl) has joined #jython
[10:58] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)
[11:01] * PRISMBITCH (~PRISMBITC@178-85-121-235.dynamic.upc.nl) Quit (Ping timeout: 252 seconds)
[11:12] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[11:16] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 252 seconds)
[11:48] * PRISMBITCH (~PRISMBITC@178-85-121-235.dynamic.upc.nl) has joined #jython
[12:05] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[12:14] * jarekps (~jsmiejcza@91.217.18.18) has joined #jython
[12:22] * sinsnare (cddef8b0@gateway/web/cgi-irc/kiwiirc.com/ip.205.222.248.176) has joined #jython
[12:29] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 264 seconds)
[12:35] * valtih (~chatzilla@sushi.pld.ttu.ee) Quit (Ping timeout: 268 seconds)
[13:03] * zz_whg is now known as whg
[13:08] * sinsnare (cddef8b0@gateway/web/cgi-irc/kiwiirc.com/ip.205.222.248.176) Quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client)
[13:10] * mcurve (~quassel@pop.nakinasystems.com) Quit (Remote host closed the connection)
[13:11] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[13:14] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[13:18] * clajo04 (~clajo04@pool-108-54-80-252.nycmny.fios.verizon.net) Quit (Quit: clajo04)
[13:28] * clajo04 (~clajo04@pool-108-54-80-252.nycmny.fios.verizon.net) has joined #jython
[13:48] * jarekps (~jsmiejcza@91.217.18.18) Quit (Quit: jarekps)
[13:54] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[14:12] * lheuer (~Adium@f049162108.adsl.alicedsl.de) has joined #jython
[14:12] * lheuer (~Adium@f049162108.adsl.alicedsl.de) Quit (Changing host)
[14:12] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[14:34] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[14:34] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[14:45] * jimbaker (~jbaker@unaffiliated/jimbaker) Quit (Read error: Operation timed out)
[14:55] * jimbaker (~jbaker@unaffiliated/jimbaker) has joined #jython
[15:11] <jimbaker> peke, sounds good to me re using cpython to write the launcher; we probably can write the script such that it's universal for python 2 or python 3, otherwise we can just do #!/usr/bin/env python2
[15:12] <jimbaker> one option if we are supporting python26 is to just bundle argparse
[15:14] <jimbaker> apparently red hat enterprise linux 5 still supports just python25
[15:14] <jimbaker> sorry, python 2.4 !!!
[15:18] <jimbaker> per https://pypi.python.org/pypi/argparse, we should have compatibility
[15:22] <jimbaker> lastly, if we just do #!/usr/bin/env python, i suppose we don't have to worry about 2 vs 3, or systems not yet implementing fully http://www.python.org/dev/peps/pep-0394/, which i assume is the case for RHEL 5
[15:24] <jimbaker> ok, sorry for thinking out loud: here's the proposed solution for the various un*x flavors - 1) shebang of #!/usr/bin/env python
[15:25] <jimbaker> 2) jython script is python2/3 compatible for 2.4 to 3.3
[15:25] <jimbaker> 3) attempts to import argparse, otherwise uses bundled argparse
[15:28] <jimbaker> note that jython can still be started up just with java with proper options; also it might be nice if the jython wrapper script could show the startup line; we could use the -J namespace for this purpose, right now it's just a passthrough to underlying java, but it could be more general than that
[15:30] <jimbaker> 4) for windows, we also have jython.py, which is exactly the same file as for un*x flavors, with jython.bat per the magic peke cited
[15:30] <jimbaker> daenney, peke, what do you think? seems to be getting closer
[15:32] <daenney> jimbaker: The current script has a --print that prints the eventual startup line
[15:32] <peke> jimbaker: sounds mostly very good.
[15:32] <jimbaker> i'm also wondering if we did have a cpython 2.7 around, we might be able to take advantage of it, per such solutions like execnet/rexec, but perhaps w/o the user having to be so aware
[15:32] <jimbaker> daenney, awesome
[15:32] <daenney> What do you want to do with execnet/rexec though?
[15:32] <daenney> Simultaneously launch multiple Jython's across different machines?
[15:33] <jimbaker> daenney, support for functionality like daemonization is what i have in mind
[15:33] <daenney> Oh right, I usually implement that myself using the double-fork trick
[15:33] <jimbaker> so there's a daemonize module in pypi that's widely used
[15:33] <peke> jimbaker: not sure is using argparse worth the effort. optparse is stil available in py3. could be easier to use it than bundle argparse.
[15:33] <daenney> Actually, we're going to hit more issues
[15:34] <daenney> I'm using os.path.exists() a few times, that's Python 2.7+
[15:34] <daenney> Or a different path function, don't remember which one exactly
[15:34] <peke> daenney: os.path.exists is old.
[15:34] <daenney> Gimme a sec
[15:34] <daenney> Aaah, subprocess.check_output
[15:34] <daenney> That's the one
[15:35] <daenney> THe cygpath trick
[15:35] <jimbaker> subprocess is available as of 2.4
[15:35] <daenney> I think we can avoid it completely, I don't see any reason to shuttle the path between cygin and ourselves
[15:35] <jimbaker> so check_output can be easily rewritten
[15:35] <daenney> subprocess.check_output isn't, that function is new
[15:35] <daenney> But, if we don't need to cygpath call we can avoid it entirely
[15:35] <peke> check_output is just sugar. easy to implement. also agree that special cygwin support should be removed unless absolutely needed.
[15:36] <daenney> And I don't see why we need the cygpath call. I haven't been able to determine it actually does something useful
[15:36] <jimbaker> yeah, the whole point of doing this in cpython is to let cpython figure out this stuff :)
[15:36] <daenney> So I'm going to ditch that one. It might have been needed for Bash to translate path formats between unix and windows
[15:36] <daenney> But CPython takes care of that just fine
[15:36] <jimbaker> daenney, yeah, i think that's the reason
[15:37] <jimbaker> my limited experience w/ cygwin - over 5 years ago - is that python scripts just ran fine
[15:37] <peke> about argument parsing: can the launcher actually use any parser? it only needs to handle some of the options and pass others forward without modifying them. wouldn't argparse et. al complain about options that jython itself should handle?
[15:38] <jimbaker> peke, you can readily delegate such options in argparse
[15:38] <daenney> argparse <3
[15:39] <jimbaker> but, it's probably best for the jython startup script to do a full parse
[15:39] <peke> i see. and it keeps order etc.? do you need to specify all arguments that are delegated?
[15:39] <jimbaker> org.python.util.jython is *not* a moving target
[15:39] <jimbaker> we control :)
[15:39] <daenney> I don't see why not
[15:40] <peke> current launcher (2.5) apparently handles only -Jarg, --jdb, --print , --profile, --boot, and --
[15:41] <jimbaker> yeah, so if it instead knew all options, that would be best imho
[15:41] * sinistersnare_ (cddef8b0@gateway/web/freenode/ip.205.222.248.176) has joined #jython
[15:41] * sinistersnare_ is now known as sinsnare
[15:42] <peke> -Jarg ought to be easy -- just delegate them to java. could the others also get a special prefix so that they could be easily detected in arguments?
[15:42] <peke> such a namespace would also ease adding new special launcher arguments in the future.
[15:43] <peke> what i mean is having something like -Ljdb, -Lprint, ... instead of the current ones.
[15:43] <jimbaker> peke, we actually own the -J namespace per GvR's pronouncement
[15:45] <peke> i see. it would be convenient if java args and launcher args had separate namespaces, though.
[15:45] <peke> easy to parse and also to document.
[15:45] <jimbaker> right now, it's very easy to differentiate because it looks like -J-XX:+UseG1GC
[15:45] <daenney> Java args do, since we own -J
[15:46] <jimbaker> so any java args always have -J-whatever
[15:46] <daenney> You just go -J-Xwhatevr -J-Xsomethingelse -J-Xhavealapdance
[15:46] <peke> should launcher args be moved under -J too? -Jjbd, -Jprint, ...
[15:46] <jimbaker> peke, probably
[15:46] <jimbaker> i don't even know if this is any documented anywhere
[15:47] <daenney> What launcher are we talking about now?
[15:47] <jimbaker> hence my finding out about --print, which may be from jruby
[15:47] <daenney> THis is getting confusing
[15:47] <jimbaker> daenney, still talking about the jython launch script
[15:47] <daenney> jython.py --print should not become jython.py -Jprint, that doesn't make sense
[15:48] <peke> aren't the current launchers based on old jruby launchers? functionality like --print probably originates from there.
[15:48] <peke> daenney: why not?
[15:48] <daenney> peke: because --print will give you the complete java command line we'll use to luanch your jython instance
[15:48] <daenney> the JVM has no clue about that
[15:48] <daenney> Or well it might, but that's not where we're getting it from
[15:49] <daenney> jython.py assembled a command for you, --print print that command
[15:49] <jimbaker> nice, just doing jython --help does mention --print, --jdb, etc
[15:49] <jimbaker> i sort of remember advising the use of jython --boot as well
[15:50] <daenney> If it's something that needs to be passed to jython.jar or the jvm we need a prefix, if it's something handled by jython.py itself I don't see why we'd add a prefix
[15:50] <jimbaker> so i think we should continue to support these launch options. it is documented after all, just my faulty memory
[15:50] <jimbaker> daenney, good point
[15:51] <jimbaker> i think the only concern is that we want to conform to cpython as much as possible. but probably only make sense for short options
[15:51] <peke> not having a prefix can be a problem if python gets an option with same name
[15:51] <daenney> No it won't
[15:52] <daenney> I can have a -v or a -d just fine in my script without ever getting intertwined with the python interpreter's -d or -v
[15:52] <daenney> If that would be the case scripts like this would be entirely impossible without everyone confining themselves to some namespace for everything
[15:52] <jimbaker> cpython only takes two long options, --version and --help
[15:53] <daenney> It doesn't matter what options cpython takes. If I don't pass them through, they won't take
[15:53] <daenney> jython.py --help does not print python --help
[15:54] <peke> daenney: my point was that if cpython gets a new option, most likely jython should get it too. launcher having that option would be at least confusing.
[15:54] <jimbaker> daenney, correct. that would be surprising :)
[15:54] <daenney> peke: Sure, but then we'd need something like -J/--java for JVM and -j/--jython for jython
[15:55] <daenney> I don't know, that's going to become weird pretty quickly
[15:55] <peke> daenney: that was what i proposed with -L (--launcher)
[15:56] <daenney> Ooh right
[15:56] <peke> but then jimbaker noted that we own -J.
[15:56] <jimbaker> yes, please don't add any new short options
[15:57] <jimbaker> i think we can be safe to continue to use long options. certainly any that are used right now
[15:57] <daenney> Sure, -J, but then what? You'd need to put logic in there to switch if it's a java option or a jython options
[15:57] <jimbaker> daenney, which is fine
[15:57] <daenney> Would mean maintaining a const in the script with the different commands though which is a bit icky imho
[15:58] <jimbaker> since it's extraordinarily clear, if it's -J-whatever, it's a java option
[15:58] <jimbaker> it is sort of unconventional, but it has worked
[15:58] <peke> daenney: launcher could check all -J options. it would then handle certain specially (-Jjdb, -Jprint) and pass other directly to java.
[15:59] <peke> not any more complicated than now checking all options, then handling -Jarg, --jdb, --print, etc. specially.
[16:00] <jimbaker> having -Jprint be a synonym for --print is not bad
[16:00] <peke> not having --print at all would make the new launcher lot simpler.
[16:00] <jimbaker> it also means we have a reasonable way of adding new options in the future
[16:00] <jimbaker> peke, sure, but i do know --boot is in use
[16:01] <daenney> peke: What's the issue with --print, exactly?
[16:01] <peke> is backwards-compatibility important with these options? this is a new major release after all. likely to require other changes also.
[16:01] <jimbaker> peke, i tend to prefer not unnecessary breaking
[16:01] <jimbaker> although we will have to require java 7
[16:02] <jimbaker> from my reading of SSLEngine, that's required
[16:02] <daenney> That's not a bad idea anyway, seeing how maintained Java 6 is
[16:02] <jimbaker> exactly. i didn't want to arbitrarily make this change
[16:02] <jimbaker> but now there's a strong supporting reason
[16:03] <daenney> Java 6 is a security disaster waiting to happen anyway
[16:03] <jimbaker> daenney, right. there's some usage on 32 bit os x
[16:03] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[16:03] <jimbaker> and apple continues to maintain java 6 for this purpose
[16:03] <peke> jimbaker: i don't like unnecessary breaking either. but keeping -Jprint and --print wouldn't make sense, imho. only supporting the former in the new launcher would ease implementing it. if the latter is kept, it needs to be implemented too. implementing the former is then just extra work.
[16:03] <jimbaker> but that's too hard for us
[16:04] <daenney> 32bit Mac OS X means hardware older than 2008 approx
[16:04] <peke> jimbaker: there's always jython 2.5 for java6. good riddance.
[16:04] <daenney> What is the issue with --print already?
[16:04] <jimbaker> peke, agreed on that!
[16:05] <peke> daenney: what issue you mean?
[16:05] <daenney> Why do you want --print gone?
[16:05] <daenney> I don't get it
[16:05] <peke> wouldn't that ease implementing the launcher?
[16:06] <jimbaker> i think it's a pretty minor thing
[16:06] <peke> removing all --options from it.
[16:06] <jimbaker> we are assuming argparse and its power :)
[16:06] <daenney> jython.py --print != java jython.jar --print, jython.jar doesn't even have a -p/--print
[16:06] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[16:07] <daenney> And I don't like the idea of removing all --options since --optiions are far more clearer in their intent then single case siwtches
[16:07] <jimbaker> daenney, correct, we also assume that jython.jar only gets certain options
[16:07] <daenney> Yes
[16:08] <jimbaker> daenney, i think that's why we have the --options in the first place
[16:08] <peke> daenney: i do understand that "jython.py --print != java jython.jar --print"
[16:08] <daenney> Then why do you want it gone / changed to -Jprint?
[16:08] <jimbaker> anyway, i think we can all agree this is a fairly minor aspect :)
[16:08] <daenney> -Jprint would indicate the option gets either passed on to the JVM or jython.jar, neither of which is the case
[16:09] <daenney> And I need to catch a bus
[16:09] <peke> daenney: to have all launcher options under -J.
[16:09] <jimbaker> daenney, actually i don't want -J to assume that
[16:09] <jimbaker> it says so in the --help
[16:09] <jimbaker> but it really only makes sense for -J-whatever
[16:10] <peke> it's get if argparse can handle also the current situation easily. didn't know that.
[16:10] <jimbaker> this instead should mean, *jython specific options*, some of which pass through to underlying java
[16:11] <jimbaker> users of jython expect a certain degree of higher-level usage of java
[16:11] <peke> having everything that launcher should handle under -J would also ease implementing possible jython.exe.
[16:11] <jimbaker> peke, as someone who has hacked a lot on argparse in the past, i know we can make it do what we ewant
[16:11] <daenney> Then we need to figure out how exactly you want the commandline to behave before I go any further with this :)
[16:12] <jimbaker> daenney, i don't know if i would prefer the plan over real, working code :)
[16:12] <peke> daenney: isn't that the reason why we are having this discussion? =)
[16:13] <jimbaker> instead, code can be used to figure out the actual details. the usual
[16:13] <daenney> ~~bus
[16:13] <peke> if there are changes, they should be done now.
[16:13] <jimbaker> daenney, catch the bus :)
[16:13] <peke> dinner here. bye.
[16:14] <jimbaker> cool, i think we resolved all the important aspects just now. we will figure out the relatively minor aspect of -Jprint vs --print (i would like both), later
[16:17] * PRISMBITCH (~PRISMBITC@178-85-121-235.dynamic.upc.nl) Quit (Ping timeout: 240 seconds)
[16:19] <sinsnare> im in class :p
[16:19] <sinsnare> CS intern this period, i update the website for 5 minutes, then screw around :p
[16:20] <sinsnare> i think what i might try to do with libgdx and jython is a particle game! http://www.badlogicgames.com/wordpress/?p=1255
[16:20] <sinsnare> that particle editor is awesome (and by game i mean some physics thing thats fun :))
[16:27] <sinsnare> well class just ended, bye!
[16:27] * sinsnare (cddef8b0@gateway/web/freenode/ip.205.222.248.176) Quit ()
[16:34] * vIkSiT (~vIkSiT|2@c-71-204-168-245.hsd1.ca.comcast.net) has joined #jython
[16:34] * vIkSiT (~vIkSiT|2@c-71-204-168-245.hsd1.ca.comcast.net) Quit (Changing host)
[16:34] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) has joined #jython
[17:08] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[17:08] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) Quit (Quit: This computer has gone to sleep)
[17:27] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Max SendQ exceeded)
[17:27] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[17:43] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) has joined #jython
[17:58] <jimbaker> sinistersnare, sounds great!
[17:59] <jimbaker> btw, don't forget to apply to univ of colorado at boulder, plus want your help for that cs course
[18:16] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)
[18:17] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) has joined #jython
[18:21] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[18:23] * lheuer (~Adium@f049162108.adsl.alicedsl.de) has joined #jython
[18:23] * lheuer (~Adium@f049162108.adsl.alicedsl.de) Quit (Changing host)
[18:23] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[18:29] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[18:39] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) Quit (Ping timeout: 240 seconds)
[18:42] <daenney> jimbaker: You wanted to use find_jython and find_java in different places too right?
[18:43] <daenney> In that case it's probably better to raise an error instead of going sys.exit()
[18:43] <jimbaker> daenney, if we can package up the jython script so that it's somewhat modular, that would be a good thing
[18:43] <jimbaker> it will also mean we can support testing
[18:44] <jimbaker> so it may mean, we should have jython.py, which is invoked by jython and jython.bat
[18:45] <jimbaker> what this means is that jython.py should be runnable by jython itself :)
[18:45] <jimbaker> even if it's usually cpython
[18:45] <daenney> Sure, I'll just raise a JavaNotFound and a JythonNotFound error instead, or would we prefer Exception, seeing as this is Java inspired? :P
[18:47] <jimbaker> daenney, i would generally prefer a builtin exception than create a new one, but it's really up to you
[18:47] <daenney> Hmmm, true
[18:49] <daenney> jimbaker: Any suggestion as to what I should use in this case?
[18:52] <sinistersnare> jimbaker: i am applying! i need to finish the suppliment essay, which i have a few days as the deadline is 11/15. and i sure can help with your course!
[18:52] <sinistersnare> email is sinistersnare@gmail.com if it is useful
[18:52] <jimbaker> sinistersnare, cool
[18:54] <jimbaker> daenney, it's an interesting question - http://docs.python.org/2/library/exceptions.html#exceptions.EnvironmentError might work, such as OSError
[18:54] <jimbaker> it's sort of a file not found type thing
[18:55] <jimbaker> http://docs.python.org/2/library/exceptions.html#exceptions.RuntimeError may be even more appropriate, despite the comment about not being used much any more
[18:55] <daenney> Mmm, but shouldn't RuntimeError be limited to errors in the Python runtime itself, versus 3rd party code?
[18:55] <daenney> I'm afraid RuntimeError is going to make people freak out
[18:55] <jimbaker> yeah, but this is very much part of the python runtime and not at all third-party :)
[18:56] <jimbaker> hence my desire to use standard exceptions
[18:56] <jimbaker> this launcher is for all intents and purposes for most people, jython
[18:56] <daenney> How so? I'm trying to find a file? The fact that I can't find it doesn't seem to justify raising an error signifying there's something wrong in Python's internals
[18:57] <jimbaker> so it's some of jython runtime error. just a question of which one
[18:57] <daenney> Mmmm
[18:57] <jimbaker> so no need to answer this question now... especially since i need to get lunch...
[18:57] <jimbaker> :)
[18:57] <daenney> Ha, enjoy
[19:01] * sinistersnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) Quit (Quit: Lost terminal)
[19:06] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) has joined #jython
[19:09] * sinistersnare (~sinisters@pool-108-28-93-153.washdc.fios.verizon.net) has joined #jython
[19:13] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Ping timeout: 246 seconds)
[19:20] * sinistersnare is now known as sinsnare|away
[19:37] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[19:58] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Read error: Operation timed out)
[20:21] * cameron__ (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 240 seconds)
[20:34] * cameron__ (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[20:50] <daenney> Well, looks like I've got find_jython and find_java working correctly
[21:08] <daenney> jimbaker: https://bitbucket.org/daenney/jython/src/a3b4e140f79cf4db042c2398fc16b0df3d1802b6/src/shell/jython.py. Comments welcome
[22:04] <peke> jimbaker: shouldn't jython.py be just jython outside windows? /cc daenney
[22:04] <daenney> Sure
[22:06] <peke> daenney: jimbaker: for what it's worth, i'd use RuntimeError in the launcher.
[22:06] <daenney> Have a look at the commit I linked ;)
[22:06] <peke> daenney: already looked. =) just wanted to comment i'd use it too.
[22:07] <peke> is there a reason you log the error and then raise exception w/o message? why not just raise the exception w/ message?
[22:08] <peke> other random comments/questions before heading to bed (it's 00:07 here)
[22:09] <peke> - why don't you just use os.getenv instead of your own getenv?
[22:10] <daenney> Because I forgot that one existed
[22:11] <daenney> And the raeson I log the error is so that people get output on the console
[22:11] <daenney> But I should pass a message in the exceptions too
[22:12] <peke> hmm, could you just catch the exception in the main method and print it out then?
[22:12] <daenney> I could but that wouldn't help
[22:12] <daenney> Or, well, hmm
[22:13] <peke> traceback probably isn't that interesting anyway.
[22:13] <daenney> I need to be able to differentiate between the different RuntimeErrors but the message should be able to tell me that
[22:13] <daenney> It's a bit icky though to inspect the message and then based on that log something
[22:14] <daenney> I also don't see any reason why I wouldn't log at the place the error actually occurs
[22:14] <peke> - how are you planning to use check_java_version? i hope not everytime jython.py is run. starting java process just to check the version every time would slow down the already slow start-up time unnecessarily.
[22:14] <daenney> java -version doesn't spin up a complete JVM, that's plenty fast
[22:14] <peke> daenney: inspecting the message definitely is icky. why do you need to differentiate errors?
[22:15] <daenney> Because of the user
[22:15] <daenney> It's nice to inform them what to do
[22:15] <daenney> At one time there's an environment variable wrong, the other means we simply can't find stuff
[22:15] <peke> daenney: java -version is anyway waste over 99% of times.
[22:15] <daenney> java -version takes 0.02s to run here
[22:16] <peke> isn't the cause reported in the logged/printed message?
[22:16] <daenney> Loading CPython is also a waste of CPU, but we're still doing it because it's convenient
[22:16] <daenney> And I'd rather tell the user they use the wrong Java version instead of have them get weird errors because of it later on
[22:17] <daenney> Unless jython checks that itself
[22:17] <peke> if jython is compiled to java7, it probably won't start with older.
[22:18] <peke> but java version should be checked by the installer.
[22:18] <daenney> What if people don't use the installer? I don't
[22:19] <peke> you used brew, right? i would assume jython 2.7 would have java7 as a dependency there.
[22:20] <daenney> No, because brew doesn't ship Java
[22:21] <daenney> It also would error if you have java6 and 7 installed and your JAVA_HOME points at 6
[22:27] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[22:47] <vIkSiT> hello all
[22:48] <vIkSiT> when deploying a jython app to tomcat, apparently it can't find the modjy_servlet
[22:48] <vIkSiT> now, i see I have to set the python.home variable
[22:48] <vIkSiT> but what do i point it to?
[22:53] <sinsnare|away> vIkSiT: why not the jython install directory?
[22:53] * sinsnare|away is now known as sinistersnare
[22:58] <topi`> vIkSiT: it's tricky business to be able to set python.home correctly for tomcat. I gave up and just put my modjy_servlet into WEB-INF/lib
[22:58] <topi`> and WEB-INF/lib/Lib (which jython will default to if no python.home defined)
[22:59] <topi`> you *can* define python.home, by tweaking CATALINA_OPTS
[23:10] <jimbaker> daenney, hmmm, agreed java -version is fast. we can look at once we actually make the change in the build.xml what is reported by jython at startup
[23:11] <jimbaker> but java -version is not as fast as starting up cpython to actually do something
[23:17] <jimbaker> daenney, re distutils.spawn - i was thinking we would just use os.exec, but i could see the utility of a parent process relationship in maybe some cases - perhaps to provide extra services like daemonization or nailgun like support; if we did do nailgun we would want to secure with a named pipe
[23:19] <vIkSiT> sinistersnare, hmm, I'm having the worst luck installing jython-ssl 2.7 as an installer
[23:20] <vIkSiT> how do you recommend installing it?
[23:21] <vIkSiT> topi`, ah
[23:29] <sinistersnare> vIkSiT: its not to be used as an installer for now, jimbaker could probably explain how :p. i just cloned the repo locally with mercurial and built it with ant
[23:31] <jimbaker> vIkSiT, well, to be honest i don't recall the issues, but it's really intended to be used as a stop gap issue for knowledgeable people. i believe it could be used as an installer, but if you wanted to distribute a jar, just use clamp
[23:32] <jimbaker> installer is more of fwierzbicki's sort of thing
[23:32] <jimbaker> Oti might know as well
[23:32] <jimbaker> actually any of the committers besides myself ;)
[23:33] * whg is now known as zz_whg
[23:46] * maxb (maxb@skeeter-mxisp.mxtelecom.com) Quit (Quit: leaving)
[23:46] * maxb (~maxb@jabberwock.vm.bytemark.co.uk) has joined #jython

Index

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