Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run reflow #481

Closed
wants to merge 13 commits into from
Closed

Conversation

TApplencourt
Copy link
Contributor

@TApplencourt TApplencourt commented Oct 25, 2023

Update our reflow.py copy and run it.

Link: https://github.com/KhronosGroup/Vulkan-Docs/blob/main/scripts/reflow.py and thanks @oddhack :)

This does what we wanted:

  • Force a maximum line width (default 76 char)
  • Split on period
  • Delete 2+ contiguous spaces

This is a small PR, so it should be easy to review...

@TApplencourt TApplencourt added the editorial Some purely editorial problem label Oct 25, 2023
Copy link
Contributor

@gmlueck gmlueck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, this is great! There are a couple problems I point out below, but I think they can be easily fixed.

To validate that nothing got inadvertently changed, I built the PDF both before and after this change and compared the PDF versions. There were no unexpected changes. (There were some expected changes on the title page related to the git version and the build date.)

To people who were not at lunch today, this addresses #472. Thomas was noting how this could be easily done via a script, so I guess he volunteered!

adoc/chapters/acknowledgements.adoc Outdated Show resolved Hide resolved
adoc/chapters/device_compiler.adoc Outdated Show resolved Hide resolved
adoc/chapters/opencl_backend.adoc Outdated Show resolved Hide resolved
@oddhack
Copy link
Contributor

oddhack commented Oct 26, 2023

A few other notes about this script:

  • Requires pretty strict adherence to style guidelines, because it's not running the asciidoctor processing pipeline and does not know about every possible asciidoc construct. When I initially did the SYCL format conversion I followed the Vulkan style guidelines in general, so it's not surprising this basically works for you. The Vulkan style guide contains a lot of stuff that is irrelevant to SYCL but much of the markup / writing / miscellaneous sections may be worth extracting.
  • Will not reflow long lines in captions and titles (not supported by asciidoc), nor inside tables (possible, but $TOOCOMPLEX for the minimal upside).

It is pretty robust within the scope of what it's intended for. We use it frequently on Vulkan.

@oddhack
Copy link
Contributor

oddhack commented Oct 26, 2023

@gmlueck it is an orthogonal issue, but you may want to review the Khronos spec copyright and make sure that's up to date with the latest version Neil has (V10, I think?).

gmlueck added a commit to gmlueck/SYCL-Docs that referenced this pull request Oct 26, 2023
Some Asciidoc references to the glossary terms were using the name of
the glossary term instead of the link name.  For glossary terms that
have multiple words, this results in a reference that has a space in
the name.  This space is causing problems in KhronosGroup#481.

All these glossary terms have an anchor that is the same as the
glossary term, but with a hyphen instead of the space that separates
the words.  Change the references to use this anchor name instead of
using the glossary term.
@TApplencourt
Copy link
Contributor Author

Will rebase with #482 after it will be merged.

Copy link
Member

@keryell keryell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks globally like a good idea.
Probably you can rephrase "Keep a maximum line width," in the description to fit the mathematical property you want to express.

@keryell
Copy link
Member

keryell commented Nov 2, 2023

@oddhack do you know why 76 characters in "Force a maximum line width (default 76 char)"?
Why not 79? I understand that 80 is a little bit brittle for some hardware differences about how is handled the real CR.

@oddhack
Copy link
Contributor

oddhack commented Nov 2, 2023

@oddhack do you know why 76 characters in "Force a maximum line width (default 76 char)"? Why not 79?

Historical dating back to OpenGL extension days - use whatever is convenient to you. If you use 999999 you get one sentence/line :-) Just make sure you like the value you start with so you don't generate lots of git churn by changing it later.

@keryell
Copy link
Member

keryell commented Nov 2, 2023

I mean, if we agree on 80 columns inherited from punch cards which percolated for decades into hardware terminals quite before OpenGL and computer graphics, why 76? You loose 4 characters... :-)

@TApplencourt
Copy link
Contributor Author

@gmlueck Added a CI test.

@TApplencourt
Copy link
Contributor Author

And perfect, the validation script work (https://github.com/KhronosGroup/SYCL-Docs/actions/runs/6748691663/job/18347563925)

@TApplencourt
Copy link
Contributor Author

This is ready to merge (if we agree on line width...). Summary of changes:

  • Copied Vulkan reflow.py and dependencies in our repo + updated abbrev list (thanks again @oddhack)
  • Run reflow on all chapters
  • Added a CI script to verify chapters conformance with reflow
  • Minor: Updated some github receipt version

@gmlueck
Copy link
Contributor

gmlueck commented Nov 3, 2023

What column width are you enforcing now? Is it 76 or 80? I agree with @keryell, 80 makes more sense than 76. From @oddhack's response, it didn't seem like there was any particular reason to choose 76.

@nliber
Copy link
Collaborator

nliber commented Nov 3, 2023

80 columns makes sense -- if folks are still using ADM-5 terminals! Even the mighty VT-100 had a 132 column mode.

Note: 80 columns is too many for my TRS-80, which only has 64 columns. (Okay, it also only had ALL CAPS, at least until I mod-ed it...)

(Honestly, just pick something...)

@TApplencourt
Copy link
Contributor Author

TApplencourt commented Nov 3, 2023

The default. So it's 76. Agree that 80 is the most popular. black -- the python formater -- did choose 88 🤷🏽

You probably noticed the peculiar default line length. Black defaults to 88 characters per line, which happens to be 10% over 80. This number was found to produce significantly shorter files than sticking with 80 (the most popular), or even 79 (used by the standard library). In general, 90-ish seems like the wise choice.

But they are talking about code length, not text. If we have already two people pushing for 80, I can change to that. Don't want to bikeshedding it too much :)

@TApplencourt
Copy link
Contributor Author

TApplencourt commented Nov 3, 2023

Changed default to 80. Funnily enough, it doesn't change anything :)

@keryell
Copy link
Member

keryell commented Nov 3, 2023

The reason I propose 79 instead of 80 is that sometimes 80 is a problem when there is a 80-hard limit and some editors or modes display some EOL char at the end, like my Emacs whitespace-mode to show all the weird chars.

@nliber
Copy link
Collaborator

nliber commented Nov 3, 2023

Doesn't making it more than 72 columns make us incompatible with Fortran?

(Sorry; couldn't resist...)

Copy link
Contributor

@ProGTX ProGTX left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, though I wonder if we need all of the Vulkan related stuff?

Also I agree with the 80 column limit, it's the most standard.

adoc/scripts/vkconventions.py Outdated Show resolved Hide resolved
@@ -40,8 +40,11 @@ jobs:
run: |
cd adoc
make OUTDIR=/tmp/out QUIET= html pdf
- name: Verify reflow conformance
run: |
./adoc/scripts/verify_reflow_conformance.sh
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading the script right, it's requiring that running reflow does nothing? That seems likely to make essentially every PR fail CI until you condition people to do this whenever they make a spec update. I've found it easier as the Vulkan spec editor to just do this when integrating PRs.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If I'm reading the script right, it's requiring that running reflow does nothing?

Yes. If I remember correctly, it was an ask from @gmlueck .

It looks like GitHub support issuing warning if we want to go this way.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is is bad for CI to fail if "reflow" detects that the formatting is wrong? This will prevent PRs from being merged until the formatting is fixed. Actually, I am hoping that contributors learn to run "reflow" themselves and fix these problems. However, even if the spec editor ends up doing it, the failing CI will ensure that someone fixes the formatting before PRs are merged.

Instead of pulling in all the Vulkan conventions.
@oddhack
Copy link
Contributor

oddhack commented Nov 7, 2023

@TApplencourt I made a PR against this branch on your fork that just implements the required SYCL conventions for the script to succeed.

Only implement necessary parts of a SYCL conventions object
Copy link
Contributor

@gmlueck gmlueck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason I propose 79 instead of 80 is that sometimes 80 is a problem when there is a 80-hard limit and some editors or modes display some EOL char at the end, like my Emacs whitespace-mode to show all the weird chars.

If 79 makes life easier for Emacs users, we can use that. This PR hasn't changed the column width yet, so it's still easy to choose a different number. Let's try to decide today, though.

@TApplencourt, there are a number of other PRs that are ready to merge, so I propose the following order:

  • We merge whatever PRs the WG approves in the meeting today.
  • You merge latest SYCL-2020/master branch into this PR.
  • Run reflow with whatever margin limit we decide on (79 or 80).
  • I'll merge this PR as an editorial change before the next WG meeting.

adoc/scripts/reflow.py Outdated Show resolved Hide resolved
@gmlueck
Copy link
Contributor

gmlueck commented Nov 10, 2023

@TApplencourt, other PRs have all been merged now, so we are ready for you to merge the latest "SYCL-2020/master" into this PR, resolve conflicts, and rerun reflow.

I suspect the merge conflicts might be substantial. If it is easier for you, you could create a new PR with the reflow scripts and run reflow in that new PR.

However you do it, I'll do a final check of the PDF to make sure nothing gets accidentally changed before merging.

@TApplencourt
Copy link
Contributor Author

Please see #495

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial Some purely editorial problem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants