#jython IRC Log (v0.9)

Index

IRC Log for 2012-03-19

Timestamps are in GMT/BST.

[0:12] * shashank (~shashank@75-171-236-198.hlrn.qwest.net) has joined #jython
[0:22] * jabley (u2487@gateway/web/irccloud.com/x-dcvnwaoajgvqqfjk) Quit (Quit: Connection closed for inactivity)
[1:12] * qmx is now known as qmx|sc2
[2:19] * qmx|sc2 is now known as qmx
[3:25] * Arfrever (~Arfrever@apache/committer/Arfrever) Quit (Quit: Ex??re)
[3:47] * qmx is now known as qmx|away
[4:01] * juneau001 (~juneau@50.44.13.106) Quit (Quit: Take care...)
[4:33] * r0bby (~wakawaka@guifications/user/r0bby) has joined #jython
[4:34] * robbyoconnor (~wakawaka@guifications/user/r0bby) Quit (Read error: Connection reset by peer)
[4:41] * r0bby is now known as robbyoconnor
[4:45] * qmx|away is now known as qmx
[5:49] * qmx is now known as qmx|away
[7:34] * shashank (~shashank@75-171-236-198.hlrn.qwest.net) Quit (Quit: Leaving.)
[8:15] <seletz> moin guys.
[8:24] <seletz> Is there a repo on github for jython?
[8:25] <seletz> oh, ok -- it's on bitbucket.
[8:26] <seletz> btw, someone should change the channel message to point to 2.5.3
[8:29] <seletz> OK, which magic commands do I need to clone from the bitbucket mirror? I get a "could not connect to server (https://svn.python.org) for the release27-maint branch.
[8:35] <agronholm> seletz: hg.python.org/jython
[8:35] <seletz> oh
[8:35] <seletz> agronholm: so the bitbucket one is dead?
[8:37] * seletz trying to clone
[8:38] <seletz> agronholm: ok, /me needs to do more RTFM
[8:41] <seletz> hmm. It seems that svn.python.org is down
[8:41] <agronholm> huh?
[8:42] <agronholm> hm
[8:42] <seletz> according to the wiki site i need to fetch the release27-maint/Lib branch from svn once to get the ssl certificate installed.
[8:43] * seletz thinks it should be easier to contribute to jytrhon ???
[8:50] <seletz> funny
[8:50] <seletz> the main cython repo appears to be on hg.python.org/cython
[9:02] <agronholm> seletz: I didn't have any trouble cloning jython when I did
[9:09] <seletz> agronholm: mhkay -- after cloning cython with hg I'm able to clone jython w/o errors. Strange.
[9:09] <seletz> ah, no -- wtf.
[9:12] <seletz> Well, **usually** I do not have these problems at all. I'm feeling like an idiot, not being able to clone a repo. This is insane.
[11:12] * juneau001 (~juneau@131.225.175.251) has joined #jython
[11:13] * juneau001 (~juneau@131.225.175.251) Quit (Remote host closed the connection)
[11:13] * juneau001 (~juneau@fess-116326.dhcp.fnal.gov) has joined #jython
[12:30] * juneau001 (~juneau@fess-116326.dhcp.fnal.gov) Quit (Read error: Connection reset by peer)
[12:34] * juneau001 (~juneau@131.225.24.76) has joined #jython
[12:36] * wainersm (~wainersm@189.61.204.85) has joined #jython
[12:56] * juneau001 (~juneau@131.225.24.76) Quit (Quit: Take care...)
[13:35] * enebo (~enebo@65-128-218-235.mpls.qwest.net) has joined #jython
[15:00] * shashank (~shashank@75-171-236-198.hlrn.qwest.net) has joined #jython
[15:49] * qmx|away is now known as qmx
[15:50] * stakkars_ (~tismer@p5DDB5D80.dip.t-dialin.net) Quit (Ping timeout: 244 seconds)
[15:50] * stakkars (~tismer@p5DDB5D80.dip.t-dialin.net) Quit (Ping timeout: 246 seconds)
[15:53] * stakkars (~tismer@p5DDB6769.dip.t-dialin.net) has joined #jython
[15:53] * stakkars_ (~tismer@p5DDB6769.dip.t-dialin.net) has joined #jython
[15:56] <fwierzbicki> seletz: the plan is to switch to an hg subrepo so we can get rid of the svn step - we just haven't done it yet
[15:56] <fwierzbicki> agreed that it should be easier
[15:57] <fwierzbicki> seletz: the bitbucket one is a mirror - so it isn't dead
[15:57] <seletz> fwierzbicki: ok -- I see
[15:57] <fwierzbicki> seletz: agronholm it seems to not be a problem for linux, but it causes trouble on windows and osx
[15:58] <seletz> fwierzbicki: so no mac developers here I guess?
[15:58] <seletz> I'd really like to contribute ...
[15:59] <fwierzbicki> seletz: there are but you only have to fix the svn issue once (and if you pointed at svn.python.org at any time in the past it also isn't a problem
[15:59] <fwierzbicki> )
[15:59] <seletz> hmm.
[15:59] <seletz> What about svn.python.org not responding? I tried the SVN info step as suggested in the WiKi
[15:59] <fwierzbicki> but we see it is a barrier (and it has annoyed me recently on a mac) so we'll fix it sometime soonish - I'm hoping to get to it this week
[16:00] <fwierzbicki> What I've heard from pjenvey is that the hg svn plugin gets stuck if the ssh domain hasn't been accepted
[16:00] <seletz> uargh
[16:00] <fwierzbicki> so it needs to be in .ssh/known_hosts for things to work
[16:01] <fwierzbicki> yeah ugly - and like I said we agree that its not really an acceptable situation
[16:01] <seletz> OK, that should be no problem -- anyone here knows the bublic key of svn.python.org?
[16:01] <seletz> public even :p
[16:01] * seletz can't type
[16:01] <fwierzbicki> seletz: do you need to get that manual - can't you have svn take care of that?
[16:03] <seletz> fwierzbicki: well -- I tried -- but svn can't get a connection to svn.python.org -- hence the problem. Or am I missing smth?
[16:03] <seletz> seems like chicken and egg to me ...
[16:03] <fwierzbicki> did it ask if you want to add it to known_hosts?
[16:03] <fwierzbicki> yeah - it's a pain
[16:03] <seletz> no
[16:03] <fwierzbicki> hmmm
[16:03] <seletz> it says "can't conect"
[16:04] <seletz> woho!
[16:04] <fwierzbicki> oh got it?
[16:04] <fwierzbicki> seletz: ^^^
[16:04] <seletz> almost :p
[16:04] <fwierzbicki> ah good :)
[16:04] <seletz> "issuer is not trusted"
[16:04] <seletz> (headbang)
[16:05] <fwierzbicki> hmmm
[16:05] <seletz> well, I'll do a RTFM on SVN (has been a very long time) -- there's surely a --fore or smth like that
[16:05] <seletz> however -- when I tried this morning It could not even connect.
[16:06] <fwierzbicki> seletz: if you'd prefer to wait a bit we really will switch to a pure hg solution - hopefully this week
[16:06] <seletz> fwierzbicki: mhkay, I'll try to wait ;)
[16:06] <fwierzbicki> :)
[16:06] <seletz> Can't we have a github repo?
[16:06] * seletz ducks
[16:06] <fwierzbicki> I just need to learn how exactly - can't be that hard
[16:07] <fwierzbicki> seletz: ha that ship has sailed :)
[16:07] <seletz> I guess so ;)
[16:07] <seletz> mhkay, /me needs to continue the deployment ??? :)
[16:09] <fwierzbicki> seletz: you know - maybe I'll push this up and figure this out today
[16:09] <fwierzbicki> can't be any harder than trying to help people through the svn issue
[16:10] <seletz> heh -- yes ;)
[16:12] <fwierzbicki> pjenvey: FYI I'm going to see about moving to an hg repo of CPython this morning - shashank: I'm late on reviewing your compiler patch - I'll finish that after I get the subrepo thing figured out.
[16:14] <shashank> fwierzbicki: no problem at all, I'm stuck with some college stuff so I won't be able to do anything for next 2 days.
[16:14] <fwierzbicki> shashank: good -- for me that is -- :) -- I'll be sure to have a review done before 2 days is up then
[16:22] <fwierzbicki> seletz: ah! svn.pyton.org is down
[16:22] <fwierzbicki> just saw the email thread
[16:22] <fwierzbicki> this doesn't change my goals for today
[16:22] <seletz> fwierzbicki: mhkay -- so I'm not an idiot.
[16:22] <seletz> phew ;)
[16:23] <fwierzbicki> (in fact it is another reason - no one cares that much about svn.python.org so it's getting quick attention)
[16:23] <fwierzbicki> s/it's/it's not/
[17:03] * qmx is now known as qmx|lunch
[17:16] <pjenvey> fwierzbicki - i suppose another option is to just check in the entire CPython lib dir (copied over)
[17:16] <pjenvey> pypy does that
[17:16] <fwierzbicki> pjenvey: ah that's a thought
[17:16] <fwierzbicki> it would be far less complicated
[17:17] <fwierzbicki> I'm trying it now and I'm not totally sure I'm doing it right - I may not be recording the proper CPython branch each time for each branch
[17:17] <fwierzbicki> I like the simplicity of just checking it in - it's what we used to do long ago
[17:18] <fwierzbicki> in the CVS days
[17:18] <fwierzbicki> shudder
[17:18] <pjenvey> =]
[17:19] <fwierzbicki> actually I really like the idea - that we we can move up the Lib version with clarity
[17:19] <fwierzbicki> s/that we/that way/
[17:20] <fwierzbicki> I could even go with pypy's naming convention "lib-python" and delete CPythonLib to signal the change
[17:21] <fwierzbicki> windows allows dashes in dir names right?
[17:21] <fwierzbicki> I can google that :)
[17:22] * lheuer1 (~Adium@blfd-4d082608.pool.mediaWays.net) has joined #jython
[17:24] * lheuer (~Adium@unaffiliated/lheuer) Quit (Ping timeout: 244 seconds)
[17:32] <seletz> fwierzbicki: dashes in names are ok, undersores, too ;)
[17:32] <fwierzbicki> seletz: :) thanks - I just wanted to doulbe check pypy's convention - but of course they are fine
[17:32] <seletz> fwierzbicki: what about security updates in the pure-python (upstream) part?
[17:32] <fwierzbicki> man I can't type today
[17:33] <fwierzbicki> seletz: we'll check them in as they happen
[17:33] <seletz> I don't know hg -- but in git you'd do a pull of the upstream repo and you'd be fine
[17:33] <fwierzbicki> seletz: I was about to do the same but in so many ways the direct checkin is simpler
[17:34] <fwierzbicki> it's just a step we'll need to add when rolling a release
[17:34] <fwierzbicki> a trivial one at that
[17:34] <seletz> so there are no changes in the pure-python part in jython wrt cython?
[17:35] <fwierzbicki> seletz: we copy over our changed files
[17:35] <seletz> __ugh__
[17:35] <fwierzbicki> but for the most part we use the originals
[17:36] <fwierzbicki> eventually we will check the changes into cpython itself - there is a plan to share the Lib/ between all implementations
[17:36] <seletz> so you're not tracking the changes in SCM, then?
[17:36] <fwierzbicki> we are currently
[17:36] <fwierzbicki> that's why we where hitting svn
[17:36] <seletz> well.
[17:36] <fwierzbicki> except for the ones we alter
[17:36] <fwierzbicki> but we re-merge them as we update
[17:36] <fwierzbicki> but yes it's not the best system ever
[17:37] <seletz> Then just separate out the pure python library to a separate repo, and add a symbolic link. no?
[17:38] <fwierzbicki> agronholm: has recently scripted some of the merging -- long term sharing is the right way to go
[17:38] <seletz> I mean -- submodules are a PITA in git, too.
[17:38] <fwierzbicki> seletz: yeah but then it will add back a barrier to new contributors
[17:39] <seletz> hmm
[17:39] <fwierzbicki> since the long term plan will be the perfect solution (Lib shared among all implementations) I'm ok with a crappier approach for now (just copy it as pypy does)
[17:40] <seletz> Well, I'm new to all this and don't know why you all do this, but manually merging stuff seems very scary to me.
[17:40] <fwierzbicki> seletz: not only scary but I giant PITA
[17:41] <fwierzbicki> it's more historic baggage than any kind of grand plan
[17:41] <seletz> I mean, I did this in pre-git pre-bitkeeper days when doing kernel development, but this was a PITA.
[17:42] <seletz> I'm currently managing very tiny projects -- but I'd never ever again want to do manual merges/tracking unless forced.
[17:42] <fwierzbicki> agreed - we'll get to a better place in the 3.x timeframe
[17:43] <seletz> mhkay -- I'll stop aruing, then ;)
[17:43] <seletz> s/aruing/arguing/
[17:43] <fwierzbicki> :)
[17:43] * qmx|lunch is now known as qmx
[17:43] <seletz> so well.
[17:44] * seletz fetches a beer
[17:49] <seletz> bah
[17:49] <seletz> -ENOBEER
[17:49] <seletz> ok, SIGWIFE | SIGCLD
[17:49] <seletz> see you.
[17:49] <fwierzbicki> later
[17:50] * seletz is now known as seletzzzzz
[18:01] * verterok (~ggonzalez@unaffiliated/verterok) Quit (Ping timeout: 265 seconds)
[18:09] * Oti (~ohumbel@adsl-84-227-119-134.adslplus.ch) has joined #jython
[19:43] <fwierzbicki> seletzzzzz: ok it's done - svn should no longer be a problem
[20:02] * shashank (~shashank@75-171-236-198.hlrn.qwest.net) Quit (Ping timeout: 244 seconds)
[20:11] * tikfreenode (znc@ec2-46-137-223-5.ap-southeast-1.compute.amazonaws.com) Quit (Ping timeout: 252 seconds)
[20:17] * shashank (~shashank@184-96-142-92.hlrn.qwest.net) has joined #jython
[20:28] * tikfreenode (znc@ec2-46-137-223-5.ap-southeast-1.compute.amazonaws.com) has joined #jython
[20:43] * qmx is now known as qmx|brb
[20:54] * juneau001 (~juneau@50.44.13.106) has joined #jython
[21:00] * qmx|brb is now known as qmx
[21:26] * shashank (~shashank@184-96-142-92.hlrn.qwest.net) Quit (Ping timeout: 244 seconds)
[22:17] * wainersm (~wainersm@189.61.204.85) Quit (Quit: Ex-Chat)
[22:31] * lheuer1 is now known as lheuer
[22:48] <pjenvey> jimbaker - do you remember having a conversation with raymond about identitydicts on jython a while ago?
[22:48] <pjenvey> raymondh
[22:51] <jimbaker> pjenvey, i do not recall this conversation. but is this for id/idstr?
[22:52] <jimbaker> look at mailing list discussion, not quite
[22:52] <pjenvey> as a replacement for [id(obj)] = val
[22:54] <jimbaker> pjenvey, sure, and it looks like this thread is most pertinent: http://mail.python.org/pipermail/python-ideas/2010-June/007301.html
[22:55] <pjenvey> right, i was refreshing my memory, one of the last things said was 'but jim baker doesn't think you need it'
[22:55] <pjenvey> obviously i disagreed being one of the people encouraging it
[22:55] <pjenvey> but i think i fell off the face of the earth for a few months started in jun 2012
[22:55] <pjenvey> 2010
[22:55] <pjenvey> and never followed up
[22:56] <jimbaker> ok, well i have no memory of this
[22:56] <jimbaker> i don't even read python-ideas :)
[22:56] <pjenvey> i got the impression he spoke to you in person
[22:57] <jimbaker> i know we spoke of many things... i will definitely read the thread in detail
[22:57] <jimbaker> pjenvey, one thing i did notice is that id/idstr currently have a sucky synchronized impl
[22:57] <jimbaker> so the multithreaded perf would be bottlenecked
[22:58] <pjenvey> right, that's why it would help any alt implementation w/ a moving gc
[22:58] <pjenvey> we have to do all this work to id()
[22:59] <pjenvey> if we abstract the internals away then we can just do something like IdentityHashMap, without all that cost
[22:59] <jimbaker> pjenvey, how much is id() currently a perf hit
[22:59] <pjenvey> i think it was originally proposed by the pypy guys because it was hurting pickle perf
[22:59] <pjenvey> the memoize dict or something was using it
[22:59] <jimbaker> pjenvey, ah yes, that would be the normal usage
[23:00] <jimbaker> in terms of graph preserving. i suppose in this case, the use of a sync IdentityHashMap could be hidden by our cPickle impl
[23:01] <pjenvey> yea. i had another use case, i tried to explain, with sqlalchemy
[23:01] <jimbaker> pjenvey, likewise
[23:01] <pjenvey> we basically degrade to using id() for hash on jython because the JVM's hash isn't unique
[23:02] <pjenvey> and then we suck
[23:02] <pjenvey> it was a very particular use case, but a use case regardless
[23:02] <jimbaker> looks like MapMaker can construct identity maps that are concurrent
[23:03] <jimbaker> pjenvey, indeed, this is what is used with weakKeys().weakValues() in the builder
[23:03] <jimbaker> http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/collect/MapMaker.html
[23:06] <pjenvey> right, we could definitely have a better impl. but of course something like sqlalchemy is still stuck w/ the crappy solution unless it ships a jar file w/ its pypi distrib (totally out of the question)
[23:07] <pjenvey> =]
[23:07] <pjenvey> well maybe one day we will propose it again and if we're lucky convince python-dev to include an identitydict in python 4.0 =P
[23:08] <pjenvey> i wonder how pypy does a unique hash
[23:09] <pjenvey> maybe it doesn't..
[23:09] * verterok (~ggonzalez@91.189.93.65) has joined #jython
[23:12] <jimbaker> worth asking on #pypy
[23:13] <jimbaker> at least we can make cPickle faster
[23:13] <jimbaker> in fact, it could be made a lot faster in general. along with struct packing/unpacking
[23:26] <jimbaker> pjenvey, re cPickle i was just reviewing the implementation, it does use a help class PickleMemo that apparently implements a IdentityHashMap
[23:27] <jimbaker> so no reliance on id() itself
[23:28] <jimbaker> (i'm pretty certain that System.identityHashMap would not be a bottleneck, as i understand it, the hash is cached in the obj header)
[23:33] <jimbaker> pjenvey, probably if we reworked load/save_type to use "polymorphic instructions" we would see some decent perf improvement in cPickle
[23:51] <jimbaker> pjenvey, looks like struct uses polymorphic instructions already, so that part looks good. probably - but we would need to do perf analysis here on a suitable benchmark to verify - this runs pretty well until it gets to to converting to/from String. definitely would prefer byte[]!

Index

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