Re: [Python-Dev] Instructions on using git mirror
On 2009.02.27 09:48:17 -0600, Neil Schemenauer wrote: > On Fri, Feb 27, 2009 at 08:36:08AM -0600, Brad Miller wrote: > > when I get to the step git svn fetch I get the following error: > > zsh-% git svn fetch > > Permission denied (publickey). > > Network connection closed unexpectedly: Connection closed unexpectedly at > > /opt/local/bin/git-svn line 1385 > > > > > > Is there a prerequisite that I get some kind of ssh key pair setup with the > > svn repository? I thought that was only for committers. > > Sorry, the instructions don't work for read-only access. I've > updated them. You need to use: > > git svn init http://svn.python.org/projects/python/trunk > > for read-only access to SVN. I don't see any point to using Neil's complicated dual-remote git + git-svn setup if you don't have commit access. For that matter, as long as Neil's git mirrors work well, I don't see any point to using git-svn at all if you don't have commit access. The whole idea of Neil's scheme is that you can use (fast) git to pull changes from the git mirrors, and (slow but compatible) git-svn to push changes to svn. Neat and clever, but complex and possibly brittle. If you don't have commit access then you can't push changes to svn anyway, so you don't need the git-svn half of the setup, so you should just git-clone Neil's repo and be happy with the much simpler setup. -- David Riptondrip...@ripton.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] a suggestion ... Re: PEP 383 (again)
On 2009.04.30 18:21:03 +0200, "Martin v. Löwis" wrote: > Perhaps - the entire PEP is about Python 3 only. I don't know whether > PyGTK already works with 3.x. It does not. There is a bug in the Gnome tracker for it, and I believe some work has been done to start porting PyGObject, but it appears that a full PyGTK on Python 3 is a ways off. -- David Riptondrip...@ripton.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] How to build Python 2.6.2 on HP-UX Itanium with thread support?
On 2009.05.13 10:34:55 +0200, henning.vonbar...@arcor.de wrote: > How to build Python 2.6.2 on HP-UX Itanium with thread support? > Note: I know that the first address to post this question is > comp.lang.python, but > I posted this question a week ago on comp.lang.python > (http://groups.google.com/group/comp.lang.python/browse_thread/thread/c7006ad8e5cf81e8) > and unfortunately, I didn't receive any answers. > > According to Patch 1225212, > at least Peter Kropf was able to get Python running with threading support > on this platform, though AFAIK he was not using GCC. > > But I guess it should be possible with GCC as well. > > Is anyone able to confirm that Python (built with GCC) > does or does not work with multi-threading on HP-UX Itanium? The good news: I did get Python 2.4.x working on HP-UX Itanium, with threading. The compiler was gcc 4.0.x. (I also tried building Python with aCC, but failed.) I remember building both 32-bit and 64-bit versions. I don't remember it being that hard. Used the source for the package at hpux.connect.org.uk as a starting point, since it had a lot of good porting tweaks, but it needed some further tweaking. (The main one I remember that is that the shared library extension for Itanium should be .so not .sl There were also a bunch of paths that required appending 32 or 64.) We used that build of Python in production, for very heavily multithreaded code, on multi-CPU boxes. Worked fine. AFAIK they're still using it. I'm not sure why the binary available at hpux.connect.org.uk has threading disabled. I suspect that some older version of HP/UX had pthread bugs that got fixed somewhere along the line. The bad news: I did this about 3.5 years ago, and I don't work there anymore, so I don't have access to that HP-UX hardware anymore, or to the notes I made when I was doing the port. So I can give you encouragement but not step-by-step instructions. Sorry. -- David Riptondrip...@ripton.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] VPython 0.1
s 243ms -42.9% NormalInstanceAttribute: 121ms 191ms -36.9% 121ms 210ms -42.5% PythonFunctionCalls: 134ms 200ms -32.6% 144ms 219ms -34.2% PythonMethodCalls: 173ms 228ms -23.9% 185ms 251ms -26.5% Recursion: 177ms 298ms -40.5% 187ms 316ms -40.8% SecondImport: 135ms 133ms +1.5% 160ms 147ms +8.9% SecondPackageImport: 148ms 141ms +5.0% 166ms 162ms +2.7% SecondSubmoduleImport: 209ms 188ms +11.4% 221ms 203ms +8.6% SimpleComplexArithmetic: 131ms 219ms -40.0% 139ms 239ms -41.7% SimpleDictManipulation: 105ms 210ms -49.9% 123ms 233ms -47.1% SimpleFloatArithmetic:93ms 224ms -58.6% 109ms 246ms -55.8% SimpleIntFloatArithmetic:84ms 190ms -56.0%89ms 213ms -58.4% SimpleIntegerArithmetic:82ms 191ms -57.1%84ms 218ms -61.5% SimpleListManipulation:85ms 188ms -54.6%90ms 207ms -56.7% SimpleLongArithmetic: 111ms 198ms -44.0% 134ms 215ms -37.6% SmallLists: 126ms 182ms -30.7% 143ms 202ms -28.9% SmallTuples: 132ms 193ms -31.3% 143ms 210ms -31.7% SpecialClassAttribute: 110ms 221ms -50.4% 144ms 241ms -40.1% SpecialInstanceAttribute: 146ms 236ms -38.2% 165ms 258ms -36.1% StringMappings: 177ms 209ms -15.2% 186ms 218ms -14.5% StringPredicates: 169ms 219ms -22.9% 178ms 238ms -25.0% StringSlicing: 130ms 206ms -37.0% 151ms 223ms -32.4% TryExcept:92ms 230ms -59.9%94ms 258ms -63.5% TryFinally: 139ms 183ms -23.6% 160ms 204ms -21.8% TryRaiseExcept: 139ms 147ms -5.0% 151ms 162ms -6.7% TupleSlicing: 135ms 174ms -22.0% 151ms 190ms -20.7% UnicodeMappings: 222ms 244ms -8.9% 241ms 257ms -6.3% UnicodePredicates: 170ms 214ms -20.6% 179ms 227ms -21.2% UnicodeProperties: 136ms 159ms -14.9% 154ms 206ms -25.3% UnicodeSlicing: 142ms 215ms -34.1% 171ms 248ms -31.3% WithFinally: 208ms 260ms -20.1% 212ms 271ms -21.9% WithRaiseExcept: 175ms 193ms -9.0% 186ms 209ms -11.0% --- Totals: 7682ms 10935ms -29.8% 8468ms 12832ms -34.0% (this=2008-10-22 20:45:22, other=/tmp/vanilla252.pybench) -- David Ripton[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [ANN] VPython 0.1
On 2008.10.23 12:02:12 +0200, M.-A. Lemburg wrote: > BTW: I hope you did not use pybench to get profiles of the opcodes. > That would most certainly result in good results for pybench, but > less good ones for general applications such as Django or Zope/Plone. I was wondering about Pybench-specific optimization too, so last night I ran a few dozen of my projecteuler.net solver programs with VPython. Excluding the ones that are so fast that startup overhead dominates runtime, the least speedup I saw versus vanilla 2.5.2 was ~10%, the best was ~50%, and average was ~30%. Pretty consistent with Pybench. -- David Ripton[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On 2008.11.05 11:09:24 +, Paul Moore wrote: > An average user (ie, not a core developer) finds an issue, and has an > idea how to fix it. He raises a tracker item, checks out the Python > sources, makes a fix, and wants to upload it to the tracker. Key > points here are the initial work needed to grab a development > checkout, and the ability to bundle up a fix for upload to the > tracker. (I'm specifically thinking of a casual user, not a developer > who already has a Python checkout to work on). > > I'll freely admit a (not very) hidden bias here - the slowness of an > initial clone (or going through the "download a shared repo, unpack > it, create a branch and update" rigmarole) makes this a nasty test for > Bazaar. But I do nevertheless think it's an important use case, as > it's all about encouraging casual users to contribute. All timings very approximate: Time for average user to check out Python sources with bzr: 10 minutes Time for average user to check out Python sources with git or hg: 1 minute Time for average user's trivial patch to be reviewed and committed: 1 year I love DVCS as much as the next guy, but checkout time is so not the bottleneck for this use case. -- David Ripton[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
