On 27 July 2013 14:36, Guido van Rossum wrote:
> On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith wrote:
>>
>> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
>>>
>>> On Sat, 27 Jul 2013 00:18:40 +0200
>>> Victor Stinner wrote:
>>> > 2013/7/26 Antoine Pitrou :
>>> > > On Fri, 26 Jul 201
On Fri, Jul 26, 2013 at 9:26 PM, Gregory P. Smith wrote:
>
> On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
>>
>> On Sat, 27 Jul 2013 00:18:40 +0200
>> Victor Stinner wrote:
>> > 2013/7/26 Antoine Pitrou :
>> > > On Fri, 26 Jul 2013 22:17:47 +0200
>> > >> """
>> > >> On Linux, setting th
On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote:
> On Sat, 27 Jul 2013 00:18:40 +0200
> Victor Stinner wrote:
> > 2013/7/26 Antoine Pitrou :
> > > On Fri, 26 Jul 2013 22:17:47 +0200
> > >> """
> > >> On Linux, setting the close-on-flag has a low overhead on
> > >> performances. Results of
On Sat, 27 Jul 2013 00:18:40 +0200
Victor Stinner wrote:
> 2013/7/26 Antoine Pitrou :
> > On Fri, 26 Jul 2013 22:17:47 +0200
> >> """
> >> On Linux, setting the close-on-flag has a low overhead on
> >> performances. Results of bench_cloexec.py on Linux 3.6:
> >>
> >> - close-on-flag not set: 7.8 u
2013/7/26 Antoine Pitrou :
> On Fri, 26 Jul 2013 22:17:47 +0200
>> """
>> On Linux, setting the close-on-flag has a low overhead on
>> performances. Results of bench_cloexec.py on Linux 3.6:
>>
>> - close-on-flag not set: 7.8 us
>> - O_CLOEXEC: 1% slower (7.9 us)
>> - ioctl(): 3% slower (8.0 us)
>>
On Fri, Jul 26, 2013 at 5:08 AM, Victor Stinner
wrote:
> After having written 2 PEP on the topic, I slowly agree that make all
> file descriptors non-inheritable is the best *compromise*. It solves
> most, or all, issues.
Right.
> The main drawback is the additionnal syscalls: on some platforms,
On Fri, 26 Jul 2013 22:17:47 +0200
Victor Stinner wrote:
> 2013/7/26 Antoine Pitrou :
> >> The main drawback is the additionnal syscalls: on some platforms, 2
> >> additional syscalls are need to make a file descriptor non-inheritable
> >> for each creation of file descriptor. According to my ben
2013/7/26 Antoine Pitrou :
>> The main drawback is the additionnal syscalls: on some platforms, 2
>> additional syscalls are need to make a file descriptor non-inheritable
>> for each creation of file descriptor. According to my benchmark on the
>> implementation of the PEP 433: the overhead of mak
Am 26.07.2013 16:29, schrieb Brett Cannon:
> Have you tried asking for help from Coverity? They have been rather nice
> so far and they may be willing to just give us free help in getting the
> modeling file set up properly.
Yes, I'm in contact with Dakshesh. I was able to figure out one model
for
On Fri, 26 Jul 2013 09:38:10 +0200
Ronald Oussoren wrote:
>
> On 25 Jul, 2013, at 4:18, Ben Finney wrote:
>
> > Ben Finney writes:
> >
> >> Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to
> >> Python 3 and aiming for inclusion in the standard library.
>
> At first gl
ACTIVITY SUMMARY (2013-07-19 - 2013-07-26)
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:
open4114 (+22)
closed 26220 (+35)
total 30334 (+57)
Open issues wit
On Fri, Jul 26, 2013 at 7:29 AM, Christian Heimes wrote:
> Am 26.07.2013 14:56, schrieb Eli Bendersky:
> > Just a quick question - is there a chance to convince Coverity to detect
> > Python refcounting leaks in C API code :-) ? This could be useful not
> > only for Python but for extensions too.
Le Fri, 26 Jul 2013 16:29:59 +0200,
Christian Heimes a écrit :
> Coverity is able to detect some cases of refcount leaks. I don't know
> if the software is able to keep track of all reference counts. But it
> understands missing Py_DECREF() in error branches.
>
> For example:
>
> PyObject *n = P
On Fri, Jul 26, 2013 at 8:56 AM, Eli Bendersky wrote:
> Just a quick question - is there a chance to convince Coverity to detect
> Python refcounting leaks in C API code :-) ?
>
You can always ask. =)
> This could be useful not only for Python but for extensions too. As it
> stands now, Coveri
On Thu, Jul 25, 2013 at 6:56 PM, Christian Heimes wrote:
> Am 26.07.2013 00:32, schrieb Terry Reedy:
> > I found the answer here
> > https://docs.google.com/file/d/0B5wQCOK_TiRiMWVqQ0xPaDEzbkU/edit
> > Coverity Integrity Level 1 is 1 (defect/1000 lines)
> > Level 2 is .1 (we have passed that)
> >
Am 26.07.2013 14:56, schrieb Eli Bendersky:
> Just a quick question - is there a chance to convince Coverity to detect
> Python refcounting leaks in C API code :-) ? This could be useful not
> only for Python but for extensions too. As it stands now, Coverity's
> leak detection is Python must be pr
Just a quick question - is there a chance to convince Coverity to detect
Python refcounting leaks in C API code :-) ? This could be useful not only
for Python but for extensions too. As it stands now, Coverity's leak
detection is Python must be pretty weak because almost everything is done
via PyOb
Le Fri, 26 Jul 2013 14:08:35 +0200,
Victor Stinner a écrit :
>
> After having written 2 PEP on the topic, I slowly agree that make all
> file descriptors non-inheritable is the best *compromise*. It solves
> most, or all, issues.
Even stdin/stdout/stderr? I think inheriting them is the sane defa
2013/7/24 Guido van Rossum :
> But I'm also ready to propose that all this is such a mess that we
> *should* change the default fd/handle inheritance to False, *across
> platforms*, and damn the torpedoes -- i.e. accept breaking all
> existing 3rd party UNIX code for subprocess creation that bypass
On 26 July 2013 21:46, Antoine Pitrou wrote:
> Le Fri, 26 Jul 2013 20:51:16 +1000,
> Nick Coghlan a écrit :
>>
>> I believe Hosted is already running 2.0, so that's the one that
>> impressed me.
>
> Strange. Apparently, free trial accounts get a 1.7.1 version:
> "RhodeCode 1.7.1.hosted.4356".
> F
Le Fri, 26 Jul 2013 20:51:16 +1000,
Nick Coghlan a écrit :
>
> I believe Hosted is already running 2.0, so that's the one that
> impressed me.
Strange. Apparently, free trial accounts get a 1.7.1 version:
"RhodeCode 1.7.1.hosted.4356".
From my POV, it would need a ton of UI polish before being p
On 26 July 2013 18:14, Antoine Pitrou wrote:
> Le Fri, 26 Jul 2013 10:03:26 +0200,
> Dirkjan Ochtman a écrit :
>> On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou
>> wrote:
>> >> (For those that haven't seen it, RhodeCode seems broadly
>> >> comparable to BitBucket feature wise, but because of th
Le Fri, 26 Jul 2013 10:03:26 +0200,
Dirkjan Ochtman a écrit :
> On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou
> wrote:
> >> (For those that haven't seen it, RhodeCode seems broadly
> >> comparable to BitBucket feature wise, but because of the way it is
> >> licensed, the source code is freely a
On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou wrote:
>> (For those that haven't seen it, RhodeCode seems broadly comparable to
>> BitBucket feature wise, but because of the way it is licensed, the
>> source code is freely available to all, and running your own instance
>> is free-as-in-beer for
On 26 Jul, 2013, at 9:50, Antoine Pitrou wrote:
> Le Fri, 26 Jul 2013 09:31:50 +1000,
> Nick Coghlan a écrit :
>>
>> To be honest, if people are going to spend time tinkering with our VCS
>> infrastructure, one of the most interesting things we could do is
>> explore what would be involved in
On 26 July 2013 08:50, Antoine Pitrou wrote:
> > (For those that haven't seen it, RhodeCode seems broadly comparable to
> > BitBucket feature wise, but because of the way it is licensed, the
> > source code is freely available to all, and running your own instance
> > is free-as-in-beer for non-p
Le Fri, 26 Jul 2013 09:31:50 +1000,
Nick Coghlan a écrit :
>
> To be honest, if people are going to spend time tinkering with our VCS
> infrastructure, one of the most interesting things we could do is
> explore what would be involved in setting up RhodeCode on
> hg.python.org :)
>
> (For those
On 25 Jul, 2013, at 4:18, Ben Finney wrote:
> Ben Finney writes:
>
>> Work continues on the PEP 3143-compatible ‘python-daemon’, porting it to
>> Python 3 and aiming for inclusion in the standard library.
At first glance the library appears to close all open files, with an option
to exclude s
Antoine Pitrou writes:
> Therefore I'd be -1 on [PEP 3143] until those issues are alleviated.
Cameron Simpson writes:
> I have always found the convention that daemons have a umask of 0
> to be utterly bogus, because almost all library code relies on the
> umask to set default security policy
29 matches
Mail list logo
