digraphs / digraphs Goto Github PK

Originally reported by: Stuart Burrell (Bitbucket: stuartburrell, GitHub: Unknown)

Apple LLVM version 7.0.0 (clang-700.0.72)

Strange compiler errors produced when compiling package.

src/digraphs.c:1922:37: warning: comparison of constant 38 with boolean expression is always false [-Wtautological-constant-out-of-range-compare]
      && ! TNUM_OBJ(user_param_arg) == T_PLIST_EMPTY) {
         ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~

src/digraphs.c:2056:37: warning: comparison of constant 38 with boolean expression is always false [-Wtautological-constant-out-of-range-compare]
      && ! TNUM_OBJ(user_param_arg) == T_PLIST_EMPTY) {
         ~~~~~~~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~~~~~~~

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/9

Originally reported by: Jan De Beule (Bitbucket: jdebeule, GitHub: jdebeule)

In the example included here we read a digraph from a file which is actually just the point graph of a finite classical polar space. This means that it is symmetric, has no loops, has diameter 2, and girth 3.

#!GAP

gap> digraph := ReadDigraphs("polarq6_3.d6.gz")[1];
<digraph with 364 vertices, 43680 edges>
gap> DigraphDiameter(digraph);
2
gap> DigraphGirth(digraph);   
2
gap> graph := Graph(digraph);;
gap> Diameter(graph);
2
gap> Girth(graph);
3

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/11

Originally reported by: Attila Egri-Nagy (Bitbucket: egri-nagy, GitHub: egri-nagy)

Do you have DotDigraph somewhere else?

#!python

gap> LoadPackage("graphs");
Error, variable `DotDigraph' is not bound to an operation called from
...

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/4

From Gordon Royle via the GAP forum:

I am using the GAP package “digraphs” to determine whether or not there is a homomorphism from a digraph d1 to a digraph d2 (in fact they are graphs, but that does not matter).

The actual two graphs that I am using are included at the bottom of this message for anyone wishing to replicate this behaviour, but the key point is that d1 has 16 vertices and d2 has 32.

When I issue the command

gap> DigraphHomomorphism(d1,d2);
Transformation( [ 1, 2, 3, 9, 7, 8, 4, 19, 6, 32, 30, 5, 18, 31, 29, 20, 17,
 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32 ] )

the output is a Transformation, indicating that there is indeed a homomorphism from d1 to d2.

But why does the transformation have 32 entries, when d1 is a digraph with only 16 vertices?

Do I just take the first 16 entries as the actual transformation, and ignore the rest?

gap> Print(d1);
Digraph( [ [ 12, 2, 13, 3, 4, 5, 6, 7, 8, 9 ], [ 11, 1, 12, 13, 3, 14, 15, 5,
7, 9 ], [ 11, 1, 12, 2, 15, 6, 7, 8, 9, 10 ], [ 1, 12, 13, 14, 5, 16, 6, 7, 8,
10 ], [ 1, 2, 13, 14, 4, 15, 16, 7, 8, 9 ], [ 11, 1, 12, 13, 3, 4, 16, 8, 9,
10 ], [ 1, 2, 3, 4, 5, 8, 10, 12, 14, 15 ], [ 1, 3, 4, 15, 5, 16, 6, 7, 9, 10
], [ 11, 1, 2, 13, 3, 15, 5, 16, 6, 8 ], [ 11, 12, 3, 14, 4, 15, 16, 6, 7, 8 ]
, [ 12, 2, 13, 3, 14, 15, 16, 6, 9, 10 ], [ 11, 1, 2, 13, 3, 14, 4, 6, 7, 10 ]
, [ 11, 1, 12, 2, 14, 4, 5, 16, 6, 9 ], [ 2, 4, 5, 7, 10, 11, 12, 13, 15, 16 ]
, [ 11, 2, 3, 14, 5, 16, 7, 8, 9, 10 ], [ 11, 13, 14, 4, 15, 5, 6, 8, 9, 10 ]
] )

gap> Print(d2);
Digraph( [ [ 17, 18, 2, 19, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16 ],
[ 29, 1, 30, 31, 3, 4, 5, 6, 7, 10, 11, 12, 13, 18, 21, 22, 23, 24 ], [ 29, 1
, 30, 2, 32, 4, 5, 6, 8, 10, 11, 14, 15, 19, 21, 22, 25, 26 ], [ 17, 1, 2, 19,
3, 5, 23, 7, 24, 9, 27, 28, 12, 29, 13, 31, 32, 16 ], [ 1, 30, 2, 31, 3, 32,
4, 8, 9, 14, 15, 16, 17, 18, 25, 26, 27, 28 ], [ 17, 1, 18, 2, 19, 3, 20, 23,
7, 24, 8, 25, 26, 10, 11, 29, 30, 16 ], [ 29, 1, 2, 31, 4, 6, 9, 12, 13, 14, 1
5, 18, 19, 20, 21, 22, 27, 28 ], [ 1, 30, 3, 32, 5, 6, 9, 12, 13, 14, 15, 18,
19, 20, 21, 22, 27, 28 ], [ 17, 1, 18, 19, 20, 4, 5, 23, 7, 24, 8, 25, 26, 10,
11, 31, 32, 16 ], [ 17, 1, 2, 3, 20, 21, 22, 6, 23, 25, 9, 27, 28, 12, 14, 31
, 32, 16 ], [ 17, 1, 2, 3, 20, 21, 22, 6, 24, 9, 26, 27, 28, 13, 31, 15, 32, 1
6 ], [ 1, 30, 2, 32, 4, 7, 8, 10, 14, 15, 16, 20, 21, 23, 24, 25, 26, 28 ], [
17, 1, 2, 20, 4, 22, 23, 7, 24, 8, 25, 26, 27, 11, 30, 14, 15, 32 ], [ 29, 1,
31, 3, 5, 7, 8, 10, 12, 13, 16, 20, 22, 23, 24, 25, 26, 27 ], [ 29, 1, 31, 3,
5, 7, 8, 11, 12, 13, 17, 20, 21, 23, 24, 25, 26, 28 ], [ 29, 1, 30, 4, 5, 6, 9
, 10, 11, 12, 14, 20, 21, 22, 24, 26, 27, 28 ], [ 29, 1, 30, 4, 5, 6, 9, 10, 1
1, 13, 15, 20, 21, 22, 23, 25, 27, 28 ], [ 1, 30, 2, 31, 5, 6, 7, 8, 9, 20, 21
, 22, 23, 24, 25, 26, 27, 28 ], [ 1, 3, 20, 4, 21, 22, 23, 6, 24, 7, 8, 25, 9,
26, 27, 28, 29, 32 ], [ 29, 30, 31, 32, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 1
6, 17, 18, 19 ], [ 2, 31, 3, 32, 7, 8, 10, 11, 12, 15, 16, 17, 18, 19, 23, 26,
27, 28 ], [ 2, 31, 3, 32, 7, 8, 10, 11, 13, 14, 16, 17, 18, 19, 24, 25, 27, 2
8 ], [ 30, 2, 32, 4, 6, 9, 10, 12, 13, 14, 15, 17, 18, 19, 21, 25, 26, 27 ], [
30, 2, 32, 4, 6, 9, 11, 12, 13, 14, 15, 16, 18, 19, 22, 25, 26, 28 ], [ 29, 3
1, 3, 5, 6, 9, 10, 12, 13, 14, 15, 17, 18, 19, 22, 23, 24, 28 ], [ 18, 19, 3,
21, 5, 6, 23, 24, 9, 27, 11, 12, 29, 13, 14, 31, 15, 16 ], [ 17, 18, 19, 4, 21
, 5, 22, 23, 7, 8, 26, 10, 11, 29, 13, 30, 14, 16 ], [ 29, 30, 4, 5, 7, 8, 10,
11, 12, 15, 16, 17, 18, 19, 21, 22, 24, 25 ], [ 30, 2, 31, 3, 32, 4, 6, 7, 14
, 15, 16, 17, 19, 20, 25, 26, 27, 28 ], [ 17, 18, 2, 3, 20, 5, 6, 23, 24, 8, 2
7, 28, 12, 29, 13, 31, 32, 16 ], [ 29, 30, 2, 32, 4, 5, 7, 9, 10, 11, 14, 15,
18, 20, 21, 22, 25, 26 ], [ 29, 30, 31, 3, 4, 5, 8, 9, 10, 11, 12, 13, 19, 20,
21, 22, 23, 24 ] ] )

This could be useful for performance reasons, particularly for McAlisterTripleSemigroups.

It would be helpful to have methods for IsDistributiveLatticeDigraph and IsModularLatticeDigraph and perhaps some more.

Similar to the bug in IsAntisymmatricDigraph #52, I have found a bug in DigraphTopologicalSort, caused by the function FuncDIGRAPH_TOPO_SORT assuming that it is given a PLIST of PLISTs. Current behaviour:

gap> gr := Digraph([[1 .. 4], [2, 4], [3 ,4], [4]]);
<digraph with 4 vertices, 9 edges>
gap> DigraphTopologicalSort(gr);
Segmentation fault: 11

Expected output:

gap> gr := Digraph([[1 .. 4], [2, 4], [3 ,4], [4]]);
<digraph with 4 vertices, 9 edges>
gap> DigraphTopologicalSort(gr);
[ 4, 2, 3, 1 ]

I've identified the problem, it's the same kind of issue as caused Issue #52. I'll make a PR to fix it, but I thought it would make it easier to keep track of these things for the release and for the tests if I also create an issue.

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

The following shows a practical example.

gap> d := Digraph([ [2], [3], [1,1] ]);
<multidigraph with 3 vertices, 4 edges>
gap> Print(OnDigraphs(d, PermList([2,3,1])));
Digraph( [ [ 2, 2 ], [ 3 ], [ 1 ] ] )
gap> Print(OnDigraphs(d, Transformation([2,3,1])));
Digraph( [ [ 2 ], [ 3 ], [ 1 ] ] )

I imagine that multidigraphs should repeat edges with transformation?

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/17

I am having problems compiling the GAP package digraphs.
I am running Windows 7 Professional SP1 and GAP 4.8.6.

I have read the instructions https://www.gap-system.org/Manuals/pkg/digraphs-0.5.2/doc/manual.pdf
In order to run the ./configure and make I downloaded MinGW.
Using MinGW I navigated to the /pkg/digraphs-0.5.2 folder and then typed ./configure.
This I think worked ok although I am not sure. It returned no errors.
Then when I typed make I got the following

I did a google search for unknown type name 'sigjmp_buf' but I did not see anything useful.

Does the screen shot above (the one of GAP running) suggest that I am using Cygwin to run GAP
Architecture: i686-pc-cygwin-gcc-default32
and is this a problem when using MinGW to configure and make the digraphs package.

I have no idea as to what to do now. Any help would be appreciated.

Best regards,

Kieran.

Regards,

Originally reported by: Michael Torpey (Bitbucket: mtorpey, GitHub: mtorpey)

I think I've figured out one source of our memory leaks.

In a new session of GAP, try the following:

gap> gr1 := CompleteDigraph(2);;
gap> gr2 := CompleteDigraph(3);;
gap> func := function(user_param, t)
>      user_param := user_param ^ t;
> end;;
gap> homos := HomomorphismDigraphsFinder(gr1, gr2, func, Group(()), infinity,
>  fail, false, DigraphVertices(gr2), []);
MT: Setting STAB_GENS[0] in GraphHomomorphisms
Error, no method found! For debugging hints type ?Recovery from NoMethodFound
Error, no 1st choice method found for `^' on 2 arguments called from
user_param ^ t on line 4 of file *stdin* called from
GRAPH_HOMOS( gr1, gr2, hook, user_param, limit, hint, isinjective, image, fail, map 
 ); on line 82 of file /home/mtorpey/gap/pkg/digraphs/gap/grahom.gi called from
<function "HomomorphismDigraphsFinder">( <arguments> )
 called from read-eval loop at line 7 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue

STAB_GENS[0] is being set on homos.c:1418 (mod line numbers) and the memory region should be freed around line 1441. However, before we get there we try to evaluate user_param ^ t, which throws a "no method found" and breaks out of the C function before it gets to the free_perm_coll line. Hence the next time we use this function, STAB_GENS[0] is overwritten and the reference to that perm_coll is lost without it being freed.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/8

I have successfully installed and loaded Digraphs 0.4.2 which came bundled with GAP4r8.

But prefer to clone its github repository so I can test different versions and upgrade easily. But I have not been able to install any version from the git repository. When I clone the repository there is no "configure" file. This happens in all testes branches (master, stable-0.5, stable-0.6). Any help here?

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

Easier to show with a couple of examples. I think in these cases the graphs gr1, gr2 and im should all be the same graph. I think that either the digraph constructor has to sort it's input, or = has to compare as sets?

gap> gr1 := Digraph([[2],[1],[1,2]]);
<digraph with 3 vertices, 4 edges>
gap> gr2 := Digraph([[2],[1],[2,1]]);
<digraph with 3 vertices, 4 edges>
gap> gr1 = gr2;
false
gap> im := DigraphRelabel(gr1, (1,2));
<digraph with 3 vertices, 4 edges>
gap> Print(im);
Digraph( [ [ 2 ], [ 1 ], [ 2, 1 ] ] )
gap> gr1 = im;
false
gap> gr2 = im;
true

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/2

DigraphColouring is documented as follows:

A proper colouring of a digraph is a labelling of its vertices in such a way that adjacent vertices have different labels. A proper n-colouring is a proper colouring that uses exactly n colours. Equivalently, a proper (n-)colouring of a digraph can be defined to be a DigraphEpimorphism from a digraph onto the complete digraph.

I think this is fine. When given the second argument n, DigraphColouring tries to find an actual n colouring; it fails if the digraph has loops. However, the 1-argument version, which uses a greedy algorithm to find any semi-decent colouring, ignores loops, and returns what I believe to be incorrect colourings:

gap> gr := Digraph([[1, 2], [1, 2, 3], [2, 3]]);
<digraph with 3 vertices, 7 edges>
gap> DigraphColouring(gr);
Transformation( [ 1, 2, 1 ] )
gap> DigraphColouring(gr, 2);
fail

This should be nice and easy to fix.

Currently there is a method IsIsomorphicDigraph which takes two digraphs and (optionally) two colourings of them. This requires the user to store the digraph and the colour separately (or at least remember to take the colouring that might be stored in VertexLabels).

This is impractical at least in the following use-case:
Assume there is an attribute which should be a coloured digraph. Since the vertex labels are usually used to suggest a connection between the graph and the original object they can't be used to store the colouring. While it would be possible to define an additional attribute describing the colouring, that is not something that a user expects (especially since the alternative package GRAPE can handle those colourings without issue).

The user would expect that they can just evaluate this attribute for different objects and then work with them. This includes testing for isomorphism. It is possible to define an IsIsomorphic-operation on the original object that computes the isomorphism with additional colours but this would again be unexpected and furthermore preclude the user from doing this on their own (which might be needed in their programs).

Therefore it would be helpful if there were an option to make ColouredDigraph or at least allow a colouring to be defined (which is not necessarily a proper vertex colouring) that is picked up in the IsIsomorphicDigraph-method.

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

As in subject, stack2 is malloced on src/digraphs.c:77, but never freed

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/1

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

Is there any way to read the 'DIMACS' format in Digraphs? I couldn't find it.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/15

The Travis tests are currently failing. This not because of the Digraphs package itself, since Travis is not managing to properly load GAP in the first instance.

I'm not an expert on Travis, so I'm not sure whether the problem is our fault or Travis's fault (or something else). However I thought I should record the failure somewhere, since as far as I'm aware the tests and manual examples are running fine in the package.

Loading digraphs in master now gives a warning, as it accesses the the undocumented internal list CONSTRUCTOR, which recently was removed.

The easiest fix is to just remove that check and the associated code:

    elif op in CONSTRUCTORS then
      class := "Constructor";
      # seem to never get one

as you don't use DeclareConstructor in digraphs, it doesn't matter.

Alternatively, you could use TypeOfOperation, but that is only available in GAP 4.9 and later.

Originally reported by: Markus Pfeiffer (Bitbucket: markusp, GitHub: markusp)

Check whether the C part is available. If not, give a proper error message.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/3

Originally reported by: Michael Torpey (Bitbucket: mtorpey, GitHub: mtorpey)

Assuming we have the digraphs-lib library downloaded and unzipped, the following happens:

gap> gr := ReadDigraphs(Concatenation(DIGRAPHS_Dir(), "/digraphs-lib/extreme.d6.gz"), 1);
<digraph with 5000 vertices, 4211332 edges>
gap> gr := ReadDigraphs(Concatenation(DIGRAPHS_Dir(), "/digraphs-lib/extreme.d6.gz"), 1);
Error, Digraphs: ReadDigraphs: usage,
cannot open file /home/mtorpey/gap/pkg/digraphs/digraphs-lib/extreme.d6.gz, called from
<function "ReadDigraphs">( <arguments> )
 called from read-eval loop at line 2 of *stdin*
type 'quit;' to quit to outer loop

Is this something to do with the file not being closed correctly?

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/6

Just forked Digraphs from GitHub gap-packages.
./configure failed at the first attempt (-bash: ./configure: No such file or directory)
but succeeded after running autogen.sh.

It would be useful, for instance for @mtorpey's work on posets of semigroup congruences, to be able to create a digraph object whilst simulatenously setting it to satisfy a particular filter. For Michael, this would be IsCongruencePoset. The interface could be something like:

gap> Digraph(nbs, IsCongruencePoset);
<poset of whatever>

Since we have a million ways of creating digraphs (various versions use Digraph itself, as well as DigraphByAdjacenyMatrix, DigraphByInNeighbours, etc), we'll need to think carefully about what we want to do.

The documentation says:

If digraph was created knowing a subgroup of its automorphism group, then this group is stored in the attribute DigraphGroup. If digraph is not created knowing a subgroup of it automorphism group, then DigraphGroup returns the entire automorphism group of digraph.

However, for a multidigraph, DigraphGroup only returns the projection of the automorphism group that acts on the vertices of the digraph:

gap> gr := Digraph([[2, 2], [1, 1]]);
<multidigraph with 2 vertices, 4 edges>
gap> aut := AutomorphismGroup(gr);
Group([ (1,2), (5,6), (3,4) ])
gap> grp := DigraphGroup(gr);
Group([ (1,2) ])

What should the correct behaviour be?

The following example:

gap> gr := Digraph([[1], [2], [1 .. 3]]);;
gap> IsAntisymmetricDigraph(gr);

causes a segmentation fault in version 0.7.0 (and all previous versions where this function exists).

I am about to commit a pull request which fixes this.

It was reported by Sebastian Gutsche, that if an old version of Digraphs is around and compiled and a newer version is around and not compiled, that Digraphs says that it can't be loaded because the kernel module isn't compiled, but then it loads anyway. We should stop printing in the TestAvailabilty function and instead of using InfoWarning use PACKAGE_WARNING, and/or include the version which cannot be loaded.

We can find out whether a digraph is bipartite, and simultaneously obtain a 2-colouring for a bipartite digraph, by using a depth first search. Doing this would be much faster than the current implementation.

I would be useful to have MutableDigraph which could have IsPositionalObjectRep and not store attributes, because it is common to create a digraph and immediately modify it (remove multiple edges, loops, etc), and this involves unnecessary copying at present since Digraphs are always immutable. As with Issue #88, this would have to be done very carefully to modify the object in-place rather than copy for every operation modifying a digraph.

There is a function at the top of oper.gi called IsSubdigraph. It has the following documentation:

If  super  and  sub are digraphs with the same number of vertices, then this
operation returns true if all the edges of sub are edges in super, and false
otherwise.

Apart from this, IsSubdigraph is not used or mentioned anywhere else in the package. In particular, there is no code coverage, so I thought I'd write some, but I encountered trouble.

I think this documentation is fine if super and sub have no multiple edges. However, I don't think it is specific enough for the cases when there are multiple edges. In my opinion, talking about digraphs in general, which may or may not have multiple edges, the multiplicity of each edge of the subdigraph should be less than or equal to the multiplicity of the edge in the super digraph.

In particular, the method does this (after checking that the numbers of vertices are equal):

  return ForAll(DigraphVertices(super), i ->
                IsSubset(OutNeighboursOfVertex(super, i),
                         OutNeighboursOfVertex(sub, i)));

So (as documented) it is simply checking that for every edge i->j in sub there is an edge i->j in super. When sub is a multidigraph, this leads to behaviour that I think is weird:

gap> super := Digraph([[2], []]);;
gap> sub := Digraph([[2, 2], []]);;
gap> IsSubdigraph(super, sub);
true
gap> IsSubdigraph(sub, super);
true
gap> super = sub;
false

Surely sub should be the "larger" digraph in this case, and surely distinct digraphs shouldn't be subdigraphs of each other!

Does anyone object to me changing the documentation, and the code, so that IsSubdigraph does take account of multiplicities?

I don't think it is sufficiently easy to find out which of the four main digraph encoding formats apply to which kinds of digraphs. I'm talking about (di)sparse6 and (di)graph6. For instance, I naively did the following, expecting it to work:

gap> gr := Digraph([[2, 2], []]);
<multidigraph with 2 vertices, 2 edges>
gap> Digraph6String(gr);
"+AG"
gap> DigraphFromDigraph6String(last) = gr;
false

I got a string from Digraph6String(gr), so why didn't recreating the digraph from the string work? I did ?Digraph6String and got the following documentation, which covers all four of the formats:

These  four functions return a highly compressed string fully describing the
digraph digraph.

Graph6  and  Digraph6  are  formats  best  used  on  small, dense graphs, if
applicable. For larger, sparse graphs use Sparse6 and Disparse6 (this latter
also preserves multiple edges).

See WriteDigraphs (9.2-5).

[Technical note: shouldn't these things be attributes, and described as such, since they don't change?]
[Also, haven't we decided at some point that the names Graph6 and Digraph6 and Sparse6 and Disparse6 are written without capital letters, when they appear as words in the middle of a sentence?]

From reading this, I would interpret the phrase "fully describing the digraph" to mean that each format can completely represent any type of digraph; I got a string representing my digraph gr above, so I would expect it to "fully describe" gr. However the phrase "(this latter also preserves multiple edges)", which comes later, seems confusing in this context, as it implies that some of the formats don't support all digraphs.

There is the final line, which is a direction to look at WriteDigraphs, but it is not clear why this is relevant or what one would expect to find there. I wouldn't expect that that would be the place to find a more detailed description of the formats.

Similarly, doing ?DigraphFromDigraph6String gives me the following:

If  str  is  a  string  encoding  a  graph  in  Graph6, Digraph6, Sparse6 or
DiSparse6  format, then the corresponging function returns a digraph. In the
case  of  either  Graph6  or  Sparse6, formats which do not support directed
edges,  this  will  be a digraph such that for every edge, the edge going in
the opposite direction is also present.

Firstly there's the typo "corresponging", and the same comment about capitalising the formats. There's nothing factually wrong about this paragraph (except possibly the use of the word "graph" in the first sentence), but it's not very helpful, and doesn't tell me what I was doing wrong with my code above.

In both of these pieces of documentation, there's a tiny bit of description about some or all of the formats. If you're going to describe the formats, why not give a proper description, or better yet, refer to a proper, complete, central description.

This isn't meant to be a rant, but I think these encoding/decoding functions are one of the best bits of the package, and I think that they should be as clear and easy to use as possible.

As far as I can tell, these are the limitations of the formats:

• Graph6: can encode any symmetric digraph without loops or multiple edges
• Sparse6: can encode any symmetric digraph
• Digraph6: can encode any digraph without multiple edges
• Disparse6: can encode any digraph

The formats are described in detail at the beginning of chapter 9.2 "Reading and writing graphs to a file", and the formats are described again in the documentation for DigraphFile, ReadDigraphs, and WriteDigraphs (although in these cases, the type of detail given is somewhat different than at the start of chapter 9.2).

Here are my suggestions:

1. There should be a single central description and definition of these four formats. This should probably reside at the start of chapter 9.2, and incorporate the current detail from there, along with any additional detail which is written about the formats in DigraphFile, ReadDigraphs, and WriteDigraphs.

2. Any documentation which talks about these formats should refer the reader to this part of the documentation. This should probably be accomplished by putting it into a subsection and giving it a label, say, "Encoding formats". Then every time the topic comes up, you could say something along the lines of a detailed description of the formats: graph6, digraph6, sparse6, and disparse6, the kinds of digraphs that each format can encode, and their comparative strengths and weaknesses, is given in <Ref Subsect="Encoding formats" Style="Number" />

3. A user should not be able to create an XString from a digraph gr if the format X can not encode gr faithfully. So in my example above, Digraph6String(gr); would have caused an error. Even better, the error message would suggest a more appropriate encoding format to use.

I hope that this issue will form the start of a discussion about how we improve the documentation of these features.

Gordon Royle reports:

d := Digraph([[ 2, 3, 4, 5, 6, 7, 8, 9, 10 ],
[ 22, 1, 13, 14, 15, 16, 19, 20, 21 ],
[ 22, 1, 13, 16, 17, 18, 9, 20, 21 ],
[ 22, 1, 15, 16, 17, 18, 19, 20, 10 ],
[ 17, 1, 18, 19, 21, 22, 8, 10, 12 ],
[ 1, 12, 15, 17, 7, 19, 20, 10, 21 ],
[ 1, 13, 14, 6, 18, 19, 9, 20, 21 ],
[ 22, 1, 13, 14, 5, 16, 18, 19, 9 ],
[ 22, 1, 3, 15, 17, 7, 8, 10, 21 ],
[ 1, 14, 4, 5, 16, 6, 18, 9, 20 ],
[ 22, 12, 13, 15, 17, 18, 19, 20, 21 ],
[ 11, 13, 14, 5, 16, 6, 18, 19, 20 ],
[ 11, 12, 2, 3, 15, 17, 7, 8, 21 ],
[ 22, 12, 2, 15, 7, 8, 19, 10, 21 ],
[ 11, 2, 13, 14, 4, 16, 6, 9, 20 ],
[ 22, 12, 2, 3, 4, 15, 17, 8, 10 ],
[ 11, 13, 3, 4, 5, 16, 6, 18, 9 ],
[ 11, 12, 3, 4, 5, 17, 7, 8, 10 ],
[ 11, 12, 2, 14, 4, 5, 6, 7, 8 ],
[ 11, 12, 2, 3, 4, 15, 6, 7, 10 ],
[ 11, 2, 13, 3, 14, 5, 6, 7, 9 ],
[ 11, 2, 3, 14, 4, 5, 16, 8, 9 ]]);;
HomomorphismDigraphsFinder(d,d,fail,[],1,fail,false,[ 1, 3, 4, 5, 8, 9, 10, 16, 17, 18, 22 ],[],fail,fail);
# returns [ Transformation( [ 1, 3, 4, 3, 8, 10, 4, 5, 10, 9, 8, 5, 22, 17, 9, 17, 16, 22, 18, 1, 16, 18 ] )

But:

gap> Orbit(AutomorphismGroup(d), [ 1, 3, 4, 5, 8, 9, 10, 16, 17, 18, 22 ],OnSets);
[ [ 1, 3, 4, 5, 8, 9, 10, 16, 17, 18, 22 ], [ 2, 6, 7, 11, 12, 13, 14, 15, 19, 20, 21 ] ]
gap> HomomorphismDigraphsFinder(d,d,fail,[],1,fail,false,[ 2, 6, 7, 11, 12, 13, 14, 15, 19, 20, 21 ],[],fail,fail);
[  ]

Another way to see this is that:

dd := InducedSubdigraph(d, [ 2, 6, 7, 11, 12, 13, 14, 15, 19, 20, 21 ]);
t := DigraphHomomorphism(d, dd);
# returns Transformation( [ 1, 6, 10, 9, 11, 9, 7, 6, 8, 7, 10, 2, 8, 11, 4, 5, 2, 3, 3, 5, 1, 4 ] )

Please add subtitle to PackageInfo.g - it is used e.g. for the right column in the list of packages at http://www.gap-system.org/Releases/index.html

https://github.com/gap-packages/Digraphs/blob/92fdc89b7eeff3900fbb042a783f23fc9ed89e67/PackageInfo.g#L23

For a digraph with isolated vertices, the automorphism group tends to be large - since the isolated vertices can be permuted at will. Therefore calculations involving the automorphism group of such digraphs may take longer. However, for cliques, an isolated vertex is only ever in a trivial (maximal) clique - so we really don't need to compute with these at all. (And they're probably not relevant to other computations either). Therefore the clique finder should pre-process a digraph to remove its isolated vertices using ReducedDigraph.

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

While digraphs doesn't require that the neighbours of a vertex be ordered, they often will be in practice. For example:

d := Digraph([2,3],[1,3],[1,2])

however, because GAP doesn't know these things are sets, operations like IsDigraphEdge, which turn into v in OutNeighboursOfVertex(digraph,u) have to do a linear search through the neighbours, when they could do a binary search through an ordered list.

There are other places where the sortedness could be used (= and < on graphs for example), but to start it would be useful to just get GAP to do what it's already good at.

The easiest way to make this happen would be to call IsSet on each member of adjacency list, which makes GAP scan the lists, and mark the as an ordered list if they are. Calling IsSet on a list should make no practical different (you can still edit it, extend it, etc.), but GAP will remember it is a set (until it is altered).

I don't think (but you might disagree!) that doing these IsSet calls during construction would add that much time (it's an O(n) linear scan), but if it is too expensive, you could always add a method to do this. I'm already using one myself:

MakeSety := function(d)
    List(DigraphVertices(d), x -> IsSet(OutNeighboursOfVertex(d, x)));
end;

An example that this is useful.

gap> d := CompleteDigraph(1000);
gap> Sum([1..1000], x-> Length(Filtered([1..1000], y -> IsDigraphEdge(d, x, y))));
999000
gap> time;
1078
gap> MakeSety(d);
gap> time;
2
gap> Sum([1..1000], x-> Length(Filtered([1..1000], y -> IsDigraphEdge(d, x, y))));
999000
gap> time;
712

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/18

Originally reported by: James Mitchell (Bitbucket: james-d-mitchell, GitHub: james-d-mitchell)

I got this:

#!GAP

gap> WriteDigraphs("/Users/jdm/Desktop/dag7c.txt.gz", graphs);
#I  Writing to /Users/jdm/Desktop/dag6c.t7t.d6.gz

Something looks like it got mangled in the renaming of the file.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/5

The following happens, despite the digraphs.so file is there:

gap> LoadPackage("dig");
───────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  orb 4.7.6 (Methods to enumerate orbits)
by Juergen Mueller (http://www.math.rwth-aachen.de/~Juergen.Mueller),
   Max Neunhöffer (http://www-groups.mcs.st-and.ac.uk/~neunhoef), and
   Felix Noeske (http://www.math.rwth-aachen.de/~Felix.Noeske).
Homepage: https://gap-packages.github.io/orb
───────────────────────────────────────────────────────────────────────────────────────────────────────────────
───────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  GRAPE 4.7 (GRaph Algorithms using PErmutation groups)
by Leonard H. Soicher (http://www.maths.qmul.ac.uk/~leonard/).
Homepage: http://www.maths.qmul.ac.uk/~leonard/grape/
───────────────────────────────────────────────────────────────────────────────────────────────────────────────
#W dlopen() error: No such file or directory
Error, module '/proc/cygdrive/C/gap4r8p8test/pkg/digraphs-0.10.1/bin/i686-pc-cygwin-gcc-default32/digraphs.so' not foun\
d in
  if not LOAD_DYN( arg[1], false )  then
    Error( "no support for dynamic loading" );
fi; at /proc/cygdrive/C/gap4r8p8test/lib/files.gd:579 called from
<function "LoadDynamicModule">( <arguments> )
 called from read-eval loop at line 25 of /proc/cygdrive/C/gap4r8p8test/pkg/digraphs-0.10.1/init.g
Error, was not in any namespace called from
LEAVE_NAMESPACE(  ); at /proc/cygdrive/C/gap4r8p8test/lib/package.gi:1212 called from
ReadPackage( pkgname, "init.g" ); at /proc/cygdrive/C/gap4r8p8test/lib/package.gi:1585 called from
<function "LoadPackage">( <arguments> )
 called from read-eval loop at line 1 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 

DigraphGroup should be able to extract from bliss the size of the found group, and attach it to the group. This information would be very useful, as I have a group where DigraphGroup took 3 seconds, but Size is still not finished, and has taken over 10 minutes.

It is currently not possible to run EquivalenceRelationLookup not MeetSemigroupCongruences for all types of congruences over a semigroup. I will post an example later when I have more time.

Originally reported by: Christopher Jefferson (Bitbucket: ChrisJefferson, GitHub: ChrisJefferson)

The 'make doc' target in the Makefile tries to run makedoc.g, which doesn't exist.

I would recommend (in order of ease), one of the following changes to Makefile.in.

1. Just remove the 'doc' and 'doc/manual.six' targets
2. Replace them with something like:

.PHONY: doc

doc:
(echo 'LoadPackage("digraphs"); DigraphsMakeDoc();' | $(GAPROOT)/bin/gap.sh -A)

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/16

Originally reported by: Jan De Beule (Bitbucket: jdebeule, GitHub: jdebeule)

The file "bdhexagon.p.gz" contains a digraph on 252 vertices (with 756 edges). It is the bipartite double of the incidence graph of the smallest generalized hexagon.

Computing the full automorphism group of this digraph causes a fatal bliss error.

Converting this digraph to a grape graph, and computing the full automorphism group, works fine. The resulting group has order 292626432.

#!GAP

gap> digraph := ReadDigraphs("bdhexagon.p.gz")[1];;
gap> AutomorphismGroup(digraph);
Bliss fatal error: src/bliss-0.73/graph.cc:1382: internal error
Aborting!

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/10

Originally reported by: Anonymous

A test comparing the construction of a graph on 8704 vertices is submitted. The test first constructs the graph in grape and digraph without using the group. Then digraph is faster. Then we use a group, and grape turns out to be much faster. Furthermore, an operation like Diameter becomes feasible to compute on the grape-graph constructed with the group

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/7

Originally reported by: James Mitchell (Bitbucket: james-d-mitchell, GitHub: james-d-mitchell)

In 0.4.1, I get:

#!GAP

gap> digraph := Digraph( [ [ 3 ], [ 4 ], [ 5 ], [ 1, 5 ], [ 1, 2 ] ] );;
gap> DigraphAllSimpleCircuits(digraph);
[ [ 1, 3, 5 ], [ 1, 3, 5, 2, 4 ] ]

But looking at the picture of this digraph (below), it looks to me like [5, 2, 4] should also be returned by DigraphAllSimpleCircuits.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/13

Originally reported by: Jan De Beule (Bitbucket: jdebeule, GitHub: jdebeule)

The graph in the example is a bipartite graph.

gap> digraph := ReadDigraphs("example.p.gz")[1];
<digraph with 30 vertices, 90 edges>
gap> DigraphShortestDistance(digraph,1,16);  
3
gap> OutNeighbours(digraph)[1];
[ 16, 18, 25 ]

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/12

Originally reported by: Finn Smith (Bitbucket: flsmith, GitHub: flsmith)

I might have misunderstood the point behind this function, but I'm confused by the example that is given in the manual

#!GAP

gap> G := Digraph(10, [1, 1, 3, 4, 4, 5, 8, 8], [6, 3, 3, 9, 10, 9, 4, 10]);
<digraph with 10 vertices, 8 edges>

gap> DigraphCanonicalLabelling(G, [1, 1, 1, 1, 2, 3, 1, 3, 2, 1]);
(1,4,5,7)(3,6,9,8,10)

I can't see in what sense this result respects colouring.

In the different encoding of coloured digraphs I have, I get a different result... which also seems not to respect colouring.

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/19

It would be nice to have different AutomorphismGroup algorithms play against each other. The NautyTracesInterface package aims to provide a C-level-link to nauty and traces.

It would be nice to have digraphs work with this, to see how the different algorithms work with each other.

The method for creating a digraph from a transformation is flawed.

Here is the documentation:

  If  trans  is  a  transformation  and n is a non-negative integer, then this
  function  returns  the  functional digraph with n vertices defined by trans.
  Specifically, the graph has n edges: for each  vertex  x,  there  is a unique
  edge with source x; this edge has range x^trans.

  If  the  optional  second argument n is not supplied, then the degree of the
  transformation trans is used by default.

When n is chosen to be the degree of the transformation, or anything higher than that, then all is fine. The problem occurs when n is less than the degree. Unless the restriction of trans to [1 .. n] happens to be a transformation of [1 .. n], then AsDigraph returns a corrupt digraph.

Here is the example from the documentation:

gap> f := Transformation([7, 10, 10, 1, 7, 9, 10, 4, 2, 3]);
Transformation( [ 7, 10, 10, 1, 7, 9, 10, 4, 2, 3 ] )
gap> AsDigraph(f); 
<digraph with 10 vertices, 10 edges>
gap> AsDigraph(f, 4); 
<digraph with 4 vertices, 4 edges>

The first digraph is fine. However, look at the out-neighbours of the second digraph:

gap> OutNeighbours(AsDigraph(f, 4));
[ [ 7 ], [ 10 ], [ 10 ], [ 1 ] ]

This is not right, and it's because the transformation does not map the numbers [1 .. 4] back to themselves. (And obviously AsDigraphs is using DigraphNC). If we discard the edges which go to a number higher than 4, then we don't get a functional digraph. So really there's not a sensible way of representing this transformation by a digraph with 4 vertices.

Suggestions

I suggest that the optional second argument should not be allowed to be smaller than the degree. That would allow the second argument to be greater than or equal to the degree. I then don't see the reason for keeping the second argument at all, since a transformation acts as the identity on any point higher than the degree - not very interesting. But I wouldn't complain about its continued inclusion.

As a side note, this same bug is present in the Semigroups package in unstable-3.0 in @james-d-mitchell's function DigraphOfActionOnPoints, when the optional second argument is too small - and the same idea is relevant to my function DigraphOfActionOnPairs which I'm writing.

gap> OutNeighbours(DigraphOfActionOnPoints(FullTransformationMonoid(2), 1));
[ [ 1, 2 ] ]

@James-Mitchell I am working on gap-system/gap#2119 and there is a problem with Digraphs build there built with bin/BuildPackages.sh in stable-4.9 branch. Build goes well, but loading (with GAP's stable-4.9 branch) fails:

#W dlopen() error: /home/travis/build/gap-system/gap/pkg/digraphs-0.11.0/bin/x\
86_64-pc-linux-gnu-default64/digraphs.so: undefined symbol: atexit
Error, module '/home/travis/build/gap-system/gap/pkg/digraphs-0.11.0/bin/x86_64-pc-li\
nux-gnu-default64/digraphs.so' not found in
  if not LOAD_DYN( arg[1], false ) then
    Error( "no support for dynamic loading" );
fi; at /home/travis/build/gap-system/gap/lib/files.gd:583  

On an up-to-date Debian Testing distribution, something is going wrong with loading the Digraphs package. Everything appears to be okay during the build, but when I open GAP and try to load Digraphs, I get the following:

[14:04:19] ~/newgap/gap $ bin/gap.sh
 ┌───────┐   GAP v4.8.6-844-g2131b73 of 2016-11-14 13:17:36 (GMT)
 │  GAP  │   http://www.gap-system.org
 └───────┘   Architecture: x86_64-pc-linux-gnu-gcc-default64
 Libs used:  gmp
 Loading the library and packages ...
 Components: trans 1.0, prim 3.0, small* 1.0, id* 1.0
 Packages:   GAPDoc 1.5.1, IO 4.4.6
 Try '??help' for help. See also '?copyright', '?cite' and '?authors'
gap> LoadPackage("digraphs");
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  orb 4.7.6 (Methods to enumerate orbits)
by Juergen Mueller (http://www.math.rwth-aachen.de/~Juergen.Mueller),
   Max Neunhöffer (http://www-groups.mcs.st-and.ac.uk/~neunhoef), and
   Felix Noeske (http://www.math.rwth-aachen.de/~Felix.Noeske).
Homepage: https://gap-packages.github.io/orb
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Loading  GRAPE 4.7 (GRaph Algorithms using PErmutation groups)
by Leonard H. Soicher (http://www.maths.qmul.ac.uk/~leonard/).
Homepage: http://www.maths.qmul.ac.uk/~leonard/grape/
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
#W dlopen() error: /home/mtorpey/newgap/gap/pkg/digraphs/bin/x86_64-pc-linux-gnu-gcc-default64/digraphs.so: undefined symbol\
: _ZTVN10__cxxabiv117__class_type_infoE
Error, module '/home/mtorpey/newgap/gap/pkg/digraphs/bin/x86_64-pc-linux-gnu-gcc-default64/digraphs.so' not found in
  if not LOAD_DYN( arg[1], false )  then
    Error( "no support for dynamic loading" );
fi; at /home/mtorpey/newgap/gap/lib/files.gd:579 called from 
<function "LoadDynamicModule">( <arguments> )
 called from read-eval loop at /home/mtorpey/newgap/gap/pkg/digraphs/init.g:25
Error, was not in any namespace at /home/mtorpey/newgap/gap/lib/variable.g:282 called from
LEAVE_NAMESPACE(  ); at /home/mtorpey/newgap/gap/lib/package.gi:1212 called from
ReadPackage( pkgname, "init.g" ); at /home/mtorpey/newgap/gap/lib/package.gi:1585 called from
<function "LoadPackage">( <arguments> )
 called from read-eval loop at *stdin*:1
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue
brk> 

I've reproduced this in a variety of setups (indeed, I can't find a setup that allows it to work), varying the following:

• Compiler: this issue occurs for gcc 6.2.0 and clang 3.8.1
• Version of GAP: this issue occurs for the released version of GAP 4.8.5, and for stable-4.8
• Version of Digraphs: this issue occurs for the released version 0.5.2, and for stable-0.6

It looks like it's something to do with dynamic linking, but I don't know enough to be able to diagnose anything further.

Originally reported by: Alexander Konovalov (Bitbucket: alex_konovalov, GitHub: Unknown)

This is what's happening:

+ cd digraphs-0.4.2
+ ./configure CFLAGS=-m32
checking build system type... x86_64-apple-darwin14.5.0
checking host system type... x86_64-apple-darwin14.5.0
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... cnf/install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm
checking the name lister (/usr/bin/nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 196608
checking how to convert x86_64-apple-darwin14.5.0 file names to x86_64-apple-darwin14.5.0 format... func_convert_file_noop
checking how to convert x86_64-apple-darwin14.5.0 file names to toolchain format... func_convert_file_noop
checking for /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld option to reload object files... -r
checking for objdump... no
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm output from gcc object... ok
checking for sysroot... no
checking for a working dd... /bin/dd
checking how to truncate binary pipes... /bin/dd bs=4096 count=1
checking for mt... no
checking if : is a manifest tool... no
checking for dsymutil... dsymutil
checking for nmedit... nmedit
checking for lipo... lipo
checking for otool... otool
checking for otool64... no
checking for -single_module linker flag... yes
checking for -exported_symbols_list linker flag... yes
checking for -force_load linker flag... yes
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking for gcc option to produce PIC... -fno-common -DPIC
checking if gcc PIC flag -fno-common -DPIC works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin14.5.0 dyld
checking how to hardcode library paths into programs... immediate
checking for dlopen in -ldl... yes
checking whether a program can dlopen itself... yes
checking whether a statically linked program can dlopen itself... yes
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld
checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fno-common -DPIC
checking if g++ PIC flag -fno-common -DPIC works... yes
checking if g++ static flag -static works... no
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... darwin14.5.0 dyld
checking how to hardcode library paths into programs... immediate
checking for CONFIGNAME... none
checking for GAP root directory... /Volumes/hudson-fs/workspace/GAP-dev/GAPCOPTS/32build/GAPGMP/gmp/GAPTARGET/install/label/fruitloop/GAP-git-snapshot
checking for GAP architecture... x86_64-apple-darwin14.5.0-gcc-default32
checking for GAP include files... /Volumes/hudson-fs/workspace/GAP-dev/GAPCOPTS/32build/GAPGMP/gmp/GAPTARGET/install/label/fruitloop/GAP-git-snapshot/src/compiled.h
checking for GAP config.h... /Volumes/hudson-fs/workspace/GAP-dev/GAPCOPTS/32build/GAPGMP/gmp/GAPTARGET/install/label/fruitloop/GAP-git-snapshot/bin/x86_64-apple-darwin14.5.0-gcc-default32/config.h
checking for GAP's gmp.h location... /Volumes/hudson-fs/workspace/GAP-dev/GAPCOPTS/32build/GAPGMP/gmp/GAPTARGET/install/label/fruitloop/GAP-git-snapshot/bin/x86_64-apple-darwin14.5.0-gcc-default32/extern/gmp/include/gmp.h
checking size of void **... 8
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating src/pkgconfig.h
config.status: executing depfiles commands
config.status: executing libtool commands
+ make
  CC       src/digraphs_la-digraphs.lo
  CC       src/digraphs_la-homos.lo
  CC       src/digraphs_la-perms.lo
  CC       src/digraphs_la-schreier-sims.lo
  CXX      src/bliss-0.73/digraphs_la-defs.lo
  CXX      src/bliss-0.73/digraphs_la-graph.lo
  CXX      src/bliss-0.73/digraphs_la-partition.lo
  CXX      src/bliss-0.73/digraphs_la-orbit.lo
  CXX      src/bliss-0.73/digraphs_la-uintseqhash.lo
  CXX      src/bliss-0.73/digraphs_la-heap.lo
  CXX      src/bliss-0.73/digraphs_la-timer.lo
  CXX      src/bliss-0.73/digraphs_la-utils.lo
  CXX      src/bliss-0.73/digraphs_la-bliss_C.lo
  CXXLD    digraphs.la
ld: warning: ld: warning: ignoring file src/.libs/digraphs_la-digraphs.o, file was built for i386 which is not the architecture being linked (x86_64): src/.libs/digraphs_la-digraphs.oignoring file src/.libs/digraphs_la-homos.o, file was built for i386 which is not the architecture being linked (x86_64): src/.libs/digraphs_la-homos.o

ld: warning: ignoring file src/.libs/digraphs_la-perms.o, file was built for i386 which is not the architecture being linked (x86_64): src/.libs/digraphs_la-perms.o
ld: warning: ignoring file src/.libs/digraphs_la-schreier-sims.o, file was built for i386 which is not the architecture being linked (x86_64): src/.libs/digraphs_la-schreier-sims.o
cnf/install-sh -c -d ./bin/x86_64-apple-darwin14.5.0-gcc-default32
cp .libs/digraphs.so /Volumes/hudson-fs/workspace/GAP-dev/GAPCOPTS/32build/GAPGMP/gmp/GAPTARGET/install/label/fruitloop/GAP-git-snapshot/pkg/digraphs-0.4.2/bin/x86_64-apple-darwin14.5.0-gcc-default32/digraphs.so
SUCCESS!

• Bitbucket: https://bitbucket.org/james-d-mitchell/digraphs/issue/14