[Python-Dev] OS-X builds for 3.7.0

2018-01-30 Thread 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:

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

2018-01-30 Thread 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?

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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 =

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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,

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

2018-01-30 Thread 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 > > >

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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,

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

2018-01-30 Thread 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: > >

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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

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

2018-01-30 Thread 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 >

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

2018-01-30 Thread 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