point with no analysis involved. Looking into
kill_python or its use can be a follow-on.
-- David
___
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
combine/edit our
bits of information. Probably something we can take off-list, so just
let me know.
-- David
___
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
_err_mode)
+
# connectionMade also closes stdin as long as we're not using a PTY.
# This is intended to kill off inappropriately interactive commands
# better than the (long) hung-command timeout. ProcessPTY should be
- - - - - - - - - - - - - - - - - - - - - - - - -
est tool to write (and I still have some email from him about the
week+ it took just to test the process identification part remotely
through buildbots at the time), so I regret not jumping right in to
try to fix it. But it's just way more effort than typing "pskill
python_d",
to make them work in a sandboxed interpreter, but
not at the expense of security. Some incompatible changes will be necessary.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
orrect.
... if Zope's sandboxing is secure. I haven't done a security review of it,
but your argument assumes that it is.
In any case, Zope's sandboxing is not capability-based.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev
Brett Cannon wrote:
> On 7/23/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
>
>> Hi David, hi Brett,
>>
>> On Sun, Jul 23, 2006 at 02:18:48AM +0100, David Hopwood wrote:
>> > If I understand correctly, the proposal is that any incompatible
>> > change
Phillip J. Eby wrote:
> At 11:07 PM 7/23/2006 +0100, David Hopwood wrote:
>> Phillip J. Eby wrote:
>> > At 01:00 PM 7/23/2006 -0700, Brett Cannon wrote:
>> >
>> >> I obviously don't want to change the feel of Python, but if I have to
>> >>
eg Ewing was making. A pure capability system incurs
the complexity and performance costs of wrappers or membranes only in cases
where they are needed, not for every object, and the complexity is only in
user code, not in the system's security kernel.
--
David Hopwood <[EMAIL PROTECTED]&g
be fixed before the module is added to the standard
library, IMHO.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailm
__ and __str__ are internal under these rules, and probably shouldn't be.
Existing classes may expose private state in the strings returned by __repr__
or __str__, but in principle, there is nothing unsafe about being able to
convert the public state of an object to a string. OTOH, this functio
Armin Rigo wrote:
> Hi David,
>
> Your proposal is too vague to be useful. In Python I would not feel
> that any compiler-enforced restrictions are going to be too restrictive,
> and so I believe that your approach is not viable, but I cannot give you
> many concrete examples
David Hopwood wrote:
> The intention was not to require the restrictions to be compiler-enforced;
> only to *allow* them to be compiler-enforced.
>
> Code like this, for example:
>
> def someMethod(self, x):
> if self == x:
"if self is x:", I mean
Greg Ewing wrote:
> David Hopwood wrote:
>
>> A restricted interpreter refuses access to any object attribute or
>> method with a name beginning with '_' (by throwing a new exception type
>> 'InternalAccessException'), unless the access is from
Greg Ewing wrote:
> David Hopwood wrote:
>
>> Inheritance should be defined as though the code of inherited methods and
>> attributes were copied into the subclass (with global accesses updated to
>> point to the original module).
>
> You'll have to propose
Richard Jones wrote:
> On 27/07/2006, at 12:19 PM, David Hopwood wrote:
>
>> A restricted interpreter refuses access to any object attribute or
>> method with a name beginning with '_' (by throwing a new exception type
>> 'InternalAccessException&#x
good idea. What was
the rationale for that? It should throw an exception.
--
David Hopwood <[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
ode cannot know
> whether this meant as overflow or underflow (in a signed sense).
Why not use IndexError for an underflow, and OverflowError for an overflow?
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.or
am not especially fond of the current miniconf name either; I didn't
>>find something more suitable, yet evocative of what it does; I would be
>>glad to hear any suggestion you or the rest of the developers would have.
>
> pyson :)
Following the pattern of JSON,
thon.atlassian.com/secure/Dashboard.jspa
Is anyone looking at the Google Code Hosting tracker, just for fun? =) (code.google.com/hosting, although performance seems to be an issue for now)--david
___
Python-Dev mailing list
Python-Dev@pyt
; +1
>
> This seems the most (only ?) logical solution.
No; always considering Unicode and non-ASCII byte strings to be distinct
is just as logical.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.
Michael Foord wrote:
> David Hopwood wrote:[snip..]
>
>>>> we should, of course, continue to use the one we always used (for
>>>> "ascii", there is no difference between the two).
>>>
>>> +1
>>>
>>> This seems the most (
Martin v. Löwis wrote:
> David Hopwood schrieb:
>>Michael Foord wrote:
>>>David Hopwood wrote:[snip..]
>>>
>>>>>>we should, of course, continue to use the one we always used (for
>>>>>>"ascii", there is no difference betwee
on. it's a question of semantics -- i asked whether the object
> (a list, in this case) is contained in the dict. i didn't ask whether
> it's hashable or not.
However, if it isn't hashable, asking whether it is in a di
t of a microoptimization that is unlikely to significantly
help performance.
CPython should be fixed anyway. The correct fix is
"if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
--
David Hopwood <[EMAIL PROTECTED]>
Thomas Wouters wrote:
> On 8/26/06, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>> CPython should be fixed anyway. The correct fix is
>> "if (y == -1 && x < 0 && (unsigned long)x == -(unsigned long)x)".
>
> Why not just "... &&
rameworks, and compile at low optimization levels when
it doesn't hurt performance.)
--
David Hopwood <[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
to read:
>
>seq[rslice(start, stop, step)]
Or slice.reversed().
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.
cularly badly. I don't
know how to implement what you want here, but I'd endorse the comments of
Nick Maclaren and Antony Baxter against making precipitate changes.
--
David Hopwood <[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
Jean-Paul Calderone wrote:
> PyGTK would presumably implement its pending call callback by writing a
> byte to a pipe which it is also passing to poll().
But doing that in a signal handler context invokes undefined behaviour
according to POSIX.
--
David Hopwood <[EMAIL
Jean-Paul Calderone wrote:
> On Mon, 04 Sep 2006 17:24:56 +0100, David Hopwood <[EMAIL PROTECTED]> wrote:
>
>>Jean-Paul Calderone wrote:
>>
>>>PyGTK would presumably implement its pending call callback by writing a
>>>byte to a pipe which it is also p
obably need something else.
+1 for (upto, sep, rest) -- and I think it should be in that order for
both partition and rpartition.
--
David Hopwood <[EMAIL PROTECTED]>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pytho
ldn't work on Windows,
because they haven't worked in the past."
--
David Hopwood <[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
Nick Coghlan wrote:
> David Hopwood wrote:
>> Martin v. Löwis wrote:
>>> Nick Coghlan schrieb:
>>>
>>>> So this is taking something that *already works properly on POSIX
>>>> systems* and making it work on Windows as well.
>>>
>>&
Martin v. Löwis wrote:
> David Hopwood schrieb:
>
>>On Windows, file system pathnames can contain arbitrary Unicode characters
>>(well, almost). Despite the existence of "ANSI" filesystem APIs, and
>>regardless of what 'sys.getfilesystemencoding()' re
Pep 353 advises the use of this incantation:
#if PY_VERSION_HEX < 0x0205
typedef int Py_ssize_t;
#define PY_SSIZE_T_MAX INT_MAX
#define PY_SSIZE_T_MIN INT_MIN
#endif
I just wanted to point out that this advice could lead to library
header collisions when multiple 3rd parties decide
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams schrieb:
>> #if PY_VERSION_HEX < 0x0205
>> typedef int Py_ssize_t;
>> #define PY_SSIZE_T_MAX INT_MAX
>> #define PY_SSIZE_T_MIN INT_MIN
>> #endif
>>
>> I
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> c. anyway you'll get a nasty warning, which for some people will be
>> just as bad as an error
>
> Try for yourself. You get the warning only if the redefinition is not
> identical to the original definition (or an object-like macro is
> redefined
Martin v. Löwis wrote:
> David Abrahams schrieb:
>
>>(C++ allows restating of typedefs; if C allows it, that should be
>>something like):
>
> C also allows this; [...]
This is nitpicking, since you agreed the change to the PEP, but are you
sure that C allows this?
>
ade an error
> in analyzing what must be true at this point.
You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
(and the constant 4) are unsigned. Also bytes_left must initially be nonnegative
so that the subexpression 'sizeof(errTxt) - bytes_left' cannot ov
I wrote:
> You omitted to state an assumption that sizeof(errTxt) >= 4, since size_t
> (and the constant 4) are unsigned.
Sorry, the constant '4' is signed, but sizeof(errTxt) - 4 can nevertheless
wrap around unless sizeof(errTxt) >= 4.
--
David Hop
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> Dave Abrahams schrieb:
>> The only problem here is that there appears to be a lag in the release of
>> ActivePython after Python itself is released.
>>
>> Is there any chance of putting up just the debugging libraries a little
>> earlier?
>
> I may
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I'm not sure whether you are requesting these for yourself or for
> somebody else. If for somebody else, that somebody else should seriously
> consider building Python himself, and publishing the result.
I'm requesting it for the many Boost.Python (
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> David Abrahams schrieb:
>>> I'm not sure whether you are requesting these for yourself or for
>>> somebody else. If for somebody else, that somebody else should seriously
>>> consider building Py
sable extensions, but a more configurable build
process would also be welcome.
I'll try to look at Martin's patch at some point. I hope these observations
and suggestions help explain the current issues with the build system when
cross-compiling.
David
__
t they can be processed by the CPU as normal 32 bit wide
instructions. This doesn't mean that the resulting executable and libraries
will be half the size that they would have been when compiled normally, but
you may be able to save some storage space that way. I have no idea whether
this tr
[Georg Brandl]
> is there any objection against making python-ideas available on gmane?
It's already there. That's how I read it.
--
David Goodger <http://python.net/~goodger>
signature.asc
Description: OpenPGP digital signature
___
Hi,
I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln,
and for me it fails miserably. The first major complaint comes when
linking pythoncore, where the _init_types symbol can't be found. On
the other hand, allowing MSVS to convert PCBuild/pcbuild.sln works
okay. Am I missi
on Mon Mar 05 2007, "Martin v. Löwis" writes:
> David Abrahams schrieb:
>> I tried building with MS Visual Studio 2005 from PCBuild8/pcbuild.sln,
>> and for me it fails miserably. The first major complaint comes when
>> linking pythoncore, where the _init_types sy
I'm trying to find the Python library binaries associated with a given
python executable.
If I look at the help for sys.prefix and sys.exec_prefix
import sys; help(sys)
I see:
prefix -- prefix used to find the Python library
exec_prefix -- prefix used to find the machine-specific P
on Tue Mar 06 2007, "Martin v. Löwis" wrote:
> David Abrahams schrieb:
>> I'm trying to find the Python library binaries associated with a given
>> python executable.
>
> This really isn't a python-dev question; please use python-list
> (news:comp
on Tue Mar 06 2007, "Martin v. Löwis" wrote:
> David Abrahams schrieb:
>> on Tue Mar 06 2007, "Martin v. Löwis" wrote:
>>> David Abrahams schrieb:
>>>> I'm trying to find the Python library binaries associated with a given
>>>&
with PSF and PyCon duties (I'm chairing PyCon 2008), I don't see
my availability for PEP editing increasing any time soon. A new PEP
Editor would be welcome!
--
David Goodger <http://python.net/~goodger>
___
Python-Dev mailing list
Python
r'[-+*\u2022\u2023\u2043]( +|$)',
...
attribution_pattern = re.compile(ur'(---?(?!-)|\u2014) *(?=[^ \n])')
-- David Goodger <http://python.net/~goodger>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.
> Guido van Rossum python.org> writes:
> > I'd like to hear from anyone who has access to *real code* that uses
> > \u or \U in a raw unicode string.
David Goodger python.org> writes:
> Docutils uses it in the docutils.parsers.rst.states module,
> On 5/11/07, David Goodger <[EMAIL PROTECTED]> wrote:
> > Docutils uses it in the docutils.parsers.rst.states module, Body class:
> >
> > patterns = {
> > 'bullet': ur'[-+*\u2022\u2023\u2043]( +|$)',
> > ...
> &
On Mon, 2010-12-06 at 10:18 +0100, "Martin v. Löwis" wrote:
> > EOL dates of prominent Linux distribution :
>
> I think I would need more information than that. Nick's proposal was
> more specific: when does the vendor stop producing patches? This is
> a clear criterion, and one that I support.
>
s only run at the start of a build process, so hung
processes (even killable ones) from a prior build hang around until
the next build takes place. They can however, interfere with the svn
checkout so things never get to the point of using kill_python. So
maybe ki
and see if we run into any other hangs that
interfere with the builds. I can't make such a change myself though.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://
On Tue, 2010-12-07 at 00:05 +0100, "Martin v. Löwis" wrote:
> >> So by this policy, RHEL and SuSE users would be off worse than with
> >> my original proposal (10 years).
> >
> > Red Hat continues to provide patches for RHEL within the "Extended Life
> > Cycle" (years 8, 9 and 10), but it's an op
ty of the
common cases with a minimum change, so seems the simplest.
-- David
___
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
o the original commit the cherry pick is coming from
(i.e. no equivalent to git cherry-pick -x), and the conflict
resolution is quite dumb. One alternative is to be careful about where
you apply your patch
(http://stackoverflow.com/questions/3926906/what-is-the-most-efficient-way-to-ha
On Wed, Dec 29, 2010 at 5:02 PM, Amaury Forgeot d'Arc
wrote:
> 2010/12/29 David Cournapeau
>>
>> The easiest way I found to emulate git cherry-pick (which does exactly
>> what you want) with hg is to use import/export commands:
>> http://mercurial.selenic.com/wi
7.x buildbot would also include dynamic adjustment of the limit,
which I think based on the prior discussion her was mentioned as being
in 7.3. Though 7.4 releases late in January so could jump right to
that.
-- David
PS: In regards to another comment in this thread, while 7.2 doesn't load
t
luded by default as opposed to needing to be
explicitly loaded.
From the older discussion
(http://mail.python.org/pipermail/python-dev/2010-November/105380.html)
it would appear that 7.x remains fixed sans a kernel build (not
necessarily a big deal for FreeBSD users), but 8.1+ can b
On Sun, 2011-01-02 at 19:18 -0800, Guido van Rossum wrote:
> On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor wrote:
> > No, it's singularly impossible to prove that any global load will be any
> > given
> > value at compile time. Any optimization based on this premise is wrong.
>
> True.
>
> My pr
On Tue, 2011-01-11 at 21:56 +0100, brett.cannon wrote:
> brett.cannon pushed a2d0edc3420e to devguide:
>
> http://hg.python.org/devguide/rev/a2d0edc3420e
> changeset: 83:a2d0edc3420e
> tag: tip
> user:Brett Cannon
> date:Tue Jan 11 12:56:47 2011 -0800
> summary:
> Add
nk I
see any way to accurately test that fact via the buildbots, since
permitting such pop-ups are so disastrous to the overall build
process.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
On Mon, 2011-01-24 at 21:17 +0100, "Martin v. Löwis" wrote:
... snip ...
> I'd like to propose PEP 393, which takes a different approach,
> addressing both problems simultaneously: by getting a flexible
> representation (one that can be either 1, 2, or 4 bytes), we can
> support the full range of
s opposed to it not
working.
For now though, these two external "monitors" seem to have helped
contain the number of manual operations I have to do on my two Windows
slaves. (Though recently I've begun seeing two new sorts of pop-ups
under Windows 7 but both related to memory, so I thi
Is there or will there be support for python merge modules so we can include
python in our installer?
Also, the discussions I saw about windows installers not removing the path on
uninstall is completely false as regards the installers that wix creates, at
least. I've modified the path many tim
>> Is there or will there be support for python merge modules so we can
>> include python in our installer?
>
>I haven't planned any. Contributions are welcome.
>
>> But has there been thought towards migrating away from msilib and using
>> platform standard tools such as wix (used by ms office, vi
> Using msilib is easier than using Wix. It's also more flexible.
IMO, no. It's simply not.
> All you have to know is how the MSI schema works.
Same with WiX.
> It could easily be extended to do so, in a straight-forward manner.
Other packaging apps already have it - no work needed.
> (actual
> If Python was starting at ground zero, and the choices were to create
> a library or to use WiX, the answer might have been different.
> However with a mature enough library to suit all the needs that anyone
> has been willing to author, it's certainly more work to create the WiX
> install and
> I found it much easier to use than WiX, which I also tried.
I also used to use the Visual Studio installer projects until I needed
something a lot more robust (e.g., customized UI + localizable strings). msilib
does the job people need it to do and that's fine. I'm really not trying to
argue
> I hadn't thought it through fully, but the preceding paragraph really
> gets to the core of the problem. The maintenance nightmare is security
> updates for private location installations by third parties. The only
> MSI-friendly way to update that code is through releasing an updated
> merge mod
> At work we keep the required stable UUIDs in an ConfigParser-format
> file checked in to the VCS for that purpose.
>
> FWIW our build system uses WiX (v2) currently and if I where to redo
> it, I'd change to msilib and not WiX v3. But never change working
> systems.
No need to do that if you're
> Can you please cite a source for that recommendation? Preferably
> some MSDN documentation.
http://msdn.microsoft.com/en-us/library/aa368269(v=vs.85).aspx
http://wix.sourceforge.net/manual-wix3/add_a_file.htm
Specifically, starting in bold, where it says "In general, you should restrict
yours
it's unclear whether it is safe to cast a string
literal to char* in these cases. For instance it seems reasonable that
I should be able to call PySys_GetObject("path") without having to
deal with a 'deprecated conversion from string constant to ‘char*’'
error.
Thanks
ssues.
Even if it is eventually decided not to backport those patches to 2.7,
it would be nice if the documentation could be updated to indicate
that strings passed to those functions won't be modified, so that API
users like myself can feel a little safer when passing literals
On Wed, 2011-03-02 at 01:14 +0100, "Martin v. Löwis" wrote:
> > I think a PEP would help, but in this case I would request that before
> > the PEP gets written (it can be a really short one!) somebody actually
> > go out and get consensus from a number of important distros. Besides
> > Barry, do we
On Thu, 2011-03-03 at 14:17 -0500, David Malcolm wrote:
> On Wed, 2011-03-02 at 01:14 +0100, "Martin v. Löwis" wrote:
> There are a number of other rpm packages with names matching "*py*",
> which use the system build of Python 3
Gah; I meant Python 2 here.
(Mus
On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> On 04.03.2011 13:59, Victor Stinner wrote:
> > Hi,
> >
> > Does the bug tracker will continue to support rX links after the
> > migration to Mercurial?
>
> Yes. They will link to http://hg.python.org/lookup/rX, which uses
> the co
hought the buildbot was still attached. In that latter
case I just had to wait long enough for the status page to switch from
idle to disconnected and then try again.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/li
Bill Janssen writes:
> David Bolen wrote:
>
>> Bill Janssen writes:
>>
>> > I'm trying to get a new buildbot in the swim of things, and it keeps
>> > getting into this state where the buildslave process seems caught in an
>> > endless loop.
Bill Janssen writes:
> David Bolen wrote:
>
>> There used to be a way to request a "ping" from the master side (I
>> think on the same page you could manually run a build from) that I
>> would used to force it to recognize a slave was really down, but after
>
s, but looking at it today, it seems to most recently have been
generated back in January. Or is the generated date line wrong?
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
script to automatically
acknowledge these dialogs too going forward, but failures prior to this
point may not be true failures but just fallout from the prior issue.
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mai
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?
Assuming that's the case, is there a way to flush any pending builds
for my slaves before I bring them back online?
Thanks.
-
from
changeset 9c6dcb5d8f01) will likely just take the slaves down again.
Perhaps the test is just too hard to execute reliably on the entire
build farm?
-- David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-d
anually
on one of two of my slaves while I'm watching.
Typically I don't pay too much attention to various failures created
by testing, but this particular case breaks in a way that the slaves don't
recover, so is probably better to put a toe in the water
t
common way to commit a broken working tree is to forget adding a new
file or removing an old file (e.g. the code depends on some old file
which has been removed while the old .pyc is still there), and none of
svn/bzr/hg/git prevents that.
David
___
Python-
Victor Stinner writes:
> Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
>>
>> Speaking of bbreport, I sometimes use the published page on that site
>> (http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
>> over things, but looking at
[CCing Panu Matilainen, the maintainer of rpm, or, at least rpm 4.*,
which is what all major distributions are using AIUI]
On Mon, 2011-03-21 at 10:50 +0100, "Martin v. Löwis" wrote:
> Am 21.03.2011 07:37, schrieb Prashant Kumar:
> > Hello,
> > My name is Prashant Kumar and I've worked on por
t.
I, for example, have cases where I may not automatically want all
cores that regrtest happens to "see" get used, as the slave is doing
other things too. Command line options to regrtest won't help since
that's not something I, as a slave owner, can override for test
builds.
vance when possible in case I need to
make adjustments.
Thanks.
-- David
___
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
On Fri, 2011-04-08 at 21:29 +1000, Nick Coghlan wrote:
> A few odds and ends from recent discussions finally clicked into
> something potentially interesting earlier this evening. Or possibly
> just something insane. I'm not quite decided on that point as yet (but
> leaning towards the latter).
I
On Mon, 2011-04-11 at 07:58 -0400, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 04/10/2011 08:00 PM, Stephen Yeng wrote:
>
> > 11 skips unexpected on linux2:
> > test_bz2 test_dbm_gnu test_dbm_ndbm test_gzip test_readline
> > test_ssl test_tcl test_tk test_t
restore compiler option
cheers,
David
___
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
he buildbots
will be inconsistent, since you're only overriding the regrtest
default in a subset of buildbot types.
-- David
___
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
601 - 700 of 2072 matches
Mail list logo
