Hello!
On 2/22/21 12:30 PM, Victor Stinner wrote:
>> The thing is you made assumptions about how downstream distributions use
>> Python without doing some research first ("16-bit m68k-linux").
>
> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
> not respected on m68k. For
Michał Górny wrote:
> On Mon, 2021-02-22 at 19:27 +, Jessica Clarke wrote:
> > Example: 16-bit m68k
> > no, it's a 32bit platform with extra alignment requirements.
> > Actually, fewer. Most architectures have alignof(x) == sizeof(x) for
> > all the primitive types, but m68k is more relaxed
Barry Scott wrote:
> > On 22 Feb 2021, at 12:40, Michał Górny mgo...@gentoo.org wrote:
> > I'm talking about 16-bit memory alignment which
> > causes SIGBUS if it's
> > not respected on m68k.
> > I don't understand why you consider this to be a problem. After all,
> > x86 has stronger (32-bit)
On Sun, Feb 21, 2021 at 12:28 PM Gregory P. Smith wrote:
>
> On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
> wrote:
>
>> On 21/02/2021 13.47, glaub...@debian.org wrote:
>> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure
On Mon, 2021-02-22 at 19:27 +, Jessica Clarke wrote:
> > > Example: 16-bit m68k
> > no, it's a 32bit platform with extra alignment requirements.
>
> Actually, fewer. Most architectures have alignof(x) == sizeof(x) for
> all the primitive types, but m68k is more relaxed and caps alignof(x)
>
On Mon, 2021-02-22 at 19:54 +, Barry Scott wrote:
>
> > On 22 Feb 2021, at 12:40, Michał Górny wrote:
> >
> > > I'm talking about 16-bit memory alignment which causes SIGBUS if it's
> > > not respected on m68k.
> > >
> >
> > I don't understand why you consider this to be a problem. After
On Mon, 22 Feb 2021 19:50:43 +
Rob Boehne wrote:
>
> The other thing that crept into this thread was the mention of test that
> intermittently fail.
> That's a huge problem because it suggests that applications will sometimes
> fail.
> I have usually seen these sort of issues because of
>
> > Example: 16-bit m68k
> no, it's a 32bit platform with extra alignment requirements.
Actually, fewer. Most architectures have alignof(x) == sizeof(x) for all the
primitive types, but m68k is more relaxed and caps alignof(x) at 2. This means
that assert((p & sizeof(long)) == 0) is too strict,
> On 22 Feb 2021, at 12:40, Michał Górny wrote:
>
>> I'm talking about 16-bit memory alignment which causes SIGBUS if it's
>> not respected on m68k.
>>
>
> I don't understand why you consider this to be a problem. After all,
> x86 has stronger (32-bit) alignment requirements, so m68k is
On 2/22/2021 5:18 PM, Matthias Klose wrote:
On 2/21/21 1:13 PM, Victor Stinner wrote:
Document what is supported, be inclusive about anything else. Don't make a
distinction yet between legacy and upcoming new architectures.
I agree with this, and I don't see any reason why we shouldn't just
On 2/22/2021 6:58 AM, Victor Stinner wrote:
On Mon, Feb 22, 2021 at 12:51 PM Ivan Pozdeev via Python-Dev
wrote:
IIRC I suggested earlier that buildsbots should be integrated into the PR
workflow in order to make it the contributor's rather than a core
dev's burden to fix any breakages that
On 2/21/21 1:13 PM, Victor Stinner wrote:
> In short, I propose to move maintenance of the legacy platforms/archs
> outside Python: people are free to continue support them as patches.
> Concrete example: Christian Heimes proposed to drop support for 31-bit
> s390 Linux:
>
On 2/22/2021 6:20 AM, Victor Stinner wrote:
To have an idea of the existing maintenance burden, look at emails sent to:
https://mail.python.org/archives/list/buildbot-sta...@python.org/
Every single email is basically a problem. There are around 110 emails
over the last 30 years:
30 days,
On 2/22/21 12:30 PM, Victor Stinner wrote:
> On Mon, Feb 22, 2021 at 8:19 AM wrote:
>> There are zero technical reasons for what you are planning here.
>
> Multiple core developers explained how it's a maintenance burden. It
> has been explained in multiple different ways.
Well, that doesn't
On 2/21/21 7:12 PM, Christian Heimes wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
>> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure guard. All platforms that Rust can
>> build for, are always enabled by default. No one
On 2/21/21 9:24 PM, Gregory P. Smith wrote:
> On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
> wrote:
>
>> On 21/02/2021 13.47, glaub...@debian.org wrote:
>>> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
>> platforms. There is no separate configure guard. All platforms
On Mon, 2021-02-22 at 12:30 +0100, Victor Stinner wrote:
> On Mon, Feb 22, 2021 at 8:19 AM wrote:
> > The thing is you made assumptions about how downstream distributions use
> > Python without doing some research first ("16-bit m68k-linux").
>
> I'm talking about 16-bit memory alignment which
On Mon, Feb 22, 2021 at 12:51 PM Ivan Pozdeev via Python-Dev
wrote:
> IIRC I suggested earlier that buildsbots should be integrated into the PR
> workflow in order to make it the contributor's rather than a core
> dev's burden to fix any breakages that result from their changes.
Some buildbot
IIRC I suggested earlier that buildsbots should be integrated into the PR workflow in order to make it the contributor's rather than a core
dev's burden to fix any breakages that result from their changes.
On 22.02.2021 14:20, Victor Stinner wrote:
On Sun, Feb 21, 2021 at 8:57 PM Michał Górny
On Mon, Feb 22, 2021 at 8:19 AM wrote:
> There are zero technical reasons for what you are planning here.
Multiple core developers explained how it's a maintenance burden. It
has been explained in multiple different ways.
> You are inflating a few lines of autoconf into a "platform support",
On Sun, Feb 21, 2021 at 8:57 PM Michał Górny wrote:
> > The checker serves two purposes:
> >
> > 1) It gives users an opportunity to provide full PEP 11 support
> > (buildbot, engineering time) for a platform.
>
> Does that mean that if someone offers to run the build bot for a minor
> platform
Hello,
On Mon, 22 Feb 2021 09:20:46 +0100
Michał Górny wrote:
> On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
> > The main thing from a project maintenance perspective is for
> > platforms to
> > not become a burden to other code maintainers. PRs need to be
> > reviewed.
> > Every
On 22.02.2021 11:20, Michał Górny wrote:
On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
The main thing from a project maintenance perspective is for platforms
to
not become a burden to other code maintainers. PRs need to be
reviewed.
Every #if/#endif in code is a cognitive burden.
On Sun, 2021-02-21 at 13:04 -0800, Gregory P. Smith wrote:
> The main thing from a project maintenance perspective is for platforms
> to
> not become a burden to other code maintainers. PRs need to be
> reviewed.
> Every #if/#endif in code is a cognitive burden. So being a minor
> platform
> can
> The main thing from a project maintenance perspective is for platforms to
not become a burden to other code maintainers. PRs need to be reviewed.
Every #if/#endif in code is a cognitive burden. So being a minor platform
can come with unexpected breakages that need fixing due to other changes
There are zero technical reasons for what you are planning here.
You are inflating a few lines of autoconf into a "platform support", so you
have a reason to justify adding multiple lines of extra autoconf codes to make
life for downstream distributions harder.
I could understand the
On Sun, Feb 21, 2021 at 4:16 AM Victor Stinner wrote:
>
> There is also a 4th category: platforms/archs which are really not
> supported, like they legacy ones for which we removed the code :-)
> Examples: BeOS, MacOS 9, platforms with no thread support, etc.
>
FWIW, BeOS may be resurfacing
On Sun, Feb 21, 2021 at 1:07 PM Gregory P. Smith wrote:
>
> > I'm +1 in general for your proposal. I also like the idea to adopt
>> > Rust's platform support definition.
>>
> +1, but see below.
>
> The main thing from a project maintenance perspective is for platforms to
> not become a burden
On Sun, Feb 21, 2021 at 12:03 PM Michał Górny wrote:
> On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote:
> > On 21/02/2021 13.13, Victor Stinner wrote:
> > > Hi,
> > >
> > > I propose to actively remove support for *legacy* platforms and
> > > architectures which are not supported by
On Sun, Feb 21, 2021 at 10:15 AM Christian Heimes
wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
> platforms. There is no separate configure guard. All platforms that Rust
> can build for, are always enabled by
On Sun, 2021-02-21 at 13:35 +0100, Christian Heimes wrote:
> On 21/02/2021 13.13, Victor Stinner wrote:
> > Hi,
> >
> > I propose to actively remove support for *legacy* platforms and
> > architectures which are not supported by Python according to PEP 11
> > rules: hardware no longer sold and
On Sun, 2021-02-21 at 19:12 +0100, Christian Heimes wrote:
> On 21/02/2021 13.47, glaub...@debian.org wrote:
> > Rust doesn't keep any user from building Rust for Tier 2 or Tier 3
> > platforms. There is no separate configure guard. All platforms that Rust
> > can build for, are always enabled
On 21/02/2021 13.47, glaub...@debian.org wrote:
> Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms.
> There is no separate configure guard. All platforms that Rust can build for,
> are always enabled by default. No one in Rust keeps anyone from
> cross-compiling code
Rust doesn't keep any user from building Rust for Tier 2 or Tier 3 platforms.
There is no separate configure guard. All platforms that Rust can build for,
are always enabled by default. No one in Rust keeps anyone from cross-compiling
code for sparc64 or powerpcspe, for example.
So if you want
(Since my first reply here somehow got lost, I'm posting this again).
Rust doesn't prevent anyone from building Tier 2 or Tier 3 targets. There is no
limitation for "legacy" or "deprecated" targets. Any target can be built and
any target can be selected by the Rust compiler for
On 21/02/2021 13.13, Victor Stinner wrote:
> Hi,
>
> I propose to actively remove support for *legacy* platforms and
> architectures which are not supported by Python according to PEP 11
> rules: hardware no longer sold and end-of-life operating systems. The
> removal should be discussed on a
36 matches
Mail list logo
