New submission from Ed Schouten:
While trying to port Python over to a new platform (CloudABI), I noticed a
couple of compiler errors in PyThread_create_key(), PyThread_delete_key(),
PyThread_delete_key_value() and PyThread_set_key_value() caused by fact that
pthread_key_t is converted
New submission from Ed Schouten:
The SCHED_* constants that are part of POSIX's are all optional:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sched.h.html
Python already declares the SCHED_SPORADIC constant as part of the POSIX module
optionally, depending on whether
New submission from Ed Schouten:
While porting Python over to CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we
stumbled upon a small issue that caused the build to fail.
As CloudABI is a sandboxed runtime environment, there is no support for
accessing
New submission from Ed Schouten:
While porting Python over to CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we
stumbled upon a small issue that caused the build to fail.
As CloudABI is a sandboxed environment, there currently isn't any support for
modifying
New submission from Ed Schouten:
While porting Python over to CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html), we
noticed that the core Python code maps ESHUTDOWN over to BrokenPipeError. This
is fine, except for the fact that ESHUTDOWN is used unconditionally
Ed Schouten added the comment:
I've filed the contributor form earlier today, but I suspect it still takes
some time to get processed.
The reason why the Mercurial headers were missing from the patch was because I
generated this patch from the Python 3.6.0a3 source tarball. I'll make sure
New submission from Ed Schouten:
RFC 6093 states that applications "SHOULD NOT" make use of TCP's out-of-band
data. For this reason, CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html) does not
provide support for it. This means that its poll() function do
New submission from Ed Schouten:
Python's fcntl module already provides some support for making support for file
locking optional. For example, constants like F_SETFL are only defined if
present. Unfortunately, the accompanying functions 'flock()' and 'lockf()' are
present unconditionally
New submission from Ed Schouten:
CloudABI is a sandboxed UNIX-like environment
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html). As it
implements a security framework similar to FreeBSD's Capsicum, file system
access is only permitted by using POSIX-2008-style directory
New submission from Ed Schouten:
POSIX only requires socket types SOCK_STREAM, SOCK_DGRAM and SOCK_SEQPACKET to
be present. SOCK_RAW is optional, as it is placed between [RS] tags in the
specification:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/sys_socket.h.html
It looks like
Ed Schouten added the comment:
That's a very good question. One of the goals of CloudABI's C library is to
leave out definitions for things that are known not to work in the environment.
For example, our doesn't contain open(), as with our security model
(Capsicum), there is nothing
Ed Schouten added the comment:
Believe it our not, dealing with the absence of those system calls is more
contained than you'd think. What is pretty nice about Python is that (almost)
all of the file system operations are performed through posixmodule.c. Most of
the changes in that area
Ed Schouten added the comment:
Sure thing! Attached is an updated patch.
--
Added file: http://bugs.python.org/file44434/patch-arc4random
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ed Schouten added the comment:
I think that PEP 11 also doesn't rule out changes in this area. For example,
consider the paragraph starting with the sentence "This policy does not
disqualify supporting other platforms indirectly. [...]"
Attached is a patch that accomplishe
Ed Schouten added the comment:
Hmmm... Taking a second look at my patch: I still think it's conceptually a
good idea to pursue this, but I think it may be wiser to first focus on the
bits that are strictly necessary from my side. The patch that I've posted
previously has the disadvantage
New submission from Ed Schouten:
Our Autoconf bits already test for the presence of the POSIX 2008
clock_gettime() and clock_getres() functions, which is nice. Still, I'd like to
make two improvements there:
1. In timemodule.c, properly guard the use of clock_getres() bits
Ed Schouten added the comment:
It does. I can now cross build Python for CloudABI by copying importlib.h and
importlib_external.h from the native build directory to the target build
directory. Thanks!
--
___
Python tracker <rep...@bugs.python.
New submission from Ed Schouten:
In issue 28067, we changed _datetimemodule to stop using localtime() and
gmtime(), which is nice. I actually needed such a change for CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html) which does
not provide the thread-unsafe
New submission from Ed Schouten:
Just like the BSDs and Mac OS X, CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html) provides
support for kqueue(). Its implementation, however, is far more limited. It can
only be used for polling on descriptors (EVFILT_READ
New submission from Ed Schouten:
CloudABI (https://mail.python.org/pipermail/python-dev/2016-July/145708.html)
does not provide getpid(). Though this may sound quite silly at first, there is
quite a good reason for this. One of the things that CloudABI wants to achieve
is making large scale
Changes by Ed Schouten <e...@nuxi.nl>:
--
title: Also stop using localtime() in timemodule -> [Patch] Also stop using
localtime() in timemodule
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Ed Schouten added the comment:
Hi Alexander,
I'm absolutely no expert when it comes to the Python codebase, so I've got a
question. If we're going to movein this to Include/pytime.h, we should likely
introduce full wrappers that have a name starting with _PyTime_, right?
This header seem
Ed Schouten added the comment:
As a person who keeps a close eye on the Austin Group mailing lists (i.e., 'the
POSIX working group'), my guess is that it's very unlikely that POSIX will ever
add those *_s() extensions. Here's a discussion on Reddit that actually
captures all of the arguments
Ed Schouten added the comment:
Does this patch look all right to you?
--
Added file: http://bugs.python.org/file44667/patch-pytime-localtime-gmtime
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Ed Schouten added the comment:
I've been brainwashed by
https://google.github.io/styleguide/cppguide.html#Function_Parameter_Ordering
over the last couple of years, which is why I thought
`localtime()/localtime_r()`'s way of ordering the arguments made most sense
here
New submission from Ed Schouten:
CloudABI is a UNIX-like runtime environment that uses a capability-based
security model. As there is no support for traditional UNIX credentials (uid_t,
gid_t), its struct stat doesn't provide st_uid and st_gid.
Python can already deal with the absence
New submission from Ed Schouten:
For CloudABI
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html) we're
providing packages containing a precompiled copy of Python. As we had to make
some changes to importlib (namely to deal with directory file descriptors), we
have to do
Ed Schouten added the comment:
The nice thing is that in our case, the importlib changes are already
compatible with the native build. So yes, we can reuse the frozen module from
the native build. :-)
Ah, yes. Issue 27641 already prevents that it's cross compiled. This patch was
written
New submission from Ed Schouten:
Modern C code should use inet_ntop()/inet_pton() as opposed to
inet_addr()/inet_aton()/inet_ntoa().
Though the former functions may typically act as drop-in replacements for the
latter, the inet_addr()/inet_aton() functions still have the advantage over
Ed Schouten added the comment:
CloudABI uses a structure type, which is exactly why I filed this bug report.
Instead of speculating about what kind of type existing implementations use,
please just focus on the specification to which we're trying to stick: POSIX.
http://pubs.opengroup.org
Ed Schouten added the comment:
It can also be a structure or a union.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25658>
___
__
New submission from Ed Schouten:
The '_crypt' module provides a binding to the C crypt(3) function. It is used
by the crypt.crypt() function.
Looking at the C code, there are a couple of things we can improve:
- Because crypt() only depends on primitive C types, we currently get away
New submission from Ed Schouten:
CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we
got Python to work
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches
for this are slowly being upstreamed.
As CloudABI uses a capability-based security
Ed Schouten added the comment:
Attached is an updated version of the patch that applies cleanly against Python
3.6.0b2.
--
Added file: http://bugs.python.org/file45181/27701.diff
___
Python tracker <rep...@bugs.python.org>
<http://bugs.p
New submission from Ed Schouten:
CloudABI is a POSIX-like strongly sandboxed runtime environment, for which we
got Python to work
(https://mail.python.org/pipermail/python-dev/2016-July/145708.html). Patches
for this are slowly being upstreamed.
CloudABI uses a capability-based security
Ed Schouten added the comment:
Looks good to me!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25658>
___
___
Python-bugs-list
Ed Schouten <e...@nuxi.nl> added the comment:
Ah, you folks switched to Git + Github in the mean time. Nice!
I've just sent this pull request: https://github.com/python/cpython/pull/4691
--
___
Python tracker <rep...@bugs.python.or
Ed Schouten <e...@nuxi.nl> added the comment:
Having looked at various implementations of crypt() and crypt_r(), I can't
think of a reason why there would be any significant difference in performance.
On systems like FreeBSD, crypt() is just a simple wrapper around crypt_r():
38 matches
Mail list logo
