[Python-Dev] Re: [SPAM] Re: Switching to Discourse

[Rob Boehne via Python-Dev]

100% agree – dealing with 5 or more platforms for discussion groups is a 
nightmare, and I tend not to follow any of them as closely for that reason.

From: Skip Montanaro 
Date: Friday, July 15, 2022 at 9:26 AM
To: Petr Viktorin 
Cc: python-dev@python.org 
Subject: [SPAM] [Python-Dev] Re: Switching to Discourse
The 
discuss.python.org
 experiment has been going on for quite a while,
and while the platform is not without its issues, we consider it a
success. The Core Development category is busier than python-dev.
According to staff, 
discuss.python.org
 is much easier to moderate.. If
you're following python-dev but not 
discuss.python.org,
 you're missing out.

Personally, I think you are focused too narrowly and aren't seeing the forest 
for the trees. Email protocols were long ago standardized. As a result, people 
can use any of a large number of applications to read and organize their email. 
To my knowledge, there is no standardization amongst the various forum tools 
out there. I'm not suggesting discuss is necessarily better or worse than other 
(often not open source) forum tools, but each one implements its own walled 
garden. I'm referring more broadly than just Python, or even Python 
development, though even within the Python community it's now difficult to 
manage/monitor all the various discussion sources (email, discuss, GitHub, 
Stack Overflow, ...)

Get off my lawn! ;-)

Skip, kinda glad he's retired now...

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5R376DBMGYMJCJTXCZPNRUBNUPV5OSAJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python

[Rob Boehne]

On 2/22/21, 4:06 PM, "Antoine Pitrou"  wrote:

On Mon, 22 Feb 2021 19:50:43 +0000
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
>   1) Uninitialized memory being used (read)
>   2) Threading problems
>   3) Resources used (files, networking, daemons) but unavailable
>   4) memory mis-management (buffer overrun that doesn't cause a crash)
> 
> #3 is probably best fixed by testing for resources and skipping when 
unavailable

5) Poor quality POSIX support in the target platform.  The Python test
suite is actually quite demanding in this regard (except on Windows).

Regards

Antoine.

   

Antoine:

I find this a bit of a surprise, can you give an example of poor POSIX support 
leading to intermittent test failures? 

Thanks,

Rob Boehne 


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5XXXKPQCF2OTXLKYOJ5AJIW27M3OUHY3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [SPAM] Re: Move support of legacy platforms/architectures outside Python

[Rob Boehne]

On 2/22/21, 1:39 PM, "Steve Dower"  wrote:

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 use 
the list of stable buildbot platforms as the "supported" list. That 
makes it really clear what the path is to push support onto upstream 
(join up and bring a buildbot with you), and also means that we've got a 
physically restricted set of machines to prove work before doing a release.

Actively blocking anything at all seems unnecessary at the source/build 
level. That's for pre-built binaries and other conveniences.

Cheers,
Steve
___

+1 to this.

I use a few unsupported platforms, not as a hobby, but in my work.  I generally 
don't require ALL the things in python to work on these platforms, so even if I 
were to contribute a buildbot for an obscure (but definitely not "hobby") 
platform, it's implied that I would also need to fix test failures in modules I 
don't use.  I generally need to provide some reason for me to use my employer's 
time, so I can't really justify fixing test failures in code the company 
doesn't use.
I think these users are just asking that what currently works not be broken 
intentionally, and that follows the spirit of Autoconf, to test if something 
works and enable if it when it does.
There are also other ways to reduce the burden of maintaining a large number of 
platforms, such as abstracting away the OS services.


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
  1) Uninitialized memory being used (read)
  2) Threading problems
  3) Resources used (files, networking, daemons) but unavailable
  4) memory mis-management (buffer overrun that doesn't cause a crash)

#3 is probably best fixed by testing for resources and skipping when unavailable

The others are problems in the code, and can be fixed with clang sanitizers, but
Without some routine running of them, those sorts of problems will reappear.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6VCZYPSIB4QE3FL4L3D2WER3VU3LZGCO/
Code of Conduct: http://python.org/psf/codeofconduct/

Re: [Python-Dev] AIX to stable, what does that take?

[Rob Boehne]

On 10/5/18, 10:33 AM, "Python-Dev on behalf of Michael Haubenwallner" 
 wrote:

>
>... I build everything myself, using xlc
>(gcc introduces the need for a GNU RTE, e.g., glibc).

Using gcc does *not* require to use glibc or even GNU binutils at all.
Except for gcc's own runtime libraries, there's no need for a GNU RTE.
In fact, in Gentoo Prefix I do use gcc as the compiler, configured to
use AIX provided binutils (as, ld, nm, ...), with AIX libc as RTE.

I think the author was referring to the dependency on libgcc_s when using gcc.
It's typical for native UNIX package builders to use gcc only when necessary 
because the correct runtime is always installed (if the os running it is newer) 
and therefore won't clash when something else in the process space is using a 
different version of libgcc_s (I'm not sure what the ABI guarantees are with 
libgcc_s specifically, and neither are UNIX packagers - not necessarily anyway)
It also eliminates the need to ship a version of libgcc_s as a shared library.


___
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] [DLFILTER] Exporting Python functions on AIX

[Rob Boehne]

Why would a VIM build refer to the export file for python?

From: Python-Dev  on behalf 
of "WILSON, MICHAEL" 
Date: Friday, July 27, 2018 at 10:27 AM
To: "python-dev@python.org" 
Cc: "WILSON, MICHAEL" 
Subject: [DLFILTER] [Python-Dev] Exporting Python functions on AIX

All,

My excuse if this is not the appropriate list for a question essentially 
concerning the AIX port of Python.

The current port of Python for AIX includes composing an export file 
(/lib/python2.7/config/python.exp) in which there are a number of functions 
starting “Py_” or “_Py_”.

The Vim package for AIX is built referencing the python.exp file and 
unfortunately, when functions are removed from libpython, even those which are 
not called, the vim command detects missing symbols.

The most recent case (May 2017), functions _Py_hgidentity, _Py_hgversion and 
_Py_svnversion were replaced/removed, see “bpo-27593: Get SCM build info from 
git instead of hg (#1327)”.

Is it correct to assume that the “_Py_” functions are internal (Python name 
space) that should/must not be called by or made visible to application code  ?

Could you indicate a URL to the authoritative API documentation ?

Thanks for your replies.

Mike Wilson

___
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] bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)

[Rob Boehne]

On 5/13/18, 12:44 PM, "Python-Dev on behalf of Christian Heimes" 
 wrote:

On 2018-05-13 06:57, Serhiy Storchaka wrote:
> 
https://github.com/python/cpython/commit/1e2ec8a996daec65d8d5a3d43b66a9909c6d0653
> commit: 1e2ec8a996daec65d8d5a3d43b66a9909c6d0653
> branch: master
> author: Rolf Eike Beer 
> committer: Serhiy Storchaka 
> date: 2018-05-13T13:57:31+03:00
> summary:
> 
> bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)
> 
> The hash implementation casts the input pointer to uint64_t* and directly 
reads
> from this, which may cause unaligned accesses. Use memcpy() instead so 
this code
> will not crash with SIGBUS on sparc.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=636400
> 
> files:
> A Misc/NEWS.d/next/Core and 
Builtins/2018-04-25-20-44-42.bpo-28055.f49kfC.rst
> M Python/pyhash.c

Hi Serhiy,

I was against the approach a good reason. The PR adds additional CPU
instructions and changes memory access pattern in a  critical path of
CPython. There is no reason to add additional overhead for the majority
of users or X86 and X86_64 architectures. The memcpy() call should only
be used on architectures that do not support unaligned memory access.
See comment https://bugs.python.org/issue28055#msg276257

X86 won't *directly* write misaligned data either, it will intrinsically copy 
it out to a properly aligned location.  In C this is also "undefined behavior", 
so technically the C implementation can do whatever it wants - like raise an 
exception - which is will on SPARC.  While X86 users may not notice any 
problems, depending on undefined behavior working in any particular way has 
many drawbacks.  Often C compilers will optimize code in ways that assume there 
is no undefined behavior in ways that breaks code that does.

At least for latest GCC, the change seems to be fine. GCC emits the same
assembly code for X86_64 before and after your change. Did you check the
output on other CPU architectures as well as clang and MSVC, too?

Christian
___
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/robb%40datalogics.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] Hi, I am amar :)

[Rob Boehne]

Amar,

Loved that joke!

I had a quick look at these PR’s and commented.  I do not see any worthwhile 
improvement to Python by merging these, and there are significant problems with 
the details in both patches.   Hopefully your intent was to learn about the 
process of contributing to Python, and and the language itself.  In that vein, 
I treated them seriously and hopefully gave you useful feedback.

Thanks,

Rob Boehne

From: Python-Dev <python-dev-bounces+robb=datalogics@python.org> on behalf 
of amar via Python-Dev <python-dev@python.org>
Reply-To: amar <rada...@protonmail.com>
Date: Tuesday, April 3, 2018 at 10:42 AM
To: "python-dev@python.org" <python-dev@python.org>
Subject: [Python-Dev] Hi, I am amar :)

Hi, all. Quick joke, Do you know why all functional programmers are anarchists? 
Because they want to get rid of the state! :D

I know there are a lot more important issues than this, but i feel this is 
important too. I wish some people could take a look at Python/Cpython pull 
request #6343[1] and the reopened PR #6362[2]. Little background here, I am a 
science student working on GIS(Geospatial Information Systems) Web Processing 
Service as a hobby project.

I am a human too, i like jokes. But not at the expense of truth. I hope i can 
make more meaningful contributions in the future!

[1] https://github.com/python/cpython/pull/6343
[2] https://github.com/python/cpython/pull/6362#issuecomment-378174084

___
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] HP-UX pr not feeling the love

[Rob Boehne]

Thanks!  I’m personally comfortable with dropping support for systems that 
people can’t buy support for, like IRIX, ULTRIX, SCO etc.  It’s hard to 
envision those being anything other than hobbyist platforms.  Here at 
Datalogics, we are selling and supporting software on HP-UX, for both pa-risc 
and Itanium, and now that SCons is beginning to support Python 3.x, I am 
attempting to use some of my spare time to get this platform (and others we 
support) to build, and then to run, on the development branch for Python 3.   
So rather than taking a large block of my time to port and fix any problems, 
I’m going to submit pr’s in a trickle, as time permits.  I’m picking HP-UX 
because it’s probably the most obscure thing we use, and likely would take the 
most effort.


From: Lukasz Langa <luk...@langa.pl>
Date: Wednesday, December 6, 2017 at 11:45 AM
To: Rob Boehne <r...@datalogics.com>
Cc: "python-dev@python.org" <python-dev@python.org>
Subject: Re: [Python-Dev] HP-UX pr not feeling the love

Hi Rob,
thanks for your patch. CPython core developers, as volunteers, have limited 
resources available to maintain Python. Those resources are not only time, they 
are also mental resources necessary to make a change in Python as well as 
actual physical resources. Supporting a platform requires all three:

1. You need time to make a platform work initially, and then continuous effort 
to keep it working, fixing regressions, including this platform in new 
features, etc.
2. You need mental resources to manage additional complexity that comes from 
#ifdef sprinkled through the code, cryptic configure/Makefile machinery, etc.
3. You need access to machines running the given operating system to be able to 
test if your changes are compatible.

This is why we are keeping the list of supported platforms relatively short. In 
fact, in time we're cutting support for less popular platforms that we couldn't 
keep running. Details in https://www.python.org/dev/peps/pep-0011/. Look, just 
in 3.7 we're dropping IRIX and systems without threads.

As you're saying, while your current PR is relatively innocent, more are needed 
to make it work. If those require more drastic changes in our codebase, we 
won't be able to accept them due to reasons stated above.

I understand where you're coming from. If you're serious about this, we would 
need to see the full extent of changes required to make Python 3.7 work on HP 
UX, preferably minimal. We would also need a buildbot added to our fleet (see 
http://buildbot.python.org/) that would ensure the build stays green. Finally, 
we would need you to think whether you could provide the patches that keep the 
build green for a significant period of time (counted in years).

- Ł




On Dec 6, 2017, at 7:22 AM, Rob Boehne 
<r...@datalogics.com<mailto:r...@datalogics.com>> wrote:

Hello,

Back in June I was fired up to get my diverse set of platforms all running 
Python 3, but quickly ran into issues and submitted a PR.

https://github.com/python/cpython/pull/2519

It seems as though this HP-UX specific change isn’t getting much consideration, 
which probably isn’t a big deal.  What may be more important is that I’ve 
stopped trying to contribute, and if I really need Python 3 on HP-UX, AIX, 
Sparc Solaris or other operating systems, I’ll have to hack it together myself 
and maintain  my own fork, while presumably others do the same.  At the same 
time I’m working hard to convince management that we shouldn’t create technical 
debt by maintaining patches to all the tools we use, and that we should get 
these changes accepted into the upstream repos.

Could someone have a look at this PR and possibly merge?

Thanks,

Rob Boehne

___
Python-Dev mailing list
Python-Dev@python.org<mailto:Python-Dev@python.org>
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/lukasz%40langa.pl

___
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] HP-UX pr not feeling the love

[Rob Boehne]

Hello,

Back in June I was fired up to get my diverse set of platforms all running 
Python 3, but quickly ran into issues and submitted a PR.

https://github.com/python/cpython/pull/2519

It seems as though this HP-UX specific change isn’t getting much consideration, 
which probably isn’t a big deal.  What may be more important is that I’ve 
stopped trying to contribute, and if I really need Python 3 on HP-UX, AIX, 
Sparc Solaris or other operating systems, I’ll have to hack it together myself 
and maintain  my own fork, while presumably others do the same.  At the same 
time I’m working hard to convince management that we shouldn’t create technical 
debt by maintaining patches to all the tools we use, and that we should get 
these changes accepted into the upstream repos.

Could someone have a look at this PR and possibly merge?

Thanks,

Rob Boehne

___
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] (no subject)

[Rob Boehne]

Victor,

Thanks - I will comment on the issue WRT backporting the fix.
If you have particular issues you’d like me to look into, just point me in
the right direction.

Thanks,

Rob



On 6/30/17, 2:29 AM, "Victor Stinner" <victor.stin...@gmail.com> wrote:

>Hi Robb,
>
>2017-06-29 23:34 GMT+02:00 Rob Boehne <r...@datalogics.com>:
>> I¹m new to the list, and contributing to Python specifically, and I¹m
>> interested in getting master and 3.6 branches building and working
>> ³better² on UNIX.
>> I¹ve been looking at a problem building 3.6 on HP-UX and see a PR was
>> merged into master, https://github.com/python/cpython/pull/1351 and I¹d
>> like to see it applied to 3.6.  I¹m happy to create a PR with a
>> cherry-picked commit, and/or test.
>
>Sure, this change can be backported to 3.6, maybe also to 3.5. But
>hum, I may suggest to first focus on the master branch and fix most
>HP-UX issues, before spending time on backport. I would prefer to see
>most tests of the important modules pass on HP-UX (ex: test_os).
>
>For a backport, you can directly comment http://bugs.python.org/issue30183
>
>Victor

___
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] Buildbot report (almost July)

[Rob Boehne]

Hello,

I¹m new to the list, and contributing to Python specifically, and I¹m
interested in getting master and 3.6 branches building and working
³better² on UNIX.
I¹ve been looking at a problem building 3.6 on HP-UX and see a PR was
merged into master, https://github.com/python/cpython/pull/1351 and I¹d
like to see it applied to 3.6.  I¹m happy to create a PR with a
cherry-picked commit, and/or test.


Rob Boehne 
Senior Software Architect | Datalogics, Inc.
+1.312.853.8351  | r...@datalogics.com
<mailto:j...@datalogics.com>
datalogics.com <https://www.datalogics.com/> | blogs.datalogics.com
<https://blogs.datalogics.com/>Connect with us: Facebook
<https://www.facebook.com/DatalogicsInc> | Twitter
<https://twitter.com/DatalogicsInc> | LinkedIn
<https://www.linkedin.com/company/datalogics> | YouTube
<https://www.youtube.com/user/Datalogics>

PROUDLY CELEBRATING 50 YEARS!
<https://www.datalogics.com/datalogics-celebrates-50-years-of-embracing-cha
nge-and-providing-high-quality-software>





On 6/29/17, 10:09 AM, "Python-Dev on behalf of Victor Stinner"
<python-dev-bounces+robb=datalogics@python.org on behalf of
victor.stin...@gmail.com> wrote:

>Hi,
>
>Our buildbots are now even more stable than in my previous buildbot
>report.
>
>Many random failures have been fixed, even if there are still many
>rare random failures (most of them are related to multiprocessing).
>
>Search for issues created by "haypo" (me!) with the Component "Tests"
>to see all remaining issues. I'm trying to open an issue for *each*
>buildbot failure! So yeah, we have a long list of 44 open issues!
>
>Correct me if I'm wrong, but, for the first time, *all reference
>leaks* have been fixed on *all branches* (2.7, 3.5, 3.6 and master),
>on *Linux and Windows*! Before, we mostly focused on the master branch
>(called "default" in Mercurial) on Linux.
>
>I also started to fix a few "memory block" leaks, most (or all?) of
>them should also be fixed (on all branches, on Linux and Windows).
>
>A new policy has been decided (on python-committers): if a commit
>breaks too many buildbots and cannot fixed easily nor quickly, the
>commit will be reverted, just to keep our buildbots "green". It
>doesn't mean that the commit will be rejected forever. It's a
>practical solution to give more time to write a proper fix, take time
>to review it, and not have to be stressed to fix buildbots "ASAP".
>Moreover, keeping green buildbots all the time allows to catch
>regressions more quickly, which ease debug in many ways.
>
>You have be warned! Now I will not hesitate to revert your change if
>you break my little buildbots ;-)
>
>I mostly care of Linux, Windows, macOS and FreeBSD (10 and CURRENT).
>Breaking other platforms is less important, since other platforms
>already have issues, but not enough developers interested to fix them.
>Obviously, I'm interested in keeping more buildbots green, if someone
>shows up and help me to fix remaining issues!
>
>Victor
>___
>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/robb%40datalogics.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