On Sun, Mar 20, 2011 at 3:46 PM, Scott Dial
wrote:
> Why would that be true? Shouldn't this launcher just be a basic wrapper
> that cobbles together the arguments for an eventual os.exec*() call?
> What is there to do other than to exec the correct interpreter with (a
> subset of?) the command-lin
On 3/19/2011 7:23 PM, Nick Coghlan wrote:
> On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. Löwis" wrote:
>> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis"
>>> wrote:
I, for example, will find issues with it if the implementation uses
Crea
On Thu, 17 Mar 2011 14:33:00 +0100, wrote:
> On Thu, 17 Mar 2011 09:24:26 -0400
> "R. David Murray" wrote:
> >
> > It would be great if rebase did work with share, that would make a
> > push race basically a non-issue for me.
>
> rebase as well as strip destroy some history, meaning some of you
On Sat, 19 Mar 2011 13:53:11 -0500, s...@pobox.com wrote:
>
> >> I have a trivial little documentation patch for csv.rst. I committed
> >> it locally, then I pulled and merged:
>
> RDM> Note that if you want doc changes to appear in all the current doc
> RDM> sets (2.7, 3.2, dev)
> Out of curiosity, what is your objection to having the child process?
One of the problems is that parent process will not be able to kill
launched script. Simply doing TerminateProcess will kill the launcher,
leaving interpreter running. This can be partially fixed with job
objects, though.
Eug
Ned Deily writes:
> As a side note, if you are prone to accidentally adding extra
> whitespace (like I am), you can add the whitespace check hook into
> your local copy of Mercurial so that you will be warned about
> whitespace problems immediately when you commit things to your local
> repos rat
On 20/03/2011 5:49 AM, "Martin v. Löwis" wrote:
* Is this really PEP material, or will turning the PEP into a regular
spec be suitable?
It's PEP material if it is contentious, which I believe it is.
Of course it is - this is python-dev .
I, for example, will find issues with it if the imple
On 20/03/2011 4:15 AM, Dj Gilcrease wrote:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
2) If the launcher provides command line options for the "benefit" of
launching interactive Python interpreters, those command line options can
have data puns with script names, or can conflict
Thanks for the feedback!
On 19/03/2011 7:44 PM, Glenn Linderman wrote:
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond
In article
,
Nick Coghlan wrote:
> Mercurial isn't really all that different, but it's distributed nature
> means it want to keep track of even minor things like the local
> whitespace fixes and the merger of your changes with the other changes
> that were pushed since you started work. So the e
Am 20.03.2011 00:39, schrieb Antoine Pitrou:
> On Sat, 19 Mar 2011 16:32:53 -0700
> Guido van Rossum wrote:
>> remote: File "/data/buildbot/master/master.cfg", line 87, in
>> perspective_addChange
>> remote: changedict['category'] = branch_to_category[changedict['branch']]
>> remote: excepti
Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
> Antoine Pitrou writes:
>
> > I suggest you try http://code.google.com/p/bbreport/, which provides a
> > very nice command-line interface.
>
> Speaking of bbreport, I sometimes use the published page on that site
> (http://code.google.c
> I made a test change to the 2.5 README and merged it into 2.6 and 2.7.
> Then I pushed. It *seems* to have worked, but I also got some
> traceback:
Oops. I wouldn't have expected that tracebacks propagate that far back.
This was your hg client talking to the remote hg client executing a
post-pus
Skip wrote:
> Antoine wrote:
> > 94 changesets? If you want to avoid risking conflicts, you should "hg
> > pull" and "hg up" (or "hg pull -u") before you start working on
> > something (just like you "svn up"'ed before working on something).
>
> Sorry, this workflow is still new and hugely confusin
On Sun, Mar 20, 2011 at 9:44 AM, David Bolen wrote:
> Nick Coghlan writes:
>
>> I don't want to give up completely on the idea just yet, but I'll
>> experiment in the sandbox before I turn it back on.
>
> If you get to that point again, I'd also be willing to pick a time to
> manually check out t
On Sat, Mar 19, 2011 at 12:59 PM, Raymond Hettinger
wrote:
> On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
>> On Sat, 19 Mar 2011 09:25:07 -0500
>> s...@pobox.com wrote:
>>
>>> The dev guide says something about collapsing changesets. Is that
>>> collapsing commits within a changeset or col
Nick Coghlan writes:
> I don't want to give up completely on the idea just yet, but I'll
> experiment in the sandbox before I turn it back on.
If you get to that point again, I'd also be willing to pick a time to
manually check out the right branch or whatever and try it manually
on one of two o
On Sun, Mar 20, 2011 at 9:32 AM, Guido van Rossum wrote:
> +1. Just as I hope for the Python 3-4 transition, I hope that whatever
> comes along next has a better transition strategy. That would make it
> really hot.
Given that the hardest part of any transition is updating developers'
brains, tha
On Sat, 19 Mar 2011 16:32:53 -0700
Guido van Rossum wrote:
> remote: File "/data/buildbot/master/master.cfg", line 87, in
> perspective_addChange
> remote: changedict['category'] = branch_to_category[changedict['branch']]
> remote: exceptions.KeyError: '2.5'
> remote: ]
That's because the b
On Sat, Mar 19, 2011 at 12:55 PM, "Martin v. Löwis" wrote:
> So I'd encourage everybody to keep asking questions, and request that
> they are answered in a polite manner, even if the one answering thinks
> that the same question is already answered in some documentation.
Thanks. I have some basic
On Sun, Mar 20, 2011 at 9:04 AM, "Martin v. Löwis" wrote:
> Am 19.03.2011 23:51, schrieb Nick Coghlan:
>> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis"
>> wrote:
>>> I, for example, will find issues with it if the implementation uses
>>> CreateProcess at some point - the launcher should IMO
On Sun, Mar 20, 2011 at 5:05 AM, wrote:
> Sorry, this workflow is still new and hugely confusing to me. To make a
> simple edit to csv.rst I needed to do a couple pulls and merges, local
> commits, resolve the same conflict multiple times, get rebuffed when I first
> pushed because there was a t
Am 19.03.2011 23:51, schrieb Nick Coghlan:
> On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" wrote:
>> I, for example, will find issues with it if the implementation uses
>> CreateProcess at some point - the launcher should IMO run Python
>> directly, rather than creating a new process. This, i
On Sun, Mar 20, 2011 at 5:52 AM, Antoine Pitrou wrote:
>> I suspect, however, that as soon as something else commits to the 3.x
>> branch and causes a new test, that test_crashers (presumably from
>> changeset 9c6dcb5d8f01) will likely just take the slaves down again.
>
> The test is already disab
On Sun, Mar 20, 2011 at 4:49 AM, "Martin v. Löwis" wrote:
> I, for example, will find issues with it if the implementation uses
> CreateProcess at some point - the launcher should IMO run Python
> directly, rather than creating a new process. This, in turn, will
> probably mean that you cannot act
On Sat, Mar 19, 2011 at 9:46 PM, Stephen J. Turnbull wrote:
> To the extent the buildbots are not overloaded, this strategy will
> indeed save developer time, as most changes are more or less
> independent of each other (that's why automated merging works at all
> well), and most of the time somet
> I think if we're going to require a complex workflow, then we're
> going to have to expect a lot of questions. And those questions
> shouldn't be brushed-off with "go read the tutorial, we have no time
> for you" or words to that effect.
And indeed, I think this (asking questions) is just about
On Sat, 19 Mar 2011 15:41:51 -0400
David Bolen wrote:
>
> Thanks. Is that a single button somewhere or do I need to cancel the
> pending builds individually when there are several waiting?
There seems to be a single button.
> In any event it looks like the retries of the failing 3.x build
> st
Antoine Pitrou writes:
> I've enabled the button to cancel pending builds in the Web UI. You
> should be able to bring back the Ubuntu slave online. You can do the
> same (cancel pending builds) for other slaves if needed.
Thanks. Is that a single button somewhere or do I need to cancel the
pen
I suggested at python-ideas a way that the declaration of abstract
properties could be improved to support the decorator syntax:
http://mail.python.org/pipermail/python-ideas/2011-March/009411.html .
A relatively small change to the property builtin would allow
properties to identify themselves as
> "Antoine" == Antoine Pitrou writes:
Antoine> On Sat, 19 Mar 2011 09:25:07 -0500
Antoine> s...@pobox.com wrote:
>>
>> I have a trivial little documentation patch for csv.rst. I committed it
>> locally, then I pulled and merged:
>>
>> cpython% hg pull
>> pul
On Mar 19, 2011, at 11:21 AM, Antoine Pitrou wrote:
> On Sat, 19 Mar 2011 09:25:07 -0500
> s...@pobox.com wrote:
>
>> The dev guide says something about collapsing changesets. Is that
>> collapsing commits within a changeset or collapsing multiple changesets
>> (whatever that might be)? Do I n
On Sat, 19 Mar 2011 14:45:10 -0400
David Bolen wrote:
>
> The problem is that the failing build is automatically retried when I
> try to reconnect the buildbot, so it just get rights into trouble
> again. The comment in that build's changeset looks like it might be
> getting rolled back?
>
> As
>> I have a trivial little documentation patch for csv.rst. I committed
>> it locally, then I pulled and merged:
RDM> Note that if you want doc changes to appear in all the current doc
RDM> sets (2.7, 3.2, dev), then you should start with patching 3.2 and
RDM> merge it into d
> * Is this really PEP material, or will turning the PEP into a regular
> spec be suitable?
It's PEP material if it is contentious, which I believe it is.
I, for example, will find issues with it if the implementation uses
CreateProcess at some point - the launcher should IMO run Python
directly,
I've run out of virtual memory on my Ubuntu buildbot today (and I
think the FreeBSD buildbots a few days ago). Those have physically
OOMd/restarted the VM. The Windows buildbots have been giving me
VM warnings, but appear to have gotten through it.
I believe it's the test_crashers test, which wh
On Sat, 19 Mar 2011 09:25:07 -0500
s...@pobox.com wrote:
>
> I have a trivial little documentation patch for csv.rst. I committed it
> locally, then I pulled and merged:
>
> cpython% hg pull
> pulling from ssh://h...@hg.python.org/cpython
> searching for changes
> adding changese
On 19.03.2011 16:30, R. David Murray wrote:
> On Sat, 19 Mar 2011 13:57:02 +0100, Antoine Pitrou
> wrote:
>> On Sat, 19 Mar 2011 02:22:42 +0100
>> raymond.hettinger wrote:
>> > http://hg.python.org/cpython/rev/80ff78425419
>> > changeset: 68671:80ff78425419
>> > branch: 3.2
>> > parent:
On Sat, Mar 19, 2011 at 4:44 AM, Glenn Linderman wrote:
> The launcher could be simpler if the Python installer placed versioned
> Python executables on the PATH. Unfortunately, historically it hasn't. If
> it did, would, or the launcher installer would place them there for
> pre-existing versio
Not all of the ideas below are complementary to each other, some are
either or, to allow different thoughts to be inspired or different
directions to be taken.
Thanks for starting a PEP.
On 3/18/2011 11:02 PM, Mark Hammond wrote:
The launcher should be as simple as possible (but no simp
On Sat, 19 Mar 2011 09:25:07 -0500, s...@pobox.com wrote:
>
> I have a trivial little documentation patch for csv.rst. I committed it
> locally, then I pulled and merged:
Note that if you want doc changes to appear in all the current doc sets
(2.7, 3.2, dev), then you should start with patching
On Sat, 19 Mar 2011 13:57:02 +0100, Antoine Pitrou wrote:
> On Sat, 19 Mar 2011 02:22:42 +0100
> raymond.hettinger wrote:
> > http://hg.python.org/cpython/rev/80ff78425419
> > changeset: 68671:80ff78425419
> > branch: 3.2
> > parent: 68665:f832ca852329
> > user:Raymond Hetting
> hg heads showed my changeset:
>
> changeset: 68585:c63d7374b89a
> user:Skip Montanaro
> date:Sat Mar 19 09:09:30 2011 -0500
> summary: Mention RFC 4180. Based on input by Tony Wallace in issue
> 11456.
>
> I committed. Now:
>
> changeset: 68680:6
I have a trivial little documentation patch for csv.rst. I committed it
locally, then I pulled and merged:
cpython% hg pull
pulling from ssh://h...@hg.python.org/cpython
searching for changes
adding changesets
adding manifests
adding file changes
added 94 changesets w
> I do distinctly recall __version__ being standardized for other
> purposes too, but I have no idea how to find that reference... It
> probably was well before 2000.
Maybe you were thinking about Pydoc, which will display __version__ in a
dedicated section of the doc.
Regards
___
On Sat, 19 Mar 2011 02:22:42 +0100
raymond.hettinger wrote:
> http://hg.python.org/cpython/rev/80ff78425419
> changeset: 68671:80ff78425419
> branch: 3.2
> parent: 68665:f832ca852329
> user:Raymond Hettinger
> date:Fri Mar 18 18:22:28 2011 -0700
> summary:
> Issue 73
On Fri, 18 Mar 2011 20:12:19 -0700
Toshio Kuratomi wrote:
> There is a section in PEP8 about __version__ but it serves a slightly
> different purpose there:
>
> """
> Version Bookkeeping
>
> If you have to have Subversion, CVS, or RCS crud in your source file, do
> it as follows.
>
>
On Sat, Mar 19, 2011 at 12:22 PM, Jesus Cea wrote:
> On 19/03/11 03:14, Nick Coghlan wrote:
>> (i.e. start moving towards more of a style of development where code
>> doesn't land in the main repository until it has been vetted by the
>> buildbots *first*).
Unfortunately, this is *not* good enou
On Sat, Mar 19, 2011 at 03:42, Nick Coghlan wrote:
> 5. The parallel evolution of the 2.x and 3.x line meant that the first
> version of 2.x with the relevant warning was released only ~7 months
> or so before the version of 3.2 where the API was removed
An additional issue that makes it particul
49 matches
Mail list logo
