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.
In standard awk, only the first character in RS is used, so regular expressions don't work. This means the resulting ps.h in plugins/core contains an illegal C string constant.
fix GVPR incorrect interpretation of color strings
The logical operators here were pretty clearly meant to be `&&` not `||`. But
this kind of micro-optimization is unnecessary on modern machines anyway, so we
can just rewrite this into something that is more obvious for both readers and
the compiler.
It would have been nice to add a provoking test case for this as well, but it is
not clear to me how exactly to reach this path. This bug has been open for quite
a while, so it seems simpler to apply the obvious fix and move on.
When processing characters in attribute values that should be escaped (e.g.
`"`), `gv2gml` would emit these as-is, resulting in invalid GML output. Such
attribute values are now correctly XML-escaped.
lib/common: move XML functions to a separate source file
Symbol resolution during linking is done on a per-file basis. Thus any use of a
function from labels.c was requiring all functions in labels.c to have their
symbols resolved. This is probably one of the partial causes of the
proliferation of duplicate XML escaping code (#1868).
This commit splits the XML escaping code into a separate file, allowing it to be
used without also requiring dependencies of unrelated functions in labels.c to
be satisfied. In the specific case motivating this, this will enable `gv2gml` to
call these XML escaping functions without linking against libcdt and libgvc.
For the above explained linking reasons, in future it may be desirable to
further separate library functions at an even finer grained basis than done in
this commit.
This has no immediate effect. However an upcoming change will introduce a header
include that brings in another 'path' symbol. So this change pre-emptively
squashes the -Wshadow compiler warning that would otherwise be introduced.
gv2gml: rename 'Agnodeinfo_t' type to 'Local_Agnodeinfo_t'
This has no immediate effect, but having a type named `Agnodeinfo_t` prevents
including lib/common/types.h which has its own `Agnodeinfo_t`. We will want to
include this header (transitively) in an upcoming commit.
adjust the release process to not require gen_version.py tweaks
This change has two primary motivations:
1. Streamlining the release steps and reducing the opportunities for human
error; and
2. Improving clarity in the release artifacts.
Following this change, no edits are required to gen_version.py in order to cut
a new release. The Graphviz version – both inter-release and for releases
themselves – is derived exclusively from CHANGELOG.md. The effect of this is
expected to be:
1. Cleaner release commits. No more regular churn of gen_version.py.
2. More obvious CHANGELOG.md in the release artifacts. This file will no
longer have a spurious “[Unreleased]” heading preceding the actual
changelog for the release.
There was the option to remove the first duplicate or the second in this file. I
checked that none of the intervening includes depended on a `_BB` definition. It
seemed clearer to remove the first and indicate that only Smyrna itself is using
`_BB`.
toggle Lefty to disabled by default in the Autotools build system
Based on a discussion that Lefty should be deprecated,¹ this takes the first
step towards removing it. It is hoped that by disabling it by default, this will
expose any downstream consumers who are relying on it being built by default.
If there are no complaints within three months, I think we can then remove build
system support entirely. If another three months pass without noise, I think we
can then remove Lefty sources from Graphviz.
In case the linked discussion is inaccessible when reading this commit message,
the summary from Stephen was:
Lefty was an early interpreter for graphics programming. It’s from about 1990
or 91, and we used it as the basis for a scriptable graphviz viewer, dotty.
It was student code written by Lefteris Koutsofios. I thought there was some
C code for parsing graphs but I could be wrong.
Even libast came into the picture much later, but I suppose that was done to
clean up some of its OS dependencies or to make it more portable or robust in
some way.
Magnus Jacobsson [Tue, 14 Sep 2021 14:27:04 +0000 (16:27 +0200)]
common: unify diverged storage-class attributes in globals.h
The immediate reason for this commit is to fix a bug when using the
autools build system with Cygwin, described below, but it is also a
step towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
This file had one set of Windows-specific storage-class attribute
declarations intended for use with the autotools build system and one
set intended for use with Visual Studio, with slightly different
control mechanisms.
It's unclear what effect changes made to these control mechanisms over
the years has had on the many operating systems that are not tested in
CI. The current state is that they partly overlap and are very hard to
understand.
This commit cleans this up by applying such declarations only if the
GVDLL or the WIN32_DLL symbol is set. An export declaration is used if
either the GVC_EXPORT or the _BLD_GVC symbol is defined and an import
declaration otherwise.
Using both GVDLL and WIN32_DLL for the same purpose is a temporary
measure and will be replaced by only one symbol in an upcoming commit
series towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
Since https://gitlab.com/graphviz/graphviz/-/merge_requests/2182,
setting GVDLL is the preferred single mechanism to enable those
attributes, rather than using _WIN32 and __CYGWIN__ plus some other
symbol to distinguish between static and dynamic-link/shared
libraries.
Likewise is the use of both GVC_EXPORT and _BLD_gvc for the same
purpose a temporary measure, which will be replaced by only one symbol
in an upcoming commit series towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
This fixes a segmentation fault when running 'dot -c' during 'make install' on Cygwin.
Debugging with gdb showed that this happened on line 99 in dot.c:
GvExitOnUsage = 1;
Magnus Jacobsson [Tue, 14 Sep 2021 18:06:19 +0000 (20:06 +0200)]
cmd/edgepaint: MSBuild: define GVDLL in the project file
Without this change, an upcoming commit in this series that unites the
storage class attributes in lib/common/globals.h that have diverged
for different build systems, would cause edgepaint to generate a
segmentation fault (error code 3221225477 = 0xC0000005: access
violation) when started on native Windows.
Also towards
https://gitlab.com/graphviz/graphviz/-/issues/2058#note_678679545.
Magnus Jacobsson [Mon, 13 Sep 2021 15:11:21 +0000 (17:11 +0200)]
gvc: autotools: work around cygwin linking problem with .def file
This workaround is just a temporary measure until an upcoming commit
series towards https://gitlab.com/graphviz/graphviz/-/issues/2058 will
remove the .def file.
Fixes this error with Cygwin when running 'dot -c' during installation.
C:/Users/magja/graphviz/build/bin/dot.exe: error while loading shared libraries: gvc.dll: cannot open shared object file: No such file or directory
Before this commit, the following results were obtained:
projects / graphviz / log