Dear,
All, I have now created the release branch for version 4.4.0 of the
Guidelines (https://github.com/TEIC/TEI/tree/release-4.4.0) and for version
7.53.0 of the Stylesheets (
https://github.com/TEIC/Stylesheets/tree/release-7.53.0)
Please refrain from committing anything to dev until the release is
completed. If you wish to make changes to the release branches, please
notify the release technicians before pushing any change. The technicians
are: Janelle Jenstad, Hugh Cayless, Raff Viglianti.
Could the Jenkins maintainers add these branches to be built?
Thanks everyone!
Raff
1
0
release notes
by Scholger, Martina (martina.scholger＠uni-graz.at)
15 Apr '22
One of the reasons the test procedure in Stylesheets/Test2/ is dramatically faster than the one in Stylesheets/Test/ is that it is, by default, run in parallel.[1,2]
You can also ask the make command to run multiple jobs at once. The switches that control this are --jobs= and --output-sync=. I just tried an experiment, comparing how long it took to run make vs make --jobs=7 --output-sync=lines. (I chose 7 because my system has 8 threads, and I wanted to have some CPU available. What little I have found on the web seems to suggest I may as well go ahead and use 8.)
The result was faster, although not even close to 7 times faster: down to 03:32 from 04:36. I compared the output of the 2 commands, and they were identical.
On GNU/Linux, at least, the nproc command will tell you how many threads are available. Thus using the command
$ make --jobs=`nproc 2>/dev/null || echo 1` -Oline
seems to make sense to me. (-O is shorthand for --output-sync=.)
It is also possible to get the Makefile to do that on its own. My first thought is that might not be such a good idea, because you may want to run with --jobs=1 in order to force error messages into the right order. (I.e., in case -Oline wasn’t good enough.)
I ran the experiment again, this time using --jobs=8 and getting screen captures of the process monitor roughly 40 s after the make command started.[3] The timing results were very similar (down to 03:36 from 04:36), but the order of output lines was different. (Same output; i.e., they were identical after sorting and removing timestamps.)
So I think anyone running the Stylesheets test process would do well to use the --jobs switch. You could use any of
* -j 8 # if you know you have 8 threads, e.g.
* --jobs=`nproc` # if you know the nproc command works on your system
* -j `nproc 2> /dev/null || echo 1` # if there is a chance nproc fails, so it defaults to '1'
Martina — could you either update the notes we have about updating P5 subset, or remind me where they are and I will? Thanks.
Notes
[1] ant test runs them in parallel; if you want them in series (likely because the order of messages was confusing when run in parallel) use ant testSeries.
[2] There are other reasons, like it is written to be less redundant, and the JVM is only spun up once, rather than once for every test.
[3] For evidence as to why --jobs makes make faster, see
https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_process_m…
and
https://bauman.zapto.org/~syd/temp/4TEICouncil/Screenshot_of_make_-j_proces…
Re: “Confirm with SB that https://github.com/TEIC/TEI/pull/2204 is ready to merge.” — agenda from yesterday’s meeting
I think I have addressed Magdalena’s (reasonable) question on the PR<https://github.com/TEIC/TEI/pull/2204#pullrequestreview-929550387>. Thus, unless she or someone else disagrees, yes, PR #2204 is, IMHO, ready to merge.
And I have just merged dev branch into the issue branch (sydb_issue-2185_URI_spaces).
Hi all,
I'd like to draw Council's attention to these two tickets:
<https://github.com/TEIC/oxygen-tei/issues/54>
<https://github.com/TEIC/TEI/issues/2251>
where two things have happened:
1. As usual, we were caught unawares when Oxygen released an update
which broke functionality in the TEI Oxygen plugin version that we
maintain. Oxygen maintain their own fork of the plugin repo and up to
now, they've been making any necessary changes silently before an Oxygen
release; then we realize that something is broken and struggle to catch
up. I now have a pull request that I've asked Radu Coravu from Oxygen to
review before I merge it, updating the included libs for transformations
to take account of log4j changes.
For those new to the situation, it's a bit complicated: the Oxygen folks
only care about ensuring that the version of the plugin that ships with
Oxygen works with the Oxygen version it ships with. However, we have
different requirements, because we attempt to maintain support for older
versions of Oxygen, so that those who cannot upgrade for some reason are
still able to get up-to-date versions of P5, the Stylesheets, and the
transformations in their older Oxygen.
This means that we can't simply adopt any of the changes that the Oxygen
folks make directly into our own branch; that would remove functionality
for earlier Oxygen versions. So we have to try to merge the changes
carefully.
When the pull request is checked and merged, then our bleeding-edge
version of the plugin will build, and those of us using it (which I hope
is a reasonable subset of the Council) are able to test and make sure
nothing is badly broken. We don't have a formal testing procedure,
though, especially for older versions of Oxygen, because few of us run
older versions.
If the bleeding edge version is deemed OK, then Council will need to
release the corresponding stable version using the procedure that's
normally followed when we do a P5/Stylesheets release.
There is a degree of urgency here because currently, anyone who is
subscribed to our plugin and has upgraded their Oxygen to the current
version will not be able to use any of the transformations, as Laurent
discovered.
2. Radu has kindly agreed to raise issues on our plugin repo when they
make changes in future, so we can try to avoid this happening again. I
think I'm the only one who watches this repo at the moment, which is not
really ideal.
Cheers,
Martin
--
------------------------------------------
Martin Holmes
UVic Humanities Computing and Media Centre
I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional
territory the university stands and the Songhees, Esquimalt and WSÁNEĆ
peoples whose historical relationships with the land continue to this day.
Dear Council,
This is the agenda for our virtual F2F meeting on Friday and Saturday (April 1 and 2):
https://docs.google.com/document/d/1WhGAcLK0H_xNNPoEECBk9f0eEn-qhSiWfqnhaik…
Please feel free to add more topics to the agenda.
Meeting times:
Friday, Apr 1:
North American break-outs
The North American group needs to decide whether to start at 12 PDT / 15 EDT or at 13 PDT / 16 EDT (see poll on slack).
Saturday, Apr 2:
European break-outs
10:00-13:00 CEST
Full Council
06:00-10:00 PDT
09:00-13:00 EDT
15:00-19:00 CEST
I'll add the table with links to the Guidelines/Stylesheets issues tomorrow.
Best,
Martina
Dr. Martina Scholger
Centre for Information Modeling
Austrian Centre for Digital Humanities
University of Graz
A-8010 Graz | Elisabethstraße 59/III
+43 316 380 2291
http://informationsmodellierung.uni-graz.at<http://informationsmodellierung.uni-graz.at/> | http://gams.uni-graz.at<http://gams.uni-graz.at/>
Chair of the TEI Technical Council | http://www.tei-c.org/
Institut für Dokumentologie und Editorik e.V. | https://www.i-d-e.de/
