This macro stepped the target pointer forwards, but the only place in which it
was used subsequently stepped the pointer backwards. The manual unrolling of
short lengths in the macro is something modern compilers and/or CPUs are capable
of if the length is predictable statically or dynamically, respectively.
Mark Hansen [Sat, 16 May 2020 08:08:12 +0000 (18:08 +1000)]
Migrate output format doc generation ksh to jinja2
This commit replaces the ksh-based templating with Python Jinja2
templating.
Previously output.html was generated with:
- output.1
- the output of mkoutput.sh
- output.2
My end goal here is to make it much simpler to generate more complex
output format docs - however I've made this change so that the output is
virtually unchanged, except for HTML-escaping a single apostrophe.
My plan is to follow this up with adding some more features to the
output format documentation.
Templating in general provides a few opportunities:
- safe auto-html-escaping
- easier editing, easier adding of more data
- some separation of logic and templating
- inclusion of subtemplates
I chose Jinja2 because:
- It's the most popular Python templating engine, used by mature
products like Ansible and Flask.
- Graphviz's docs generation already takes a dependency on Python for
jconvert.py.
- The Python language is pretty accessible to contributors.
- Jinja2 seems pretty stable, going back to 2007. Unlikely to break
soon.
Alternatives considered:
- I could just as well have gone with Go's stdlib template/html but I
don't think Go is already used to build Graphviz, and Go isn't as
popular as Python, so not as accessible to contributors.
- Python Django templates: they're pretty similar to Jinja2, but I think
Django's templates are more heavyweight
We expect `python` to be a symlink to Python 3, not Python 2 but it does not
hurt to use syntax compatible with both. Other Python checks in configure.ac
were already using compatible syntax.
Mark Hansen [Fri, 22 May 2020 01:52:36 +0000 (11:52 +1000)]
Skip test_large_graphs on win32.
This test is expected to fail on win32 due to Window's smaller stack
size defaults:
- Windows by default uses 1MB stacks:
https://docs.microsoft.com/en-us/windows/win32/procthread/thread-stack-size
- Linux x86_64 seems to usually have a default of 8MB (architecture
dependent):
```
mark@x86_64_linux $ ulimit -a | grep stack
Maximum stack size (kB, -s) 8192
mark@arm32v6 $ ulimit -a | grep stack
Maximum stack size (kB, -s) 8192
```
This test failure is not a regression (it would have been failing before 81c3a3af), and it's blocking other submissions. This change gets the CI
green again to unblock forward progress.
Mark Hansen [Sun, 17 May 2020 03:15:17 +0000 (13:15 +1000)]
Squash Centos Dockerfiles yums into fewer layers
This should speed up builds, giving yum some more opportunity for
parallelism, and should decrease the Docker image size because the files
that are 'cleaned up' at the end are no longer in any of the Docker
filesystem layers.
Mark Hansen [Sat, 16 May 2020 05:04:29 +0000 (15:04 +1000)]
Collapse CI Dockerfile into a single layer
Speed up CI Docker build: apt-get update once
This is cribbed from
https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get,
particularly the 'well-formed RUN instruction that demonstrates all the
apt-get recommendations'.
This ensures that:
- apt-get has a lot of parallelism available to speed up downloading of
packages
- apt-get only has to read package information into memory once
(speeding up the build)
- one single revision of the Ubuntu package sets are used by all apt-get
installs (previously if Ubuntu updates packages between RUN commands
we might get packages from different revisions - unlikely but
possible)
- the /var/lib/apt/lists/* files are not present in any docker
filesystem layer, saving space (previously they were present in all
layers but the last layer, so the removal at the end didn't save any
space)
Mark Hansen [Sat, 16 May 2020 05:42:58 +0000 (15:42 +1000)]
Mark Makefiles that don't generate files as .PHONY
See
https://www.gnu.org/software/make/manual/html_node/Phony-Targets.html.
These targets aren't the name of a file, they're just a name for some
behaviour to run.
Marking them as .PHONY ensures that even if a file called 'clean' or
'distclean' or 'all' or 'install' exists in the directory, the code will
still be run.
Mark Hansen [Thu, 14 May 2020 11:39:41 +0000 (21:39 +1000)]
brewer.awk: Close file after opening.
macOS awk seems to have a limit to how many files it will open at once.
Fixes this error on macOS awk:
$ make
...
awk -f brewer.awk ../../lib/common/brewer_colors
awk: colortmp/brbg7 makes too many open files
input record number 131, file ../../lib/common/brewer_colors
source line number 13
make: *** [colors.html] Error 2
fix: print index instead of pointer value in debugging message
The .v and .av members of the structs being used here are node_t**s. So the
addition of an integer results in a node_t**. This does not seem like what was
intended to be printed here, but rather the integer value being added. This
issue was found by adding __attribute__((format(printf, 2, 3))) to agerr() and
then using compiler flag -Werror=format.
Henrik Grimler [Mon, 27 Apr 2020 06:24:34 +0000 (08:24 +0200)]
PriorityQueue: don't include deprecated malloc.h
We could guard it with `#ifdef HAVE_MALLOC_H` but it is not necessary in any
case, stdlib.h (and possibly malloc.h), are already included by memory.h which
PriorityQueue.c includes.
Should fix https://gitlab.com/graphviz/graphviz/-/issues/1696
Magnus Jacobsson [Sun, 12 Apr 2020 14:39:03 +0000 (16:39 +0200)]
Use any python version for python bindings
In order to work on Ubuntu 20.04 which does not have a "python" lib,
only "python3" and "python2".
See https://www.fosslinux.com/26413/ubuntu-20-04-lts-focal-fossa-set-to-remove-python-2.htm.
Also needed was to replace pyversion which found only Python 2
versions. Possibly this can done in a better way by someone who
understands Debian packaging in general and Lintian in particular.
See https://lintian.debian.org/tags/debian-pyversions-is-obsolete.html.
Magnus Jacobsson [Sun, 12 Apr 2020 06:31:51 +0000 (08:31 +0200)]
Use specific Python version to run shapes.py
The script runs fine with both Python 2 and Python 3, but on
e.g. Fedora 31, Centos 8 & Ubuntu 20.04 there is no "python"
program. Only "python2" and "python3".
For some rationale regarding Centos 8, see
https://www.liquidweb.com/kb/how-to-install-python-on-centos-8/
projects / graphviz / log