Timestamps are in GMT/BST.
[0:02] * vIkSiT (~vIkSiT|2@unaffiliated/viksit) Quit (Quit: Leaving)
[2:06] * Oti (~ohumbel@adsl-89-217-97-146.adslplus.ch) Quit (Ping timeout: 245 seconds)
[2:10] * Oti (~ohumbel@adsl-89-217-123-227.adslplus.ch) has joined #jython
[2:36] * Oti (~ohumbel@adsl-89-217-123-227.adslplus.ch) Quit (Ping timeout: 272 seconds)
[2:46] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) has joined #jython
[6:35] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) Quit (Quit: Oti)
[7:22] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[8:12] <topi`> isn't concurrent.futures python 3.x only? I think it was introduced in python 3.3
[8:13] <topi`> it's similar to the java.concurrent.executors
[8:16] * jarekps (~jsmiejcza@office.clearcode.cc) has joined #jython
[8:25] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 268 seconds)
[8:25] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[9:01] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[10:49] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 248 seconds)
[10:52] <agronholm> topi`: it was introduced in python 3.2
[10:52] <agronholm> and that's what the "backport" was for :P
[10:54] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[11:04] * lheuer (~Adium@unaffiliated/lheuer) Quit (Quit: Leaving.)
[11:10] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[11:11] * lheuer (~Adium@unaffiliated/lheuer) Quit (Client Quit)
[11:57] * zz_whg is now known as whg
[13:28] * mcurve (~quassel@pop.nakinasystems.com) Quit (Read error: Connection reset by peer)
[13:29] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[13:58] * mcurve (~quassel@pop.nakinasystems.com) Quit (Remote host closed the connection)
[13:58] * mcurve (~quassel@pop.nakinasystems.com) has joined #jython
[14:13] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 272 seconds)
[14:14] * whg (whg@unaffiliated/whg) Quit (Changing host)
[14:14] * whg (whg@nat/ibm/x-fqeanmauiegrbwmr) has joined #jython
[14:17] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Ping timeout: 248 seconds)
[15:20] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) has joined #jython
[15:28] * robbyoconnor (~wakawaka@guifications/user/r0bby) has joined #jython
[15:28] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Client Quit)
[15:29] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) has joined #jython
[15:30] <jimbaker> re large collection literals - this is a simple fix that only works with flat large collections - a literal dict, list, set, tuple that is only composed of numbers and strings
[15:30] <jimbaker> so no nested collections
[15:31] <jimbaker> this still handles the actual cases i have seen in the wild
[15:31] <jimbaker> daenney, sounds good about using cpython for our startup script. yes, this imposes a dependency on cpython, so i suppose cygwin users will have to install
[15:32] <daenney> jimbaker: Or people simply go java -jar jython :)
[15:32] <jimbaker> daenney, that works in certain cases
[15:32] <jimbaker> such as singlejar'ing
[15:33] <jimbaker> so users can choose which one they want
[15:33] <jimbaker> but we are python guys. let's write the jython script in a language we really know & can test :)
[15:34] <daenney> Works for me
[15:34] <jimbaker> daenney, cool!
[15:34] <daenney> I can finally throw that bash nightmare away I created
[15:34] <jimbaker> long term, this will let us grow us more functionality as well related to nailgun like approaches
[15:35] <jimbaker> so as i mentioned earlier, it looks like the current ssl module as i have rewritten it will need to be rewritten once again
[15:36] <jimbaker> since pip, through requests, uses nonblocking ssl client sockets, which in java requires SSLEngine
[15:36] <jimbaker> this doesn't look so bad...
[15:38] <daenney> Pip is using requests now?
[15:38] <jimbaker> i was hoping that we were almost at 2.7 beta 2, but w/o this support, no pip. imho pip is a blocker for beta2
[15:38] <jimbaker> daenney, yes
[15:39] <daenney> Ah, I wasn't aware of that
[15:40] * sinistersnare (cddef8b0@gateway/web/freenode/ip.205.222.248.176) has joined #jython
[15:51] <jimbaker> on the bright side - we will have ssl support for nonblocking sockets :)
[15:51] <jimbaker> which twisted needs, for one
[15:57] <daenney> Yeah but Twisted is a bit... well what's in a name :)
[16:14] <jimbaker> daenney, it's not a priority for beta 2, but i personally need to see it happen. for real usage, we almost certainly want to use netty to support, since it's closer to twisted's model anyway
[16:15] <daenney> Sure :)
[16:16] <jimbaker> very cool, stefan richthofer has release jyni alpha 2
[16:16] <daenney> That the c-extensions layer right?
[16:16] <jimbaker> the interesting challenge, reading between the lines in his email to jython-dev, is that of gc
[16:16] <jimbaker> daenney, yes
[16:17] <daenney> Cool
[16:17] <jimbaker> basically jyni needs to bridge the refcounting world of c ext api with the java gc model
[16:18] <sinistersnare> yah i got that email, sounds cool
[16:18] <daenney> It sounds impossible
[16:18] <jimbaker> it is very much possible
[16:19] <jimbaker> the c extension api is very well defined and proven to be robust. the only challenge in the past was writing to it. but cython essentially solved that problem
[16:19] <jimbaker> the more interesting issue is addressing performance. we have somewhat more tricks at our disposal to tell the jvm our intent through sun.misc.Unsafe
[16:20] <sinistersnare> do things like numpy use cython?
[16:20] <jimbaker> sinistersnare, yes
[16:20] <sinistersnare> i keep hearing about sun.misc.Unsafe, and from what i have read, it feels really hacky
[16:21] <daenney> It's called Unsafe for a reason I guess
[16:21] <sinistersnare> yeah, but like, you have to access it through reflection
[16:21] <sinistersnare> that sort of thing
[16:22] <jimbaker> nahhh, sun.misc.Unsafe is cool - it is Unsafe but it allows you to access the underlying hardware in a portable fashion
[16:22] <sinistersnare> interesting
[16:23] <jimbaker> any high performance code in java seems to ultimately depend on sun.misc.Unsafe, or uses it. example: cassandra
[16:23] <sinistersnare> yeah Spring too
[16:23] <jimbaker> or of course java.util.concurrent
[16:24] <jimbaker> so one does not simply use sun.misc.Unsafe... but for the purposes of implementing language runtimes, it's fine
[16:25] <daenney> I wonder why people ever decided to call it Cassandra though. She was cursed by Apollo to be able to see the future but have no one believe her. So unless that's a statement about the data that comes out of it...
[16:26] <sinistersnare> I dont know, but my CS class is gonna end in like 1 minunte...so i have to go, talk to yall later!
[16:26] * sinistersnare (cddef8b0@gateway/web/freenode/ip.205.222.248.176) Quit ()
[16:27] <jimbaker> well, it does get in an interesting question, when we bring in python, which was slain by apollo, so he could take over the oracle at delphi..
[16:27] <daenney> :)
[16:30] <daenney> Eh, where did the jython sources go?
[16:31] <daenney> As in, version controlled something?
[16:31] <jimbaker> daenney, we are using a mirror at https://bitbucket.org/jython/jython
[16:32] <daenney> Ah, good. I just stumbled over wiki.python.org/jython which as pointing me to subversion
[16:32] <jimbaker> w/ the actual repo at http://hg.python.org/jython
[16:32] <jimbaker> daenney, yeah, wikis... sounds like the usual of not being up-to-date
[16:32] <daenney> Then your wiki is out of date :P
[16:38] <jimbaker> wow, reading jyni.org - plans to support ctypes as well
[16:40] <daenney> I wish `hg clone` would be a bit more informative. It's the one thing git does better :/
[16:40] <jimbaker> cannot wait until we can just do $ jython -m pip install jyni
[16:41] <jimbaker> i should add support for clamp to make that happen - just need the jars keyword support to describe such dependencies
[16:41] * srcerer_ is now known as srcerer
[16:44] <daenney> Damn how slow is that initial clone... :/
[16:59] <jimbaker> daenney, hg is not known for speed
[16:59] <daenney> Clearly, my clone is still going on :P
[17:00] <jimbaker> hg also occasionally just gets stuck
[17:01] <jimbaker> topi`, jeff allen has finished all/nearly all of the buffer support
[17:01] <jimbaker> so that's what has just landed in trunk
[17:03] <jimbaker> one thing i would like to see is some sort of support for a true PyByteString which uses 8-bit support and interoperates cleanly with byte[] arrays
[17:03] <jimbaker> maybe i'm describing jython 3.x
[17:03] <jimbaker> ...
[17:09] <daenney> 3.x sounds good
[17:14] <daenney> Dear god, I just cat'ed jython.bat
[17:15] <jimbaker> daenney, i imagine that's even more interesting...
[17:15] <daenney> Interesting is not the right word. I need a drink I think
[17:17] <jimbaker> wow, that's the first bat file i have looked at in a long time. that it even works is rather fascinating
[17:18] <jimbaker> essentially, when the only tool available is goto, it will have to be used
[17:19] <daenney> Uhu :)
[17:19] <jimbaker> so that's one more good reason for using cpython in this case
[17:20] <daenney> Yeah, kinda though I guess we could keep the .sh and .bat around for people
[17:20] <daenney> The .sh is showing some weird behaviour but I have no idea what the .bat does
[17:22] <daenney> It might be in perfect working order
[17:22] <jimbaker> that's the problem - we really don't want code like that because we *don't know*
[17:24] <daenney> Fair enough
[17:25] <jimbaker> Oti and nicholas riley are credited/blamed for jython.bat - Oti has been more active recently, but i think nicholas is doing other things these days
[17:25] <jimbaker> regardless, if we can have a single, tested piece of code for both, that would be good
[17:25] <jimbaker> both windows and non-windows
[17:26] <daenney> This will be python2.7+ though, otherwise I'll still have to deal with optparse and stuff :/
[17:27] <jimbaker> daenney, it's only python 2.7 for us :)
[17:27] <daenney> Yeah I know but people might not have that CPython version
[17:27] <daenney> Jython is easier, as long as you have the minimum required jvm
[17:28] <jimbaker> daenney, understood. however, if we require 2.7, we basically break out of these dependency issues. yes, we have pushed somewhat more work on the user. but if they need something simple, they can always have singlejar usage
[17:29] <daenney> True
[17:29] <jimbaker> i'm a big believer in correctness first
[17:30] <jimbaker> and usually it's really hard to get to correctness w/o testing. maybe it was ok to hand test in the past, but we need to move beyond that
[17:55] * agronholm (~agronholm@2001:1bc8:102:6f29:45c:50f5:7c99:7b48) Quit (Ping timeout: 264 seconds)
[17:59] * agronholm (~agronholm@2001:1bc8:102:6f29:c825:bc50:4247:937f) has joined #jython
[17:59] * ChanServ sets mode +o agronholm
[18:17] <daenney> Well, that was easy, jython.py now accepts the same arguments as the shell version
[18:53] <jimbaker> :)
[18:53] <jimbaker> i guess we just need to figure out portable ways to ensure that python 2.7 is selected by #! and whatever is the bat equiv
[18:58] * jarekps (~jsmiejcza@office.clearcode.cc) Quit (Quit: jarekps)
[19:01] <daenney> That's easy enough, /usr/bin/env python2.7 ought to do that
[19:01] <daenney> Though windows might be weird
[19:12] <daenney> jimbaker: DO you have any clue why the .sh does `cygpath -u JAVA_HOME` ? What's the point of doing that? It only does it if cygwin and if JAVA_HOME is set
[19:13] <daenney> But if JAVA_HOME is set, why the cygpath -u?
[19:13] <daenney> It seems redundant
[19:30] <jimbaker> daenney, no idea unfortunately
[19:30] <daenney> Well, we'll have to see when we run this on cygwin then
[19:31] <daenney> I'm still slightly confused about cygwin to begin with, Jython doesn't require it so...
[19:32] * jyc (~jyc@173.245.6.163) Quit (Ping timeout: 272 seconds)
[19:34] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 272 seconds)
[19:38] * jyc (~jyc@173.245.6.163) has joined #jython
[19:41] <daenney> jimbaker: SHould I use a branch or a bookmark? I tend to use named branches because of git but generally git's branches map to mercurial's bookmarks but I don't see those in the bitbucket ui :/
[19:43] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[19:44] <jimbaker> daenney, it really doesn't matter because we cannot merge directly
[19:44] <jimbaker> so whatever is easiest
[19:44] <jimbaker> i too would prefer git/github
[19:44] <daenney> Right, but if bookmarks don't show up then I guess branch it is
[19:45] <jimbaker> the problem is, bitbucket is where you can fork and do whatever
[19:45] <jimbaker> but hg.python.org is where we committers actually push
[19:45] <daenney> Oh wait, they do
[19:45] <jimbaker> it's an unfortunate workflow
[19:45] <daenney> Bookmark it is :)
[19:45] <jimbaker> not terrible, but it has speed bumps
[19:45] <daenney> Can't you move it over to bitbucket?
[19:46] <jimbaker> cool, re bookmarks. in the end, it's just a matter of hg diff
[19:46] <jimbaker> daenney, maybe. not right now
[19:46] <daenney> I wasn't saying now :P
[19:46] <jimbaker> if we go that far, we should just move to github imho
[19:46] <daenney> Depends, move to bitbucket should be easy, no repo conversion
[19:47] <daenney> Just update a bunch of links and put in an http redirect and you should be good
[19:47] <jimbaker> right
[19:47] <daenney> I thought mercurial could even deal with that so an hg clone/push wouldn'teven be affected in that case
[19:47] <daenney> Not sure though
[19:53] <jimbaker> daenney, perhaps - my hg fu is weak
[19:53] <daenney> Same, it's been a long time since I had to use it
[19:53] <daenney> Used to use it all the time, but my employer uses git so that changed things
[20:09] * lheuer (~Adium@unaffiliated/lheuer) has joined #jython
[20:16] * thereisnospoon_ (~thereisno@27-33-1-87.tpgi.com.au) has joined #jython
[20:18] * thereisnospoon (~thereisno@27-33-1-87.tpgi.com.au) Quit (Ping timeout: 240 seconds)
[20:33] * osc (~oscar@80-62-162-242-static.dk.customer.tdc.net) Quit (Ping timeout: 240 seconds)
[21:10] <daenney> jimbaker: Well, I'm off to bed but I did push this out: https://bitbucket.org/daenney/jython/commits/a7bd05e9bc8f2ab1f1e351d23074f8ab970d85bf?at=default
[21:14] <daenney> I have my doubts about find_jython mostly
[21:24] <daenney> I've already found a few things wrong with it, damn
[22:00] <jimbaker> daenney, also, we should share the find_jython code
[22:00] <jimbaker> so it can be reused by tools like clamp, see
[22:01] <jimbaker> https://github.com/jythontools/clamp/blob/master/clamp/build.py#L253
[22:01] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) has joined #jython
[22:01] <jimbaker> ok, let you sleep, i need to head out
[22:02] <jimbaker> Oti, btw, daenney has been looking at rewriting the bin/jython and bin/jython.bat scripts so they are in cpython
[22:02] <jimbaker> i think this is an ok dependency, and it will get us actual testability vs where are now
[22:02] <Oti> jimbaker, oh that's cool
[22:03] <Oti> these scripts are a constant source of sorrow
[22:03] <jimbaker> yes, agreed
[22:03] <Oti> (the old ones)
[22:03] <jimbaker> we know they can be written much better in python. plus, i think we can actually claim expertise in python ;)
[22:03] <jimbaker> i for one cannot say that of bash, and i know nothing of bat
[22:03] <Oti> me neither ;-)
[22:04] <jimbaker> cool, plus it opens up some interesting possibilities
[22:05] <jimbaker> Oti, btw, i'm starting to think about planning a visit to switzerland this coming summer, along w/ europython in berlin
[22:05] <jimbaker> but i have a meetup to go to, and we are carpooling, so ttyl!
[22:06] <Oti> jimbaker, see you
[22:26] * Oti (~ohumbel@adsl-178-39-179-157.adslplus.ch) Quit (Quit: Oti)
[22:28] * enebo (~enebo@c-75-73-8-169.hsd1.mn.comcast.net) Quit (Quit: enebo)
[22:45] <peke> daenney: jimbaker: i've looked at both jython.sh and jython.bat earlire and even fixed some bugs in the latter. and i totally agree they need to die.
[22:52] <peke> i also agree replacing them with cpython code has plenty of benefits, but there are also drawback.
[22:54] <peke> a good thing with cpython is that outside windows you can pretty much expect it to be available. in older machines you may not always have 2.7, though, and i would definitely consider supporting also older versions. supporting 2.5-2.7 isn't that hard anyway.
[22:56] <peke> outside windows you can also just name the script 'jython' without the '.py'.
[22:58] <peke> unfortunately on windows using cpython often means users need to install it first. and there the script needs to be 'jython.py'. both of these are, in my opinion, pretty big limitations.
[23:16] <peke> in jython 2.2 start-up scripts were still very simple. it was created by the installer with hard-coded paths to java and jython.jar. annoyingly needed to be updated if java was updated.
[23:17] <peke> weren't the scripts in 2.5 copied from jruby originally? what are they doing these days?
[23:21] <peke> how i think windows problems could be fixed is creating a separate binary launcher for that platform. for example autoit could be used for that purpose. it has a horrible, horrible scripting language, but being able to create stand-alone executable is pretty handy.
These logs were automatically created by JythonLogBot_ on irc.freenode.net using a slightly modified version of the Java IRC LogBot (github).