It is unclear where this originated from. It was added in the original commit of
this file but, at the time, the Autotools build system was not generating this
variable. The argz functionality seems related to the (now removed) dependency
RxSpencer, but Graphviz never used this and never checked whether it was
available.
fix: emit Bézier curves as point-by-point spline shapes in PIC plugin
With this change, the PIC plugin is finally usable. Bézier curves were being
emitted as a sequence of space-separated numbers. Similar to the previous
situation with boxes, I’m not sure what the intent of this was. This is invalid
PIC syntax. As of this commit, the PIC plugin produces output that is accepted
by GNU PIC. Fixes #131.
fix: print a point array as a point-by-point box in PIC back end
The existing code was emitting the points as a space-separated list of numbers.
It’s not clear what this was attempting to achieve. This is not a valid PIC
command. This change causes this to emit a sequence of line commands to draw the
described box. Related to #131.
This looks once again copied from the core PIC implementation
(lib/common/picgen.c) without accounting for the fact the core implementation’s
attrs macros are generated dynamically. The plugin generates a single macro,
attrs0, which it was incorrectly calling as attrs1. Related to #131.
The PIC plugin seems to have copied some details from the core PIC
implementation (lib/common/picgen.c) without noticing that the core
implementation juggles its comment format to emit PIC comments on pages and only
use TROFF comments at the top level. Related to #131.
pylintrc: backport inclusive language change from Pylint
Pylint commit 850c442dbda8d332049971d5c38f82b86da44f1d modified the pylintrc
template to remove the use of the problematic term “blacklist.” This commit
extracts the relevant parts of that and applies it to our code base, removing
the term in the Graphviz tree as well.
When upgrading to a version of Pylint that includes commit 12a76469782fab5c23d78039c4bfb37e3331945a, we should also swap our usage of
extension-pkg-whitelist for extension-pkg-allow-list.
The lab_gamut_data array is a lookup table (LUT) for some approximation of the
visible gamut of the CIELAB color space.¹ We have previously had extensive
problems compiling this file on Windows due to memory usage of MSVC. 0927817d203d61305da2b019f244744c10b588e6 finally brought things under control by
removing all struct usage which somehow was a factor.
This commit further reduces our requirements and guards against future such
situations. The LUT now, instead of listing every valid CIELAB value, lists
ranges in the CIELAB space. Some numbers:
old new
--------------
file size 8.3MB 149KB
LUT size 2.4MB 43KB
gcc-8.3 -O3 -c lab_gamut.c 5.8sec 0.8sec
max lab_gamut() malloc 18MB 151MB
If necessary, we could reduce the dynamic allocation performed by lab_gamut() by
doing a pre-scan to calculate how many actual CIELAB values we need to store for
a given call.
¹ I say “some approximation” because all my attempts to distill a formula for
deriving this table have failed. The closest is to enumerate the CIELAB
space, translate each color into Standard RGB and then check whether the
resulting value is within (0,0,0) - (255,255,255). However, this still is
not quite exact. I expect the machine on which this LUT was originally
generated uses a differently floating point representation or precision than
any that I have available.
This lookup table contains an approximation of the visible gamut of the CIELAB
color space.¹ While scaling to, e.g., Standard RGB is not linear, it is
continuous. Therefore it follows that if (L=5,a=22,b=6) is visible and
(L=5,a=22,b=8) is visible, (L=5,a=22,b=7) is also visible. This was presumably
an accidental deletion committed in pre-version-control days. Fixes #1974.
This replicates the metric tracking from some other CI jobs for the pylint task.
This should make the number of pylint warnings appear in the metrics section of
MRs, allowing us to track whether MRs increase or reduce the number of pylint
warnings.
sprintf has consistently been in the top ten root causes of vulnerabilities in
low level applications and is generally considered unsafe for any use in modern
code bases. This commit removes the instances of it that are straightforward to
convert to snprintf. Related to #1950.
remove intermediate string construction altogether in dot_polygon
There's no need for this and we can achieve it in one (well two) shot.
The better way to do this would be with an in-memory expanding buffer (like
open_memstream), but this change is at least an improvement over the previous
code.
The values being computed here were already computed in a previous block and
have not changed since. There was clearly copy-pasted wholesale from the code
above it.
fix: remove BROWSER #define from Windows MS Build compilation
This is only used by two plugins, glitz and xlib, and it’s unclear whether
either are intended to run on Windows. The code path using BROWSER is also only
enabled when the build environment has sys/types.h and unistd.h, neither of
which typically exist on Windows. In any event, xdg-open is not the way to open
a browser on Windows. It is better that we exclude this and fail at compile time
than build plugins that fail in unpredictable ways at runtime. Closes #1954.
fix: correctly recognize Windows packages in deploy script
239f6301789b603202d500f7ae58e800354c1524 identified Windows packages containing
the word “Windows” but the package filenames actually have this in lower case.
Closes #1955.
projects / graphviz / log