The `ps_txt` array is only used in calls to `cat_libfile`, which does not need a
single line per array entry. By fusing all strings into the first `ps_txt` array
entry, we can reduce the number of eventual `gvputs` calls, accelerating the
entire operation.
Magnus Jacobsson [Sun, 10 Oct 2021 10:05:20 +0000 (12:05 +0200)]
CI: move generation of COLLECTION from macOS build template to individual jobs
This is no functional change, but makes the macOS build jobs more
similar to the Linux build jobs and opens up for letting the macOS
CMake and autotools builds use different COLLECTION in the future.
Magnus Jacobsson [Sun, 10 Oct 2021 09:06:31 +0000 (11:06 +0200)]
CI: don't generate GRAPHVIZ_VERSION file in macOS CMake build job
The version is generated internally to a variable in the CMake build
job and the downstream test job generates the file itself since commit fea17b6a9738eb96f037e22538d1885a75f20698.
This commit moves the generation of the GRAPHVIZ_VERSION file from the
build template to the macOS autotools build job.
remove generation of ps.h and commit generated output instead
The generation of ps.h from ps.txt was trivial and ps.txt was no easier to edit
or update than the resulting generated header. Removing it and using a static
source instead accelerates all three builds, increases portability and moves
towards dropping the dependency on Awk.
This function was seemingly incorrectly casting the (float) result of a float
subtraction to an integer. Apart from triggering compiler warnings, this had the
effect of concluding points that were merely close together were actually equal.
Despite being compiled and hooked into all three build systems, nothing in
Graphviz uses this and none of its artifacts are installed. Its compilation
appears to be an exercise without purpose.
pango_textlayout: replace 'agxbput(… xml_string0(…))' with 'xml_escape(…)'
Similar to the prior commit, this avoids dynamic allocating – well, some,
`axbput` itself is still dynamically allocating – and improves thread safety.
This is intended to be a functional no-op.
replace 'gvprintf(… xml_string(…))' with 'gvputs_xml'
A first demonstration of how to use the `xml_escape` functionality introduced in
preceding commits. Note that, while this is intended to be a non-functional
change, this does side step intermediate buffering in `xml_string` and escaped
output is now passed directly to `gvputs`.
plugin core: swap duplicated prototypes for missing includes
This file is calling functions `xml_string` `xml_url_string` without including
the header that prototypes them, utils.h. There seems to be no reason to avoid
this and locally re-prototype these functions.
expose a primitive 'xml_escape' for generic XML escaping
This function is intended to be a flexible XML-escaper that subsumes
`xml_string`, `xml_string0`, and `xml_url_string`. Unlike the preceding named
functions, calling `xml_escape` is thread-safe and does not mandate dynamic
allocation.
xml_string0: outline the inner loop body functionality
The motivation for this change is to move towards consolidating XML-escaping
functionality. The introduced function, `xml_core`, is intended to be usable by
`xml_url_string` and other Graphviz XML escaping functions in future.
This aim of consolidation hopefully also explains why this change looks more
complicated than might be expected. It is intended to be functionally a no-op.
But `xml_core` takes a generalized callback and state because it is imagined a
future caller may want to pass in, e.g. `gvputs` as their target sink for
XML-escaped data. That is, future changes may side step the static buffer usage
and allocation that happens in `xml_string0` and instead pump bytes directly
into a final target file.
switch to inclusive terminology 'allow-list' instead of 'whitelist' in Pylint
Pylint commit 12beaa0d3fa050b68dff092520966c63d2f0e437 added this alternative
spelling for this option, in line with the aim of using more inclusive
terminology. This made it into Pylint 2.7.3. As of the prior commit, Graphviz is
upgraded to Pylint 2.7.3 and can use this new spelling.
Commit a9c626e7f6a81f0949b1e4134e17c8968f13256b cherry-picked some upcoming
Pylint changes related to inclusive terminology. This and the remainder of the
changes relevant to Graphviz (the `extension-pkg-allow-list` option) made their
way into Pylint 2.7.3. By upgrading to 2.7.3 “whitelist” terminology can be
removed from Graphviz’ Pylint configuration.
Note that a9c626e7f6a81f0949b1e4134e17c8968f13256b incorrectly quotes Pylint
commit hashes from PR3961¹ that never made their way into the main Pylint branch
as-is but were rebased. The corresponding commit hashes are:
remove explicit support for PHP5 SWIG bindings in the Autotools build system
Older versions of SWIG can generate bindings for a variety of PHP versions.
Periodically SWIG bumps the version of PHP targeted by the default flag,
`-php`:¹
SWIG version `-php` effect PHP5 support? PHP7 support?
================================================================
<1.3.26 `-php4` no no
≥1.3.26, <1.3.37 `-php4` yes no
≥1.3.37, <3.0.11 `-php5` yes no
≥3.0.11, <4.0.0 `-php5` yes yes
≥4.0.0 `-php7` yes yes
This commit changes the behavior under the Autotools build system:
It seems reasonable to consider the first three rows of the above table
irrelevant. The last version of PHP5, 5.6, was EOLed on 2018-12-31,² so any
users in rows 1-3 of the table have been unsupported for some time. In practice,
only users in row 2 are affected by this change, who are using a version of SWIG
released prior to 2009-01-12.³
In future, it may make sense to drop build system support for the `-php` flag
altogether and *only* support `-php7`, given that using `-php` on an older
version of SWIG that defaults to PHP5 probably produces uncompilable code
anyway.
Python 3.10 was released on 2021-10-04 with what appears to be a breaking
change.¹ Graphviz’ Windows CI tasks (intentionally) install an unpinned
version of Python 3, so they get whatever the latest Python 3 version available
on Chocolatey is. Python 3.10 became available in Chocolatey on 2021-10-05 and
Windows CI tasks immediately started failing. The root cause is that 3.10
exposes a latent bug in Pytest.² This bug is reportedly fixed in Pytest 6.2.4,
so upgrading should repair Windows CI.
projects / graphviz / log