| Re: [elk-dev] The new ElkGraph |
Greetings Miro,
one of our students is currently in the process of developing a proper
test framework. Adding a few helper methods shouldn't be a problem.
Cheers,
Christoph Daniel
On 16/11/16 08:42, Miro Spönemann wrote:
> Hi,
>
> just a thought that I had yesterday: once we have the new graph and its
> textual (Xtext based) format in place, we could make a testing
> infrastructure that allows to write very compact tests using Xtend. I
> sketched an example to illustrate the idea:
>
> @Test
> def void testSimpleLayering() {
> valgraph = parse(‘''
> algorithm = org.eclipse.elk.layered
> direction = right
> node n1
> node n2
> edge n1 -> n2
> ''')
> graph.layout()
> val n1 = graph.getNode('n1')
> val n2 = graph.getNode('n2')
> assertTrue(n1.x < n2.x)
> }
>
> The utility method parse would use the Xtext / Antlr parser to get an
> ElkGraph instance. The extension method layout would invoke the graph
> layout engine. Using getNode one could retrieve the node with a certain
> ID. As an alternative, this should also work:
>
> val graph = parse('''
> node n1
> node n2
> edge n1 -> n2
> ''')
> graph.layout(#{
> CoreOptions.ALGORITHM -> 'org.eclipse.elk.layered',
> CoreOptions.DIRECTION -> Direction.RIGHT
> })
>
> Here the argument of layout is a map literal using the Xtend syntax. The
> given option mapping would be applied to all appropriate elements in the
> graph prior to invoking the layout.
>
> This could help in building a good test base, which I believe is one of
> the most important things the ELK needs at the moment.
>
> Miro
>
>
>> On 15 Nov 2016, at 16:36, Christoph Daniel Schulze
>> <cds@xxxxxxxxxxxxxxxxxxxxxx <mailto:cds@xxxxxxxxxxxxxxxxxxxxxx>> wrote:
>>
>> Greeting, fellow ELK developers!
>>
>> The new ELkGraph is pretty much done and everything is migrated (see the
>> cds/realelkgraph branch). "Everything is migrated" in this context means
>> "everything compiles". I do expect the results to be full of strange
>> coordinate conversion bugs, which is why I have not merged the branch
>> onto master yet.
>>
>> Before we can track down the bugs, we need something to track them down
>> with. This is why my attention will now shift to KIELER Pragmatics: once
>> KLighD works with the new graph, we can start finding and fixing bugs. I
>> expect KLighD to work with the new ELK Graph by the end of the week, so
>> I guess we can start fixing bugs starting next week.
>>
>> Once everything has settled down a bit, there are two things left to be
>> done:
>>
>> 1. Migrate some of the basic math data structures to the elk.graph
>> plug-in.
>>
>> 2. Investigate if we can get rid of persistent entries. I expect that we
>> need to give the graph plug-in access to some sort of a mechanism for
>> properly deserialising layout options, something that we currently do in
>> the core ELK plug-in.
>>
>> Comments and suggestions welcome!
>>
>> Cheers,
>> Christoph Daniel
>>
>>
>> _______________________________________________
>> elk-dev mailing list
>> elk-dev@xxxxxxxxxxx <mailto:elk-dev@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/elk-dev
>
> --
> Dr. Miro Spönemann
> Software engineer and consultant
>
> TypeFox GmbH
> Am Germaniahafen 1, 24143 Kiel
>
> http://typefox.io
> Tel.: +49 151 42679459
>
> Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385
> Geschäftsführer: Sven Efftinge, Dr. Jan Köhnlein, Moritz Eysholdt
>
>
>
> _______________________________________________
> elk-dev mailing list
> elk-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/elk-dev
>
Attachment:
signature.asc
Description: OpenPGP digital signature