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
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 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 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
> 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
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
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
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
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 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
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
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).
(
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
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
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
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
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
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: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 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 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://h...@hg.python.org/cpython master
>
>Then create a hardlinked clone [2] for working in each branch,
>specifying the branch to check out usi
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 06:47 pm, fuzzy...@voidspace.org.uk 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
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 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 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
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, 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
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 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
>>>
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 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
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 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
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
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 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
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 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 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 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 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
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
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
>
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: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
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
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
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
> 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
50 matches
Mail list logo
