On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:

I fully support Paul's initiative to fix the copyright issues for the next release.

...

On 18. Aug 2019, at 18:54, Paul A Bristow via Boost < boost@lists.boost.org> wrote:

1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use).

I think this program should be rewritten in Python which would simplify maintaining and using it (no compilation needed, simpler code, Python's string processing is fast enough).

- To give the inspection report more visibility, there should be an entry in the menu of www.boost.org. Under "Development" we currently have "Master Summary" and "Master Issues". There should also be "Master Inspection Report". And vice versa for "Development *".

It would be fantastic to see a PR for the existing library check Python program < https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py>. as that would achieve the goal of providing continuous visibility on a per branch and per library basis as you suggest. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On Tue, Aug 20, 2019 at 2:35 PM Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

On 19.08.19 17:45, Rene Rivera via Boost wrote:

...

On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:

...

[snip]

It would be fantastic to see a PR for the existing library check Python program <

...

. as that would achieve the goal of providing continuous visibility on a

https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py per

...

branch and per library basis as you suggest.

Do you want to run inspect using this python script or do you want a full implementation of inspect in python?

We can start with the license checks. And eventually add more inspect functionality if needed. But the goal is not to run the inspect program itself preferring to "port" the functionality over. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

On 20. Aug 2019, at 21:40, Rene Rivera via Boost wrote:

On Tue, Aug 20, 2019 at 2:35 PM Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:

...

On 19.08.19 17:45, Rene Rivera via Boost wrote:

...

On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:

...

[snip]

It would be fantastic to see a PR for the existing library check Python program <

...

. as that would achieve the goal of providing continuous visibility on a

https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py per

...

branch and per library basis as you suggest.

Do you want to run inspect using this python script or do you want a full implementation of inspect in python?

We can start with the license checks. And eventually add more inspect functionality if needed. But the goal is not to run the inspect program itself preferring to "port" the functionality over.

What is the minimum Python version that has to be supported? Python 2.7?

On 21. Aug 2019, at 10:25, Mike via Boost wrote:

...

What is the minimum Python version that has to be supported? Python 2.7?

Python 2 is almost EOL. As this is a dev-tool primarily targeted at library developers, there should be no reason to maintain Python 2 support. Python 3 is even older than c++11 which is IIRC required by b2.

I agree with you, but boost_check_library.py has to work on all the machines which run the Boost Test matrix, therefore the script has to be compatible with the Python versions on these machines. If all of them have Python3 already, great. I am mainly asking because I would like to replace optparse with argparse, which first appeared in Python2.7.

On Wed, 21 Aug 2019 at 17:22, Paul A Bristow via Boost < boost@lists.boost.org> wrote:

PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉

The python installation process is at least a lot easier than to install Boost, and it [the installer] does what we dummies softies are used to: download, run installer, click yes until it stops nagging and then wait. We softies handle that relatively well, as that's the process with all [the majority at least] installs. We are blissfully unaware of dependencies or crt's, though. Ah wait, that [to have awareness] is not necessary by design. Ah well. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

On 22. Aug 2019, at 09:54, Paul A Bristow via Boost wrote:

I was implying that the *son-of-inspect* Python program has got to work.

The current inspect has worked for nearly two decades and still does.

And John Maddock has just made the CI process run it routinely, so people can see how bad their library is much more easily.

With Multiprecision and Math libraries, it is just the tedious process of checking all the inspect reports and deciding what to do about them.

Lots of errant, tax, max/min macro issues, missing licences (many live generated files that we could manage without licences, though a tip to people writing C++ or other code to generate C++ code, it is easy at the writing stage to code to write the license and copyright at the head of the generated file (but a hassle and possibly troublesome to do it later, especially for some other poor sucker 😉)

The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable. I am considering to revert this change and propose instead to remove the min/max macro check from the inspection list. Or is there a way to blacklist it locally for my library?

Lots of files that don't need license and copyright can have boost-no-inspect written into them, or added, or whole folders made no-inspect. It just needs some work.

1) A constructive criticism of boost-no-inspect files I worry about using these boost-no-inspect files to prevent scans for whole folders. I think the files themselves are distracting, but moreover, I think it shouldn't be necessary to ignore whole folders. Instead of fixing the copyright notices in my files in Boost.Histogram, I could just have put boost-no-inspect files in the directories. This wouldn't solve the issue that the inspect tool tries to address. boost/status has a boost-no-inspect file, for example, but I think it should not. Like you pointed out, boost_check_library.py should have a license notice, and likewise the xml and xsd files in that folder. I am not a lawyer, but in my understanding - and I can only understand simple consistent rules - everything in Boost which is not automatically generated by another program is by definition "source code", which then needs a license notice. I think the boost-no-inspect files should not be needed, because the directory structure of Boost is very uniform in all projects and this is enforced. It should be predictable for the inspect tool which directories need to be scanned. I think the inspect tool has a good rule set for this, but it should definitely also ignore also what's in .gitignore, see next item. 2) Proposal: parse .gitignore and meta/inspect-ignore The inspect tool gives a lot of false positives when I run it locally on my computer. These would disappear if it would ignore what is in .gitignore. Once this feature is added, we could generally switch to a solution where the inspect tool scans the meta folder and reads a inspect-ignore file. This would have the same format as .gitignore, so the same code in the inspect tool can be used to read both. This would be a better solution than using boost-no-inspect files and "boost-no-inspect" comments. I just posted these suggestions/requests as issues to the boostorg/inspect repo. Summary: I understand that the C++ inspect tool has worked for a long time and it obviously works very well, but software needs to adapt to new demands. We face the decision to either add new features to inspect or to ported the functionality piece by piece over to boost_check_library.py, add then add new features to that version. I think Python is better suited for this sort of task, so you know my view. Best regards, Hans

-----Original Message----- From: Boost On Behalf Of Mike via Boost Sent: 22 August 2019 10:17 To: boost@lists.boost.org Cc: Mike Subject: Re: [boost] Compliance with Boost copyright and license guidelines

...

Gesendet: Donnerstag, 22. August 2019 um 11:06 Uhr Von: "Hans Dembinski via Boost" The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable. I am considering to revert this change and propose instead to remove the min/max macro check from the inspection list. Or is there a way to blacklist it locally for my library?

This is not a compiler problem. The windows.h file (https://en.wikipedia.org/wiki/Windows.h) is defining those macros unless special workarounds are applied like defining NOMINMAX before including the file.

But it is a problem for all those who *use* Boost code *and* Windows - and that is a LOT of people, most perhaps. So there is a longstanding Boost policy that we avoid annoying Windows users. It's a minor nuisance and trivial ugliness in Boost code, adding brackets to (std::max) and (std::numeric_limits<>::max)() etc. Paul PS I suspect that it seemed very cool of Microsoft to define these min and max macros, probably about 30 ago, perhaps even by Bill himself? Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

degski wrote:

...

So there is a longstanding Boost policy that we avoid annoying Windows users.

So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying?

avoid - annoying - Windows users not avoid - annoying Windows users That is, we try to avoid making Windows users annoyed.

On 23/08/2019 00:48, degski wrote:

...

avoid - annoying - Windows users

Better: ... avoid to annoy Windows users. English does have its pitfalls. Thanks for pointing that out.

That's not really better, since it's grammatically incorrect. You could say "avoid being an annoyance to Windows users". Or use a less ambiguous word "avoid upsetting Windows users". (Which technically could still be read the wrong way, but I don't think anyone would read it that way.)

-----Original Message----- From: Boost On Behalf Of degski via Boost Sent: 22 August 2019 13:29 To: boost Cc: degski Subject: Re: [boost] Compliance with Boost copyright and license guidelines

On Thu, 22 Aug 2019 at 12:52, Paul A Bristow via Boost < boost@lists.boost.org> wrote:

...

So there is a longstanding Boost policy that we avoid annoying Windows users.

So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying? Brexit seems to have gone to your head, better get it checked out.

I'm getting really annoyingly annoyed by this thread 😉 But everyone is annoyed and annoying - by max/min macros - and by Brexit. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

On Thu, 22 Aug 2019 at 16:51, Glen Fernandes via Boost < boost@lists.boost.org> wrote:

Granted, that was November 2018, and it is now August 2019. Many things have happened since then.

Don't count on it [having changed]. For example, as one user has pointed out on this thread, perhaps

Brexit has happened.

The Brits keep on postponing it [cos they can't agree on anything], so no, it did not happen, it probably won't, that's my guess. But heck, maybe Trump could buy the UK of the EU, as he seems to be in the mood for buying an island. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

On 22. Aug 2019, at 15:51, Glen Fernandes wrote:

Hans wrote:

...

The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable.

In September 2018, I introduced a use of std::numeric_limits<T>::max() in Boost.CircularBuffer. In November 2018, I received the first of two complaints (from Windows users) so I addressed it.

I'm not convinced that it is not relevant anymore.

Granted, that was November 2018, and it is now August 2019. Many things have happened since then.

For example, as one user has pointed out on this thread, perhaps Brexit has happened.

It is entirely possible that Brexit has caused this to no longer be a problem for Windows developers.

Ok, I stand corrected. This is still an issue and I didn't really understood where the issue is coming from. Thanks to Glen, Paul, and Mike Dev for explaining.

Copying my response here as I accidentally sent my original response only to Hans directly:

I agree with you, but boost_check_library.py has to work on all the machines which run the Boost Test matrix,

Does it? Isn't that just a waste of time? IIRC, the script doesn't run unit tests or anything. It just checks for the presence and content of various files and directories. I don't know, why this has to run on every test machine.

I am mainly asking because I would like to replace optparse with argparse, which first appeared in Python2.7.

My opinion: Go ahead. If this causes trouble on a test machine, that is imho a reason to either fix the test machine or to not run the script on that machine (just as unit-tests for c++14 libs are not/should not be run on machines without a c++14 compiler). It should not hold back development. But I guess Rene or maybe Michael are the ones who could give a more authoritative answer on that.

Von: "Paul A Bristow via Boost"

[..]

It's even easier than I thought - I idly open a dosbox and typed Python and lo this came up.

What's a dosbox? I guess you didn't mean https://www.dosbox.com/ ? ;) Sorry, couldn't resist - I.e. I hope, no one is developing boost on a Windows 98/ME system anymore. But I don't have any preference on how those checks are done. Python tends to be suited way better for text processing than c++, but if the code is already there, then I agree - hwy reinvent the wheel. Anyway, if the problems don't get fixed, it doesn't matter what tool is used to detect them. Best Mike

On Wed, 21 Aug 2019 at 11:14, Hans Dembinski via Boost < boost@lists.boost.org> wrote:

What is the minimum Python version that has to be supported? Python 2.7?

Python 2 is on its way out, Fedora 31, f.e. will NOT have Python-2.7 by default anymore. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey

Won't requiring Python put off some library authors from applying a run the inspect program to their own code?

(Having the Python program will be valuable for providing an externally visible and usable list). I rather see it the other way round: Using and maintaining the Python

Waiting for the CI system to catch up with that is intolerably slow. +1 The static checker which can be run without any setup locally would

Am 21.08.19 um 09:32 schrieb Paul A Bristow via Boost: program will be much easier and faster: Just run it, done. Most devs are likely using Linux anway where Python is preinstalled. Better than having to compile something first, probably need to change it due to false positives and compile again. Then compile own code etc. therefore be a huge bonus.

All notable Linux distribution and OSX comes with pre-installed Python. Only Windows does not ship with Python preinstalled.

That got a lot better in the most recent Windows 10 update: https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-upda... tldr; python now has a stub executable which takes you to the store install page. Same as the "bash" stub executable, and soon also "wordpad" and "paint". Niall