> Georg and I have been working on converting the SVN repository to
> Mercurial. We can now present you a test repository (actually, two).
Thanks for working on this!
How do you want bugs reported?
Can you please update the PEP? I see at least the following deviations:
- the extrahist repository
With hg 1.7.5 on Windows 7 I performed a non-core checkout:
hg clone http://hg.python.org/cpython
The eol extension is enabled in global settings. I looked at things
a bit, opening some files and using the Tortoise Hg Repository
Explorer. But made no actual changes. Running hg diff produces
On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:
> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).
Unnamed heads are trivial to convert to clones.
Cheers,
Dirkjan
Am 25.02.2011 08:29, schrieb Eli Bendersky:
> Hi,
> Earlier today I've committed revision 88554, and a bit later a
> buildbot failure message was received:
> Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed
> test_import, blamelist having my name because I made the last commit
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:
>> I think I would have liked the strategy of the PEP better (i.e.
>> create clones for feature branches, rather than putting all
>> in a single repository).
>
> Unnamed heads are trivial to co
On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote:
> If there are hundreds of them, it's far from trivial. I don't even know
> how to find out which one to convert.
Right, I mostly mean it's trivial for Antoine or Georg to extract into
a clone (at least that's how I was planning to do it, no
Am 25.02.2011 09:29, schrieb Dirkjan Ochtman:
> On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote:
>> If there are hundreds of them, it's far from trivial. I don't even know
>> how to find out which one to convert.
>
> Right, I mostly mean it's trivial for Antoine or Georg to extract into
>
It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation
http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads
Minimal repro:
#include "Python.h"
int main()
{
PyEval_Init
On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
> I think I would have liked the strategy of the PEP better (i.e.
> create clones for feature branches, rather than putting all
> in a single repository).
In my brief tests, the single repository has been easy to work with.
If they were separa
On Fri, 25 Feb 2011 19:13:49 +1100
Neil Hodgson wrote:
>With hg 1.7.5 on Windows 7 I performed a non-core checkout:
>
> hg clone http://hg.python.org/cpython
>
>The eol extension is enabled in global settings.
Yes, please try to disable it. The issue is we have a .hgeol in the
repositor
On Thu, 24 Feb 2011 17:39:40 -0800
Brett Cannon wrote:
> >
> > Your clone will contain the following branches:
> >
> >$ hg branches
> >default68026:f12ef116dd10
> >3.268025:cef92ee1a323
> >2.768010:8174d00d0797
> >
On 25.02.2011 09:25, "Martin v. Löwis" wrote:
> Am 25.02.2011 09:17, schrieb Dirkjan Ochtman:
>> On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote:
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> in a sing
On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
>
>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
>
>> I think I would have liked the strategy of the PEP better (i.e.
>> create clones for feature branches, rather than putting all
>> in a single repository).
>
>In my brief tests, the s
On Wed, Feb 23, 2011 at 10:30 PM, Georg Brandl wrote:
> On 23.02.2011 20:43, "Martin v. Löwis" wrote:
>>> Or you realized later how nice it would be, grabbed the time machine,
>>> and fixed 10 release blockers on the 19th. :)
>>
>> No no no. He actually grabbed the time machine, drove 20 years bac
Hi Barry,
> The way I work with the Subversion branches is to have all the active branches
> checked out into separate directories under a common parent, e.g.
>
> ~/projects/python/py26
> ~/projects/python/py27
> ~/projects/python/trunk
> ~/projects/python/py31
> ~/projects/python/py32
> ~/proje
On 25.02.2011 17:12, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
>
>>
>>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
>>
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>> i
On 25.02.2011 17:31, Georg Brandl wrote:
> On 25.02.2011 17:12, Barry Warsaw wrote:
>> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
>>
>>>
>>>On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
>>>
I think I would have liked the strategy of the PEP better (i.e.
create clones f
ACTIVITY SUMMARY (2011-02-18 - 2011-02-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2682 (+27)
closed 20422 (+52)
total 23104 (+79)
Open issues wit
On Fri, 25 Feb 2011 13:52:58 +0100
Antoine Pitrou wrote:
> On Fri, 25 Feb 2011 19:13:49 +1100
> Neil Hodgson wrote:
> >With hg 1.7.5 on Windows 7 I performed a non-core checkout:
> >
> > hg clone http://hg.python.org/cpython
> >
> >The eol extension is enabled in global settings.
>
> Y
On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
giampaolo.rodola wrote:
> +#else
> +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> +: PyLong_AsLong(arg);
> +#endif
There's something fishy here. Why would you call PyLong_AsLong() if
PyLong_Check() is false?
Regards
Anto
On 2011-02-25 17:12, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote:
>
>>
>> On Feb 25, 2011, at 12:09 AM, Martin v. Löwis wrote:
>>
>>> I think I would have liked the strategy of the PEP better (i.e.
>>> create clones for feature branches, rather than putting all
>>>
What's the easiest way of finding which tests failed on buildbot builds? I mean,
is there anything easier than using the Web interface to browse to failing
builds and then looking at the stdio output in a browser?
Thanks,
Vinay Sajip
___
Python-Dev mai
On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote:
> On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
> giampaolo.rodola wrote:
>
> > +#else
> > +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> > +: PyLong_AsLong(arg);
> > +#endif
>
> There's something fishy here. Wh
Le vendredi 25 février 2011 à 20:11 +0200, Ross Lagerwall a écrit :
> On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote:
> > On Fri, 25 Feb 2011 15:39:16 +0100 (CET)
> > giampaolo.rodola wrote:
> >
> > > +#else
> > > +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg)
> > > +
On Fri, 25 Feb 2011 18:10:28 + (UTC)
Vinay Sajip wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I
> mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?
Not really, bu
On 25/02/2011 18:10, Vinay Sajip wrote:
What's the easiest way of finding which tests failed on buildbot builds? I mean,
is there anything easier than using the Web interface to browse to failing
builds and then looking at the stdio output in a browser?
That's one of the big advantages that Jen
On 25.02.2011 19:10, Vinay Sajip wrote:
> What's the easiest way of finding which tests failed on buildbot builds? I
> mean,
> is there anything easier than using the Web interface to browse to failing
> builds and then looking at the stdio output in a browser?
Once every failure sent a mail to p
On 06:47 pm, [email protected] wrote:
On 25/02/2011 18:10, Vinay Sajip wrote:
What's the easiest way of finding which tests failed on buildbot
builds? I mean,
is there anything easier than using the Web interface to browse to
failing
builds and then looking at the stdio output in a bro
2011/2/25 barry.warsaw :
> barry.warsaw pushed 9619d21d8198 to cpython:
>
> http://hg.python.org/cpython/rev/9619d21d8198
> changeset: 68030:9619d21d8198
> branch: 2.7
> tag: tip
> parent: 68010:8174d00d0797
> user: Barry Warsaw
> date: Fri Feb 25 14:35:22 2011 -0
On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
>First, get an initial clone (let's name it 'master') over the wire
>using: [1]
>
> $ hg clone -U ssh://[email protected]/cpython master
>
>Then create a hardlinked clone [2] for working in each branch,
>specifying the branch to check out usi
On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote:
>Ah, this reminds me. Figuring out what to do with the AST version
>should probably be a hg roadmap topic.
Is there a bug tracker for the conversion?
-Barry
signature.asc
Description: PGP signature
_
On 25.02.2011 20:45, Barry Warsaw wrote:
> On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote:
>
>>Ah, this reminds me. Figuring out what to do with the AST version
>>should probably be a hg roadmap topic.
>
> Is there a bug tracker for the conversion?
There's todo.txt in the pymigr repo.
Ge
On Fri, 25 Feb 2011 14:43:15 -0500
Barry Warsaw wrote:
>
> I'll have to remember that 'hg pull' does not update the working copy by
> default, and eventually I'll figure out the whole merge thing.
You can use "hg pull -u" to update (and "hg pull -uv" if you want to
see the list of updated files)
On 25/02/2011 20:43, Barry Warsaw wrote:
>
> One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes
> my editor and always shows me a 'diff -u' in the commit message buffer. This
> is incredibly handy because I don't have to remember to do the diff in a
> different window, a
Antoine Pitrou:
> It should now be fixed in current SVN, meaning the final conversion
> should be perfectly usable with the eol extension enabled.
Good.
> Do you find other issues under Windows? Have you tried pushing changes?
Since I'm not a member of core developers I used a http pull a
Le samedi 26 février 2011 à 08:40 +1100, Neil Hodgson a écrit :
> Antoine Pitrou:
>
> > It should now be fixed in current SVN, meaning the final conversion
> > should be perfectly usable with the eol extension enabled.
>
>Good.
>
> > Do you find other issues under Windows? Have you tried pus
On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote:
>What you are asking for is available in TortoiseHg which absolutely
>rocks (if you are not allergic to the idea of a graphical tool).
Like shellfish, bee-strings, and Perl I'm afraid. :)
>You can even select indvidually inside a file which lin
On Fri, 25 Feb 2011 18:02:43 +0100 (CET)
vinay.sajip wrote:
> Author: vinay.sajip
> Date: Fri Feb 25 18:02:43 2011
> New Revision: 88589
>
> Log:
> logging: enabled test which was intermittently failing on buildbots.
Looks like it fails again:
(
http://www.python.org/dev/buildbot/all/builders
Now that the language moratorium is lifted, let's make sure to get PEP
380 implemented for Python 3.3. I think there are some minor issues to
be resolved, but I don't think that should stop someone from doing a
first pass of the implementation (especially since a version for 2.6
already exists).
(
From: Guido van Rossum
> (OTOH I am not much enamored with cofunctions, PEP 3152.)
That's okay, I don't like it much myself in its current form.
I plan to revisit it at some point, but there's no hurry.
--
Greg
This email may be confidential and subject to legal privilege, it may
not reflect
On 25Feb2011 14:43, Barry Warsaw wrote:
| [...] And I have to
| remember to fiddle with .hg/hgrc when I clone a new branch working directory,
| but I guess that's mostly a one-time cost.
Hmm. Why do you need to fiddle with the hgrc? Just curious.
| I'll have to remember that 'hg pull' does not
Ok. Will you hvae time to port your patches to 3.3?
On Fri, Feb 25, 2011 at 3:01 PM, Greg Ewing wrote:
> From: Guido van Rossum
>
>> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>
> That's okay, I don't like it much myself in its current form.
> I plan to revisit it at some point, bu
On Fri, Feb 25, 2011 at 5:43 PM, Guido van Rossum wrote:
> Now that the language moratorium is lifted, let's make sure to get PEP
> 380 implemented for Python 3.3. I think there are some minor issues to
> be resolved, but I don't think that should stop someone from doing a
> first pass of the impl
On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing wrote:
> From: Guido van Rossum
>
>> (OTOH I am not much enamored with cofunctions, PEP 3152.)
>
> That's okay, I don't like it much myself in its current form.
> I plan to revisit it at some point, but there's no hurry.
I've just gone through PEP 3152
Hi,
Le 25/02/2011 20:43, Barry Warsaw a écrit :
> On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote:
> [snip]
>> Note that each of these branch clones will initially have your local
>> master repo as the default path [3,4]. If you'd like to have the default
>> push/pull path to point to ssh://h
> After migration
> ===
>
> +* set up automatic installation of changes to ssh keys, decide upon
> + account managers
I would like account managers to be decided before the conversion.
I personally won't be available as an account manager anymore. The new
account managers are then
On 25/02/2011 20.10, Vinay Sajip wrote:
What's the easiest way of finding which tests failed on buildbot builds? I mean,
is there anything easier than using the Web interface to browse to failing
builds and then looking at the stdio output in a browser?
You can try bbreport (http://code.googl
On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote:
> $ hg branches
> default 68026:f12ef116dd10
> 3.2 68025:cef92ee1a323
> 2.7 68010:8174d00d0797
> 3.1 67955:5be8b695ea86
> 2.6
On Sat, 26 Feb 2011 12:32:04 +1000
Nick Coghlan wrote:
> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote:
> > $ hg branches
> > default 68026:f12ef116dd10
> > 3.2 68025:cef92ee1a323
> > 2.7 68010:8174d00d0797
> >
On 26.02.2011 03:32, Nick Coghlan wrote:
> On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou wrote:
>>$ hg branches
>>default68026:f12ef116dd10
>>3.268025:cef92ee1a323
>>2.768010:8174d00d0797
>>3.1
50 matches
Mail list logo
