-
Notifications
You must be signed in to change notification settings - Fork 68
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
Run reflow #481
Conversation
There was a problem hiding this 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!
A few other notes about this script:
It is pretty robust within the scope of what it's intended for. We use it frequently on Vulkan. |
@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?). |
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.
Will rebase with #482 after it will be merged. |
There was a problem hiding this 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.
@oddhack do you know why 76 characters in "Force a maximum line width (default 76 char)"? |
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. |
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... :-) |
874620c
to
a1cf91e
Compare
@gmlueck Added a CI test. |
And perfect, the validation script work (https://github.com/KhronosGroup/SYCL-Docs/actions/runs/6748691663/job/18347563925) |
This is ready to merge (if we agree on line width...). Summary of changes:
|
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...) |
The default. So it's 76. Agree that 80 is the most popular.
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 :) |
Changed default to 80. Funnily enough, it doesn't change anything :) |
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. |
Doesn't making it more than 72 columns make us incompatible with Fortran? (Sorry; couldn't resist...) |
There was a problem hiding this 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.
@@ -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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
@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
There was a problem hiding this 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.
@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. |
Please see #495 |
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:
This is a small PR, so it should be easy to review...