Re: [Python-Dev] Friendly reminder: be kind to one another

[Antoine Pitrou]

This is missing a bit of context.  Is this about python-dev?  Some
other ML?

Regards

Antoine.


On Tue, 30 Jan 2018 02:16:14 +
Brett Cannon  wrote:
> Over the last 3 days I have had two situations come up where I was asked
> for my opinion in regards to possible CoC violations. I just wanted to take
> this opportunity to remind everyone that open source does not work if we
> are not open, considerate, and respectful to one another (which also
> happens to be the PSF CoC that we are all expected to follow when working
> on Python). When we stop being kind to each other is when open source falls
> apart because it drives people away, and for a project that is driven by
> volunteers like Python that will be what ends this project (not to say
> people should be rude to corporate open source projects, but they can
> simply choose to switch to a core dump approach of open source).
> 
> I gave a talk at PyCascades this past week on setting expectations for open
> source participation: https://youtu.be/HiWfqMbJ3_8?t=7m24s . I had at least
> one person who was upset about no one getting to their pull request quickly
> come up to me afterwards and apologize for ever feeling that way after
> watching my talk, so do please watch it if you have ever felt angry at an
> open source maintainer or contributor to help keep things in perspective.
> 
> I also wanted to say that I think core developers should work extra hard to
> be kind as we help set the tone for this project which can leak into the
> broader community. People with commit privileges are not beyond rebuke and
> so people should never feel they are not justified speaking up when they
> feel a core developer has been rude to them.
> 
> Anyway, the key point is to remember is that people are what make this
> project and community work, so please make sure that you do what you can to
> keep people wanting to participate.
> 



___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] OS-X builds for 3.7.0

[Chris Barker]

Ned,

It looks like you're still building OS-X the same way as in the past:

Intel 32+64 bit, 10.6 compatibility

Is that right?

Might it be time for an update?

Do we still need to support 32 bit?  From:

https://apple.stackexchange.com/questions/99640/how-old-are-macs-that-cannot-run-64-bit-applications

There has not been a 32 bit-only Mac sold since 2006, and a out-of the box
32 bit OS since 2006 or 2007

I can't find out what the older OS version Apple supports, but I know my IT
dept has been making me upgrade, so I"m going to guess 10.8 or newer...

And maybe we could even get rid of the "Framework" builds..

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Ray Donnelly]

On Tue, Jan 30, 2018 at 5:42 PM, Chris Barker  wrote:
> Ned,
>
> It looks like you're still building OS-X the same way as in the past:
>
> Intel 32+64 bit, 10.6 compatibility
>
> Is that right?
>
> Might it be time for an update?
>
> Do we still need to support 32 bit?  From:
>
> https://apple.stackexchange.com/questions/99640/how-old-are-macs-that-cannot-run-64-bit-applications
>
> There has not been a 32 bit-only Mac sold since 2006, and a out-of the box
> 32 bit OS since 2006 or 2007
>
> I can't find out what the older OS version Apple supports, but I know my IT
> dept has been making me upgrade, so I"m going to guess 10.8 or newer...
>
> And maybe we could even get rid of the "Framework" builds..

While we're making such macOS-build requests, any chance of building a
static interpreter too? We've been doing that on the Anaconda
Distribution since the 5.0 release in September and it seems to be
working well.

>
> -CHB
>
>
> --
>
> Christopher Barker, Ph.D.
> Oceanographer
>
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
>
> chris.bar...@noaa.gov
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/mingw.android%40gmail.com
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Friendly reminder: be kind to one another

[Paul Moore]

On 30 January 2018 at 17:10, Antoine Pitrou  wrote:
>
> This is missing a bit of context.  Is this about python-dev?  Some
> other ML?

While I'll admit to being curious about what prompted this, honestly,
it's none of my business - and so I think that Brett's posting should
be viewed as a general reminder, without any specific context implied.

Paul
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Matt Billenstein]

On Tue, Jan 30, 2018 at 09:42:07AM -0800, Chris Barker wrote:
>IT dept has been making me upgrade, so I"m going to guess 10.8 or newer...

OSX is in a sad state linking to system libs on the later releases -- maybe
10.11 and on, not sure of the exact release -- they stopped shipping the
headers for things like ssl and ffi since they don't want 3rd parties linking
to deprecated versions of those libraries versus, in the case of ssl, their
newer security framework.  Recommendation is to bundle what you need if you're
not using the framework -- something to think about.

thx

m

-- 
Matt Billenstein
m...@vazor.com
http://www.vazor.com/
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Joni Orponen]

On Tue, Jan 30, 2018 at 6:42 PM, Chris Barker  wrote:
>
> And maybe we could even get rid of the "Framework" builds..
>

Please do not. These make life easier for doing things the Apple way for
signed sandboxed applications.

Joining the discussion here from a ~cross-post on pythonmac-sig:
https://mail.python.org/pipermail/pythonmac-sig/2018-January/024283.html

-- 
Joni Orponen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Joni Orponen]

On Tue, Jan 30, 2018 at 7:08 PM, Matt Billenstein  wrote:

> OSX is in a sad state linking to system libs on the later releases -- maybe
> 10.11 and on, not sure of the exact release -- they stopped shipping the
> headers for things like ssl and ffi since they don't want 3rd parties
> linking
> to deprecated versions of those libraries versus, in the case of ssl, their
> newer security framework.  Recommendation is to bundle what you need if
> you're
> not using the framework -- something to think about.


There are also some practical issues with trying to distribute software
using some deprecated Cocoa APIs or weak linked syscalls. The pythonmac-sig
thead I linked to earlier has pointers to how to flare those up if one ever
needs to distribute Python to a specific macOS version target range while
compiling on a newer macOS.

It would be nice to do more things the Apple way, including porting to
modern runtime feature availability check cascades of the Cocoa APIs and
using the Apple provided system Frameworks. This seems like a rather major
workload and should be targeting 3.8. I'm willing to participate in that
effort.

The availability of syscalls across targets when cross-compiling for an
older target is a more generic build system problem and I'm not sure if
Python should do anything other than just document it being a thing. I'm
personally fine patching pyconfig.h after running the configure script for
this special case.

As suggested on pythonmac-sig, I'd like to see 10.11 get chosen as the
macOS to build on as it provides a decent balance between hardware
compatibility and being new(er).

-- 
Joni Orponen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Joni Orponen]

On Tue, Jan 30, 2018 at 6:50 PM, Ray Donnelly 
wrote:

> While we're making such macOS-build requests, any chance of building a
> static interpreter too? We've been doing that on the Anaconda
> Distribution since the 5.0 release in September and it seems to be
> working well.
>

PyPy is also currently eyeing doing their macOS builds better:
https://bitbucket.org/pypy/pypy/issues/2734/establish-a-build-and-release-pipeline-for

What do the Anaconda static builds get built on?

-- 
Joni Orponen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Florian Weimer]

I hope this is the right list for this kind of question.  We recently
tried to build Python 2.6 with GCC 8, and ran into this issue:

  

Also quoting for context:

| PyInstance_NewRaw contains this code:
| 
| inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type);
| if (inst == NULL) {
| Py_DECREF(dict);
| return NULL;
| }
| inst->in_weakreflist = NULL;
| Py_INCREF(klass);
| inst->in_class = (PyClassObject *)klass;
| inst->in_dict = dict;
| _PyObject_GC_TRACK(inst);
| 
| _PyObject_GC_TRACK expands to:
| 
| #define _PyObject_GC_TRACK(o) do { \
| PyGC_Head *g = _Py_AS_GC(o); \
| if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
| Py_FatalError("GC object already tracked"); \
| …
| 
| Via:
| 
| #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
| 
| We get to this:
| 
| /* GC information is stored BEFORE the object structure. */
| typedef union _gc_head {
| struct {
| union _gc_head *gc_next;
| union _gc_head *gc_prev;
| Py_ssize_t gc_refs;
| } gc;
| long double dummy;  /* force worst-case alignment */
| } PyGC_Head;
| 
| PyGC_Head has 16-byte alignment.  The net result is that
| 
| _PyObject_GC_TRACK(inst);
| 
| promises to the compiler that inst is properly aligned for the
| PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which
| is only 8-byte-aligned.
| 
| Objects/obmalloc.c contains this:
| 
| /*
|  * Alignment of addresses returned to the user. 8-bytes alignment works
|  * on most current architectures (with 32-bit or 64-bit address busses).
|  * The alignment value is also used for grouping small requests in size
|  * classes spaced ALIGNMENT bytes apart.
|  *
|  * You shouldn't change this unless you know what you are doing.
|  */
| #define ALIGNMENT   8   /* must be 2^N */
| #define ALIGNMENT_SHIFT 3
| #define ALIGNMENT_MASK  (ALIGNMENT - 1)
| 
| So either the allocator alignment needs to be increased, or the
| PyGC_Head alignment needs to be decreased.

Is this a known issue?  As far as I can see, it has not been fixed on
the 2.7 branch.

(Store merging is a relatively new GCC feature.  Among other things,
this means that on x86-64, for sufficiently aligned pointers, vector
instructions are used to update multiple struct fields at once.  These
vector instructions can trigger alignment traps, similar to what
happens on some other architectures for scalars.)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Friendly reminder: be kind to one another

[Brett Cannon]

On Tue, 30 Jan 2018 at 10:01 Paul Moore  wrote:

> On 30 January 2018 at 17:10, Antoine Pitrou  wrote:
> >
> > This is missing a bit of context.  Is this about python-dev?  Some
> > other ML?
>
> While I'll admit to being curious about what prompted this, honestly,
> it's none of my business - and so I think that Brett's posting should
> be viewed as a general reminder, without any specific context implied.
>

What Paul said. :)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Gregory P. Smith]

The proper fix for this in the code would likely break ABI compatibility
(ie: not possible in python 2.7 or any other stable release).

Clang's UBSAN (undefined behavior sanitizer) has been flagging this one for
a long time.

In Python 3 a double is used instead of long double since 2012 as I did
some digging at the time:
https://github.com/python/cpython/commit/e348c8d154cf6342c79d627ebfe89dfe9de23817

-gps

On Tue, Jan 30, 2018 at 10:59 AM Florian Weimer  wrote:

> I hope this is the right list for this kind of question.  We recently
> tried to build Python 2.6 with GCC 8, and ran into this issue:
>
>   
>
> Also quoting for context:
>
> | PyInstance_NewRaw contains this code:
> |
> | inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type);
> | if (inst == NULL) {
> | Py_DECREF(dict);
> | return NULL;
> | }
> | inst->in_weakreflist = NULL;
> | Py_INCREF(klass);
> | inst->in_class = (PyClassObject *)klass;
> | inst->in_dict = dict;
> | _PyObject_GC_TRACK(inst);
> |
> | _PyObject_GC_TRACK expands to:
> |
> | #define _PyObject_GC_TRACK(o) do { \
> | PyGC_Head *g = _Py_AS_GC(o); \
> | if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
> | Py_FatalError("GC object already tracked"); \
> | …
> |
> | Via:
> |
> | #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
> |
> | We get to this:
> |
> | /* GC information is stored BEFORE the object structure. */
> | typedef union _gc_head {
> | struct {
> | union _gc_head *gc_next;
> | union _gc_head *gc_prev;
> | Py_ssize_t gc_refs;
> | } gc;
> | long double dummy;  /* force worst-case alignment */
> | } PyGC_Head;
> |
> | PyGC_Head has 16-byte alignment.  The net result is that
> |
> | _PyObject_GC_TRACK(inst);
> |
> | promises to the compiler that inst is properly aligned for the
> | PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which
> | is only 8-byte-aligned.
> |
> | Objects/obmalloc.c contains this:
> |
> | /*
> |  * Alignment of addresses returned to the user. 8-bytes alignment works
> |  * on most current architectures (with 32-bit or 64-bit address busses).
> |  * The alignment value is also used for grouping small requests in size
> |  * classes spaced ALIGNMENT bytes apart.
> |  *
> |  * You shouldn't change this unless you know what you are doing.
> |  */
> | #define ALIGNMENT   8   /* must be 2^N */
> | #define ALIGNMENT_SHIFT 3
> | #define ALIGNMENT_MASK  (ALIGNMENT - 1)
> |
> | So either the allocator alignment needs to be increased, or the
> | PyGC_Head alignment needs to be decreased.
>
> Is this a known issue?  As far as I can see, it has not been fixed on
> the 2.7 branch.
>
> (Store merging is a relatively new GCC feature.  Among other things,
> this means that on x86-64, for sufficiently aligned pointers, vector
> instructions are used to update multiple struct fields at once.  These
> vector instructions can trigger alignment traps, similar to what
> happens on some other architectures for scalars.)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Gregory P. Smith]

I'm curious if changing the obmalloc.c ALIGNMENT and ALIGNMENT_SHIFT
defines is sufficient to avoid ABI breakage.

-gps

On Tue, Jan 30, 2018 at 1:20 PM Gregory P. Smith  wrote:

> The proper fix for this in the code would likely break ABI compatibility
> (ie: not possible in python 2.7 or any other stable release).
>
> Clang's UBSAN (undefined behavior sanitizer) has been flagging this one
> for a long time.
>
> In Python 3 a double is used instead of long double since 2012 as I did
> some digging at the time:
> https://github.com/python/cpython/commit/e348c8d154cf6342c79d627ebfe89dfe9de23817
>
> -gps
>
> On Tue, Jan 30, 2018 at 10:59 AM Florian Weimer  wrote:
>
>> I hope this is the right list for this kind of question.  We recently
>> tried to build Python 2.6 with GCC 8, and ran into this issue:
>>
>>   
>>
>> Also quoting for context:
>>
>> | PyInstance_NewRaw contains this code:
>> |
>> | inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type);
>> | if (inst == NULL) {
>> | Py_DECREF(dict);
>> | return NULL;
>> | }
>> | inst->in_weakreflist = NULL;
>> | Py_INCREF(klass);
>> | inst->in_class = (PyClassObject *)klass;
>> | inst->in_dict = dict;
>> | _PyObject_GC_TRACK(inst);
>> |
>> | _PyObject_GC_TRACK expands to:
>> |
>> | #define _PyObject_GC_TRACK(o) do { \
>> | PyGC_Head *g = _Py_AS_GC(o); \
>> | if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
>> | Py_FatalError("GC object already tracked"); \
>> | …
>> |
>> | Via:
>> |
>> | #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
>> |
>> | We get to this:
>> |
>> | /* GC information is stored BEFORE the object structure. */
>> | typedef union _gc_head {
>> | struct {
>> | union _gc_head *gc_next;
>> | union _gc_head *gc_prev;
>> | Py_ssize_t gc_refs;
>> | } gc;
>> | long double dummy;  /* force worst-case alignment */
>> | } PyGC_Head;
>> |
>> | PyGC_Head has 16-byte alignment.  The net result is that
>> |
>> | _PyObject_GC_TRACK(inst);
>> |
>> | promises to the compiler that inst is properly aligned for the
>> | PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which
>> | is only 8-byte-aligned.
>> |
>> | Objects/obmalloc.c contains this:
>> |
>> | /*
>> |  * Alignment of addresses returned to the user. 8-bytes alignment works
>> |  * on most current architectures (with 32-bit or 64-bit address busses).
>> |  * The alignment value is also used for grouping small requests in size
>> |  * classes spaced ALIGNMENT bytes apart.
>> |  *
>> |  * You shouldn't change this unless you know what you are doing.
>> |  */
>> | #define ALIGNMENT   8   /* must be 2^N */
>> | #define ALIGNMENT_SHIFT 3
>> | #define ALIGNMENT_MASK  (ALIGNMENT - 1)
>> |
>> | So either the allocator alignment needs to be increased, or the
>> | PyGC_Head alignment needs to be decreased.
>>
>> Is this a known issue?  As far as I can see, it has not been fixed on
>> the 2.7 branch.
>>
>> (Store merging is a relatively new GCC feature.  Among other things,
>> this means that on x86-64, for sufficiently aligned pointers, vector
>> instructions are used to update multiple struct fields at once.  These
>> vector instructions can trigger alignment traps, similar to what
>> happens on some other architectures for scalars.)
>> ___
>> Python-Dev mailing list
>> Python-Dev@python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
>>
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Victor Stinner]

See https://bugs.python.org/issue31912 and https://bugs.python.org/issue27987

Victor

2018-01-30 19:56 GMT+01:00 Florian Weimer :
> I hope this is the right list for this kind of question.  We recently
> tried to build Python 2.6 with GCC 8, and ran into this issue:
>
>   
>
> Also quoting for context:
>
> | PyInstance_NewRaw contains this code:
> |
> | inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type);
> | if (inst == NULL) {
> | Py_DECREF(dict);
> | return NULL;
> | }
> | inst->in_weakreflist = NULL;
> | Py_INCREF(klass);
> | inst->in_class = (PyClassObject *)klass;
> | inst->in_dict = dict;
> | _PyObject_GC_TRACK(inst);
> |
> | _PyObject_GC_TRACK expands to:
> |
> | #define _PyObject_GC_TRACK(o) do { \
> | PyGC_Head *g = _Py_AS_GC(o); \
> | if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
> | Py_FatalError("GC object already tracked"); \
> | …
> |
> | Via:
> |
> | #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
> |
> | We get to this:
> |
> | /* GC information is stored BEFORE the object structure. */
> | typedef union _gc_head {
> | struct {
> | union _gc_head *gc_next;
> | union _gc_head *gc_prev;
> | Py_ssize_t gc_refs;
> | } gc;
> | long double dummy;  /* force worst-case alignment */
> | } PyGC_Head;
> |
> | PyGC_Head has 16-byte alignment.  The net result is that
> |
> | _PyObject_GC_TRACK(inst);
> |
> | promises to the compiler that inst is properly aligned for the
> | PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which
> | is only 8-byte-aligned.
> |
> | Objects/obmalloc.c contains this:
> |
> | /*
> |  * Alignment of addresses returned to the user. 8-bytes alignment works
> |  * on most current architectures (with 32-bit or 64-bit address busses).
> |  * The alignment value is also used for grouping small requests in size
> |  * classes spaced ALIGNMENT bytes apart.
> |  *
> |  * You shouldn't change this unless you know what you are doing.
> |  */
> | #define ALIGNMENT   8   /* must be 2^N */
> | #define ALIGNMENT_SHIFT 3
> | #define ALIGNMENT_MASK  (ALIGNMENT - 1)
> |
> | So either the allocator alignment needs to be increased, or the
> | PyGC_Head alignment needs to be decreased.
>
> Is this a known issue?  As far as I can see, it has not been fixed on
> the 2.7 branch.
>
> (Store merging is a relatively new GCC feature.  Among other things,
> this means that on x86-64, for sufficiently aligned pointers, vector
> instructions are used to update multiple struct fields at once.  These
> vector instructions can trigger alignment traps, similar to what
> happens on some other architectures for scalars.)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Chris Barker - NOAA Federal]

And maybe we could even get rid of the "Framework" builds..
>

Please do not. These make life easier for doing things the Apple way for
signed sandboxed applications.


Thanks — good to hear there is a good reason for them. I’ve always thought
that Frameworks were designed with other use-casss, and didn’t really help
with Python.

For the record, are you re-distributing the python.org builds, or
re-building yourself?

-CHB



Joining the discussion here from a ~cross-post on pythonmac-sig:
https://mail.python.org/pipermail/pythonmac-sig/2018-January/024283.html

-- 
Joni Orponen

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/chris.barker%40noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] OS-X builds for 3.7.0

[Chris Barker - NOAA Federal]

> It would be nice to do more things the Apple way, including porting to modern 
> runtime feature availability check cascades of the Cocoa APIs and using the 
> Apple provided system Frameworks. This seems like a rather major workload and 
> should be targeting 3.8.

Yeah — too much to do for 3.7 at this stage.

But what about dropping 32 bit and maybe bumping the OS up? Maybe
10.11 is too new, but something newer than 10.6?

Or maybe 10.11 is a good target — looks like it’s been around 2+
years, and Apple now provides free updates.

-CHB
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Friendly reminder: be kind to one another

[Steven D'Aprano]

On Tue, Jan 30, 2018 at 06:00:36PM +, Paul Moore wrote:
> On 30 January 2018 at 17:10, Antoine Pitrou  wrote:
> >
> > This is missing a bit of context.  Is this about python-dev?  Some
> > other ML?
> 
> While I'll admit to being curious about what prompted this, honestly,
> it's none of my business - and so I think that Brett's posting should
> be viewed as a general reminder, without any specific context implied.

But specific content was not just implied but explicitly eluded to: 
Brett stated that 

"the last 3 days I have had two situations come up where I was asked
for my opinion in regards to possible CoC violations"

so it is our business and every one of us should be wondering what we 
personally might have written that could have been a possible CoC 
violation, on this or some other list.

As Brett says, none of us are beyond reproach.


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Friendly reminder: be kind to one another

[Brett Cannon]

On Tue, Jan 30, 2018, 17:30 Steven D'Aprano,  wrote:

> On Tue, Jan 30, 2018 at 06:00:36PM +, Paul Moore wrote:
> > On 30 January 2018 at 17:10, Antoine Pitrou  wrote:
> > >
> > > This is missing a bit of context.  Is this about python-dev?  Some
> > > other ML?
> >
> > While I'll admit to being curious about what prompted this, honestly,
> > it's none of my business - and so I think that Brett's posting should
> > be viewed as a general reminder, without any specific context implied.
>
> But specific content was not just implied but explicitly eluded to:
> Brett stated that
>
> "the last 3 days I have had two situations come up where I was asked
> for my opinion in regards to possible CoC violations"
>
> so it is our business and every one of us should be wondering what we
> personally might have written that could have been a possible CoC
> violation, on this or some other list.
>

In both instances the people who were involved have been spoken to, so if
no one talked with you about how they felt then it wasn't you (i.e. I'm not
being vague to make everyone tread carefully in case it's them). As I said,
people just asked for my opinion and I provided it.

At this point please just ignore my comment about what personally triggered
the email. It's not the focal point of what I was hoping to communicate,
just so the email didn't seem totally random is all.

-Brett



> As Brett says, none of us are beyond reproach.



>
> --
> Steve
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Making "-j0" the default setting for the test suite?

[Nick Coghlan]

On 30 January 2018 at 02:39, Victor Stinner  wrote:
>> * "-j1" would explicitly turn off multiprocessing
>
> Running tests "sequentially" but run them in one subprocess per test
> file is interesting for tests isolation. Runing tests one by one
> reduces the risk of triggering a race condition (test only failing
> when the system load is high).
>
> -jN was always documented as "use multiprocessing".
>
> Maybe we need a new option to explicitly disable multiprocessing instead?
>
>vstinner@apu$ ./python -m test
>Run tests sequentially
>
> vs
>
>vstinner@apu$ ./python -m test -j1
>Run tests in parallel using 1 child processes

Hmm, that's a good point.

Maybe a less intrusive alternative would be akin to what we did with
the configure script for non-optimised builds: when we display the
total duration at the end, append a note in the serial execution case.

Something like:

Total duration: 16 minutes 33 seconds (serial execution, pass
'-j0' for parallel execution)

Such a change would be a safe way to nudge new contributors towards
"./python -m test -j0" for faster local testing, without risking
backwards compatibility issues with existing test suite invocations in
other contexts.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Benjamin Peterson]

Yes, changing obmalloc.c's alignment guarantees would definitely be the easiest 
solution. I think someone just needs to investigate whether it wastes a lot of 
memory.

On Tue, Jan 30, 2018, at 13:22, Gregory P. Smith wrote:
> I'm curious if changing the obmalloc.c ALIGNMENT and ALIGNMENT_SHIFT
> defines is sufficient to avoid ABI breakage.
> 
> -gps
> 
> On Tue, Jan 30, 2018 at 1:20 PM Gregory P. Smith  wrote:
> 
> > The proper fix for this in the code would likely break ABI compatibility
> > (ie: not possible in python 2.7 or any other stable release).
> >
> > Clang's UBSAN (undefined behavior sanitizer) has been flagging this one
> > for a long time.
> >
> > In Python 3 a double is used instead of long double since 2012 as I did
> > some digging at the time:
> > https://github.com/python/cpython/commit/e348c8d154cf6342c79d627ebfe89dfe9de23817
> >
> > -gps
> >
> > On Tue, Jan 30, 2018 at 10:59 AM Florian Weimer  wrote:
> >
> >> I hope this is the right list for this kind of question.  We recently
> >> tried to build Python 2.6 with GCC 8, and ran into this issue:
> >>
> >>   
> >>
> >> Also quoting for context:
> >>
> >> | PyInstance_NewRaw contains this code:
> >> |
> >> | inst = PyObject_GC_New(PyInstanceObject, &PyInstance_Type);
> >> | if (inst == NULL) {
> >> | Py_DECREF(dict);
> >> | return NULL;
> >> | }
> >> | inst->in_weakreflist = NULL;
> >> | Py_INCREF(klass);
> >> | inst->in_class = (PyClassObject *)klass;
> >> | inst->in_dict = dict;
> >> | _PyObject_GC_TRACK(inst);
> >> |
> >> | _PyObject_GC_TRACK expands to:
> >> |
> >> | #define _PyObject_GC_TRACK(o) do { \
> >> | PyGC_Head *g = _Py_AS_GC(o); \
> >> | if (g->gc.gc_refs != _PyGC_REFS_UNTRACKED) \
> >> | Py_FatalError("GC object already tracked"); \
> >> | …
> >> |
> >> | Via:
> >> |
> >> | #define _Py_AS_GC(o) ((PyGC_Head *)(o)-1)
> >> |
> >> | We get to this:
> >> |
> >> | /* GC information is stored BEFORE the object structure. */
> >> | typedef union _gc_head {
> >> | struct {
> >> | union _gc_head *gc_next;
> >> | union _gc_head *gc_prev;
> >> | Py_ssize_t gc_refs;
> >> | } gc;
> >> | long double dummy;  /* force worst-case alignment */
> >> | } PyGC_Head;
> >> |
> >> | PyGC_Head has 16-byte alignment.  The net result is that
> >> |
> >> | _PyObject_GC_TRACK(inst);
> >> |
> >> | promises to the compiler that inst is properly aligned for the
> >> | PyGC_Head type, but it is not: PyObject_GC_New returns a pointer which
> >> | is only 8-byte-aligned.
> >> |
> >> | Objects/obmalloc.c contains this:
> >> |
> >> | /*
> >> |  * Alignment of addresses returned to the user. 8-bytes alignment works
> >> |  * on most current architectures (with 32-bit or 64-bit address busses).
> >> |  * The alignment value is also used for grouping small requests in size
> >> |  * classes spaced ALIGNMENT bytes apart.
> >> |  *
> >> |  * You shouldn't change this unless you know what you are doing.
> >> |  */
> >> | #define ALIGNMENT   8   /* must be 2^N */
> >> | #define ALIGNMENT_SHIFT 3
> >> | #define ALIGNMENT_MASK  (ALIGNMENT - 1)
> >> |
> >> | So either the allocator alignment needs to be increased, or the
> >> | PyGC_Head alignment needs to be decreased.
> >>
> >> Is this a known issue?  As far as I can see, it has not been fixed on
> >> the 2.7 branch.
> >>
> >> (Store merging is a relatively new GCC feature.  Among other things,
> >> this means that on x86-64, for sufficiently aligned pointers, vector
> >> instructions are used to update multiple struct fields at once.  These
> >> vector instructions can trigger alignment traps, similar to what
> >> happens on some other architectures for scalars.)
> >> ___
> >> Python-Dev mailing list
> >> Python-Dev@python.org
> >> https://mail.python.org/mailman/listinfo/python-dev
> >> Unsubscribe:
> >> https://mail.python.org/mailman/options/python-dev/greg%40krypto.org
> >>
> >
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.7, long double vs allocator alignment, GCC 8 on x86-64

[Florian Weimer]

* Gregory P. Smith:

> The proper fix for this in the code would likely break ABI compatibility
> (ie: not possible in python 2.7 or any other stable release).
>
> Clang's UBSAN (undefined behavior sanitizer) has been flagging this one for
> a long time.
>
> In Python 3 a double is used instead of long double since 2012 as I did
> some digging at the time:
> https://github.com/python/cpython/commit/e348c8d154cf6342c79d627ebfe89dfe9de23817

A slightly more ABI-safe version of that change looks like this:

diff --git a/Include/objimpl.h b/Include/objimpl.h
index 55e83eced6..aa906144dc 100644
--- a/Include/objimpl.h
+++ b/Include/objimpl.h
@@ -248,6 +248,18 @@ PyAPI_FUNC(PyVarObject *) _PyObject_GC_Resize(PyVarObject 
*, Py_ssize_t);
 /* for source compatibility with 2.2 */
 #define _PyObject_GC_Del PyObject_GC_Del
 
+/* Former over-aligned definition of PyGC_Head, used to compute the
+   size of the padding for the new version below. */
+union _gc_head;
+union _gc_head_old {
+struct {
+union _gc_head *gc_next;
+union _gc_head *gc_prev;
+Py_ssize_t gc_refs;
+} gc;
+long double dummy;
+};
+
 /* GC information is stored BEFORE the object structure. */
 typedef union _gc_head {
 struct {
@@ -255,7 +267,8 @@ typedef union _gc_head {
 union _gc_head *gc_prev;
 Py_ssize_t gc_refs;
 } gc;
-long double dummy;  /* force worst-case alignment */
+double dummy;  /* force worst-case alignment */
+char dummy_padding[sizeof(union _gc_head_old)];
 } PyGC_Head;
 
 extern PyGC_Head *_PyGC_generation0;

This preserves the offset used by _Py_AS_GC in case it has been built
into existing binaries.  It may be more appropriate to do it this way
for Python 2.7.  I think it's also more conservative than the
allocator changes.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com