Problem to Solve

At the moment Grakn user of the Docker container may not know how to capture logs from inside a running docker container - especially important when the run has failed.

Current Workaround

There may not be a clean one, but in a case, we could log into the docker container:

$ docker exec -it [container id] /bin/bash
$ cd /path/to/logs
$ [some how upload via 

I didn't see a board or community to ask such things, so I'll mention it here: there doesn't seem to be a guide specifically for more in depth commands in console window.

Is this something that's planned?

I'm loving the rest of the software, and will help me visualize.

There are a bunch of links to the theory of NARs in the readme that link to a google site that is gone:
All links starting with: https://sites.google.com/site/narswang/

As an example, we should unparse:

(lambda [x A]
  (lambda [y A]
     (lambda [z A]
        e)))

as:

(lambda [x y z A] e)

(that kind of shortcut presentation is the whole purpose of the unparser)

Consider changing warnings "found topics with non-existent parents"
into errors, just as we already treat broken links as errors. A
simple fix might be to replace the following code in the definition of
function save-json-files, in file books/xdoc/save-fancy.lisp.

    (or (not orphans)
        (cw "~|~%WARNING: found topics with non-existent parents:~%~x0~%These ~

Missing things:

• <p> tags to delimit paragraphs
• Proper quotes “” and apostrophe ’ (instead of inch " and feet ' symbols)
• <code> tags around strings like node names
• Links between related items (impossible with the current overscripted website structure)
• Non-breaking spaces, where appropriate (e.g. after “a”)

Hello, I know this is probably an inappropriate place to ask,
but I'm struggling to build this project with visual studio cmake.

Could you maybe include a small tutorial how to do it from start to finish, @aljen?
That would be great so I could finally tinker with your marvellous creation.

Right now, we restrict grammar to disallow statements such as match $x; get. When building with graql, this is still allowed (Graql.match(var("x")).get()) when it should not be.

Further restrictions are currently built into Grakn's match clause validation at runtime, but not checked elsewhere - such as match $x != $y; get; which does a n^2 scan of the database. We could push this into Gra