Fixed a bug where internals would not be parsed by Workcraft

[snowleopard]

Thanks! That's what I hit during my demo in Tokyo :)

[jrbeaumont]

Oh I see. I can't believe I missed it before. I noticed it now, while doing some over the top testing of the concepts layout (now implemented)

[snowleopard]

@jrbeaumont Is it possible to add some tests, to make sure future commits do not break the conversion algorithm (testing that it correctly handles input, internal and output signals, as well as OR-causality)?

[jrbeaumont]

I'm sure it is, but we would need to test against an expected .g file, which may be large. Do you know of a smoother way to do it?

[snowleopard]

I think if you split the test into multiple smaller independent pieces, it will work well:

• Test that you produce a correct .g contents for a simple example with 1 input, 1 internal and 1 output signal, and no causality (i.e. compare the resulting String, without actually writing a file).
• Test the list of arcs produced for a concept involving a handshake (without even converting it into a String representation).
• Test the list of arcs produced for an OR gate.
• ... plus 2-3 other simple tests like this.

[jrbeaumont]

Ok, that sounds reasonable. I will make a start and think on some more simple tests. Possibly something where we use 2 different concept descriptions to produce the same output, as with a cElement.

[snowleopard]

@jrbeaumont Ah, good idea! Such a test could look like:

testCElement = c1 == c2
  where
    c1 == cElement a b c
    c2 == buffer a c <> buffer b c

[snowleopard]

You may need to implement an Eq instance for STG concepts, that would sort the list of arcs before doing the comparison.