greg [Fri, 7 Oct 2022 00:34:47 +0000 (17:34 -0700)]
Increase stack size for dot MSBUILD project file (avoid crash on larger graphs)
Comment from Matthew Fernandez: It is believed this resolves some instances of
stack overflow in `dfs_enter_outedge` experienced with larger graphs on Windows.
Co-authored-by: Matthew Fernandez <matthew.fernandez@gmail.com>
Return value
…
The currently selected filename, or NULL if no file is selected, or the
selected file can’t be represented with a local filename. Free with g_free().
The caller of the method takes ownership of the data, and is responsible for
freeing it.
Contrary to this, `savefiledlg` was duplicating the pointed to data and then
losing the pointer `gtk_file_chooser_get_filename` returned.
The straightforward fix to this would be to retain the pointer and then `g_free`
it after copying its contents into the buffer `xbuf`. However, we can instead
refactor this function to avoid the copy altogether and simply pass the original
memory back to the caller, making this both a fix and an optimization.
On top of this, `on_gvprbuttonsave_clicked` was never calling `agxbfree` on its
local `xbuf`. By moving to a standard string, we also fix this memory leak.
Return value
…
The currently selected filename, or NULL if no file is selected, or the
selected file can’t be represented with a local filename. Free with g_free().
The caller of the method takes ownership of the data, and is responsible for
freeing it.
Contrary to this, `openfiledlg` was duplicating the pointed to data and then
losing the pointer `gtk_file_chooser_get_filename` returned.
The straightforward fix to this would be to retain the pointer and then `g_free`
it after copying its contents into the buffer `xbuf`. However, we can instead
refactor this function to avoid the copy altogether and simply pass the original
memory back to the caller, making this both a fix and an optimization.
graphml2gv: remove 'composite_buffer' from 'userdata_t'
1d28d7d2b4d2b2551bd1f432aa175f54a69364a4 seems to have copied this
implementation of `userdata_t` from cmd/tools/gxl2gv.c without noticing the
`composite_buffer` member is never used in graphml2gv.
graphml2gv: remove 'xml_attr_value' from 'userdata_t'
1d28d7d2b4d2b2551bd1f432aa175f54a69364a4 seems to have copied this
implementation of `userdata_t` from cmd/tools/gxl2gv.c without noticing the
`xml_attr_value` member is never written to in graphml2gv.
graphml2gv: remove 'xml_attr_name' from 'userdata_t'
1d28d7d2b4d2b2551bd1f432aa175f54a69364a4 seems to have copied this
implementation of `userdata_t` from cmd/tools/gxl2gv.c without noticing the
`xml_attr_name` member is never written to in graphml2gv.
This allows dropping several workarounds in the CMake build system. The only
supported platform with a CMake version less than 3.13.0 is Ubuntu 18.04. Given
CMake is not the default build system, the age of Ubuntu 18.04 makes it unlikely
there are users there building Graphviz from source, and later CMake versions
are easily obtainable from Kitware, it seems reasonable to increase this
requirement.
The `rsvg_term` function has been a no-op for some time:¹
rsvg_term has been deprecated since version 2.36 and should not be used in
newly-written code.
There is no need to de-initialize librsvg.
This function does nothing.
Graphviz was calling it when linked against librsvg 2.36 (2.36.0 was released
2012-03-26). I do not know why this code was conditional as `rsvg_term` has been
a no-op since 2.35.0.² Moreover, calling it prior to it becoming a no-op was
wrong too. The commit that removed its functionality notes:
rsvg_term() was dangerous to call
The problem is that it previously called libxml2’s `xmlCleanupParser` whose
documentation states:³
This function name is somewhat misleading. It does not clean up parser state,
it cleans up memory allocated by the library itself. It is a cleanup function
for the XML library. It tries to reclaim all related global memory allocated
for the library processing. It doesn't deallocate any document related memory.
One should call xmlCleanupParser() only when the process has finished using
the library and all XML/HTML documents built with it. See also xmlInitParser()
which has the opposite function of preparing the library for operations.
WARNING: if your application is multithreaded or has plugin support calling
this may crash the application if another thread or a plugin is still using
libxml2. It's sometimes very hard to guess if libxml2 is in use in the
application, some libraries or plugins may use it without notice. In case of
doubt abstain from calling this function or do it just before calling exit()
to avoid leak reports from valgrind !
This seems to have come to light ~2010.⁴ But presumably there is still a long
tail of software in the wild still, like Graphviz, erroneously calling
`rsvg_term`.
The `-ffast-math` compiler option enables a mode of floating point semantics
that are heavily relaxed from strict IEEE 754 conformance in the name of speed.¹
The permissible optimizations under `-ffast-math` include transformations that
produce floating point results most users would consider wrong. It is unclear
why “do math fast but incorrectly” is a useful mode. It seems the world is
finally coming around to this tenet.²
This change stops enabling `-ffast-math` anywhere in the Autotools build system.
Gitlab: fixes #1412, #2296 Reported-by: Kasper Daniel Hansen Reported-by: Ross Barnowski
¹ https://gcc.gnu.org/wiki/FloatingPointMath
² https://simonbyrne.github.io/notes/fastmath/,
https://moyix.blogspot.com/2022/09/someones-been-messing-with-my-subnormals.html
remove suppression of -ffast-math when building with ICC
The Intel C Compiler does not support the `-ffast-math` command line option, so
this logic was suppressing it. But it is coming before anything in the Graphviz
build system itself that would add `-ffast-math`. So it is actually suppressing
a `-ffast-math` addition coming from the user’s environment. If you are a user
compiling Graphviz with ICC, I have a very simple alternative for you: do not
pass `-ffast-math` explicitly.
Of the platforms Graphviz supports, the one with the oldest CMake version
available is Ubuntu 18.04, which has CMake 3.10.2. This change raises the
baseline CMake requirement to indicate we no longer support CMake 3.9.
The diff between CMake 3.9 and 3.10 does not actually contain anything useful to
Graphviz. But it still seems wise to proactively move our floor forwards.
Mark Hansen [Sat, 8 Oct 2022 03:32:49 +0000 (14:32 +1100)]
Use full paths to pangocairo libraries, not names
This lets me build on macOS.
Thanks to Matthew for finding this fix for #2286
There are a few other usages of PANGOCAIRO_LIBRARIES within Graphviz,
but none that I'm currently compiling on macOS. Maybe those should be
moved too, but I've just started with this one.
Magnus Jacobsson [Fri, 16 Sep 2022 10:35:53 +0000 (12:35 +0200)]
shapes: point_init/point_inside: fix clipping of edge at node outline
Take node penwidth into account for the point node shape
Following the fix for polygon and ellipse shapes except the 'point'
shape, this fixes the second part of arrow not respecting penwidth for
the 'point' shape. A similar fix needs to be applied to fix the second
part for the 'cylinder' node shape.
The test_edge_node_overlap_point_node_shape test now succeeds, so the
expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Fri, 16 Sep 2022 08:53:36 +0000 (10:53 +0200)]
shapes: poly_init: fix clipping of edge at node outline for ellipse node shapes
Take node penwidth into account also for ellipse node shapes.
Following the fix for polygon node shapes, this fixes the second part
of arrow not respecting penwith for ellipse shapes other than
'point'. Similar fixes need to be applied to fix the second part for
the 'point' and 'cylinder' node shapes.
The test_edge_node_overlap_ellipse_node_shapes_except_point test now
succeeds, so the expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Thu, 15 Sep 2022 17:01:54 +0000 (19:01 +0200)]
arrows: miter_point: add fallback to bevel
The 'l' and 'r' arrow shape modifiers make the arrow tip have a sharp
angle and causes the normal miter point to exceed the 'miter-limit'
and SVG renderers to fall back to a bevelled corner.
Magnus Jacobsson [Sun, 17 Apr 2022 16:55:50 +0000 (18:55 +0200)]
arrows: arrow_length_normal: take edge penwidth into account when calculating length
This causes the edge stem to be clipped at the visual outline of the
edge arrow instead of at its "ideal" bounding box which fixes the too
large overlap between them that was introduced by eariler commits in
this series.
The test_max_edge_stem_arrow_overlap_simple.cpp,
test_edge_node_overlap_normal_and_inv_edge_arrows
test_edge_node_overlap_simple and test_edge_node_overlap_node_shapes
test cases now succeed, so the expectancy that they should fail is
removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Sun, 17 Apr 2022 15:45:24 +0000 (17:45 +0200)]
arrows: refactor arrow length calculation to allow arrow type specific length functions
Add a len function to arrowtype_t. This is currently a no-op. All
arrow types use a generic function that just returns the nominal
length. Future commits will replace the generic function with
functions specific for each arrow type.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Wed, 13 Apr 2022 21:01:41 +0000 (23:01 +0200)]
splines: bezier_clip: change to clip just inside instead of just outside the node
The previous changes removed *all* overlap between nodes and edges at
the expense of creating a very small gap instead. This is visually not
very pleasing. This change ensures that we get a very small minimum
overlap instead.
The test_min_edge_node_overlap_simple and
test_min_edge_node_overlap_node_shapes tests tests now succeed, so the
expectancy that they should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Wed, 14 Sep 2022 19:58:57 +0000 (21:58 +0200)]
shapes: star_inside: fix clipping of edge at node outline
Take node penwidth into account when doing the clipping of the 'star'
shape. This causes the clipping to occur at the visible node outline
instead of at the "ideal" bounding box which does not take node
penwidth into account.
For the star shape, this fixes the second part of arrow not respecting
penwidth. Similar fixes need to be applied to fix the second part for
other node shapes.
The test_max_edge_node_overlap_node_shapes test case now succeeds, so
the expectancy that it should fail is removed.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
Magnus Jacobsson [Mon, 11 Apr 2022 18:06:26 +0000 (20:06 +0200)]
shapes: poly_init/poly_inside: fix clipping of edge at node outline
Take node penwidth into account when doing the clipping. This causes
the clipping to occur at the visible node outline instead of at the
"ideal" bounding box which assumes a zero node penwidth.
For polygon shapes, this fixes the second part of arrow not respecting
penwidth. Similar fixes need to be applied to fix the second part for
other node shapes.
The test_max_edge_node_overlap_simple test now succeeds, so the
expectancy that it should fail is removed.
The test_min_edge_node_overlap_simple and
test_min_edge_node_overlap_node_shapes tests now fail since there's
now a small gap between the edge and the node, so they're temporarily
set to be expected to fail. This gap will be removed in an upcoming
commit in this series.
Towards https://gitlab.com/graphviz/graphviz/-/issues/372.
projects / graphviz / log