[great-users] FW: Visual Studio project Templates and group operator bug

[Simon Görke]

Kevin,

Thanks for the quick response. I will check the fixed version tomorrow 
and report back.

There is another question which resulted from last nights' Jenkins runs: 
we do not only compile the rules, but also run the transformations using 
the resulting binaries. Supervising this execution as a whole is no 
problem.
However last night, an udm exception occured (meta model changed => rule 
tried to set an attribute to an invalid enum value), and those are 
difficult to catch automatically as they do not result in an returncode 
!= 0. Parsing the output (which could be principally done by Jenkin's 
log parser) is difficult because each exception has its own individual 
message.
I fear this is only relevant for our special use case, but do you think 
it would it be possible to add a uniform prefix to the printout of the 
udm exceptions (e.g. "UDM Exception: ...")?

Simon


Am 15.10.2014 um 17:43 schrieb Kevin Smyth:
> 1. Unfortunately, the templates for the input to the tool that produces
> the .vcproj are embedded as resources in the GReAT executables. So it is
> not easy for end users to modify them. But I will add /bigobj and /MP to
> the templates. I'll think about adding a more general solution. Maybe we
> should add an attribute to UserCodeLibrary where you can specify a
> .props file (or the VS2008 equivalent).
>
> 2. I agree these are bugs, and I will fix them. The component
> responsible for this behavior is the add-on "UMTHelper", not the decorator.
>
> The new behavior for connecting a Group: if you add a connection, it
> will not be immediately deleted (like it was trying to do), but if you
> modify the Group's GroupAction, it will delete the connection if the
> action is Bound or Delete. I believe this is the desired behavior, but
> if you think it should do something else, please let me know.
>
> The crash is a bug in GME that I will fix, but the crash will not be
> triggered after the changes to the GReAT addon.
>
>
> Thanks for the good bug reports.
>
> Kevin
>
> On 10/15/2014 9:21 AM, Daniel Balasubramanian wrote:
>>
>> -----Original Message-----
>> From: Simon Görke [mailto:simon.goerke at ils.uni-stuttgart.de]
>> Sent: Wednesday, October 15, 2014 7:58 AM
>> To: great-users-bounces at list.isis.vanderbilt.edu
>> Subject: Visual Studio project Templates and group operator bug
>>
>> Hi everybody,
>>
>> I would like to report two minor GreAt issues. Both can be avoided,
>> however they unnececessarily complicate our every-day work with the tool.
>>
>> 1. Visual Studio project files (*.vcproj):
>> With one of our rules, VS requires us to set the /bigobj switch for
>> successful compilation (background:
>> http://msdn.microsoft.com/de-de/library/ms173499.aspx).
>> The VS projects generated by GreAt do not set this switch, so we have
>> to set it manually after each generation. Consequently, we can not
>> make the build process for this rule part of our continuous
>> integration environment (Jenkins).
>> Would it be possible to set the option in the GreAt-internal template?
>> As far as we know, there are no negative implications apart from
>> missing VS2005 compatibility (which is not supported by GreAt anyway?).
>> As a nice-to-have, compilation time could be widely reduced by
>> enabling the multi-processor switch (/MP) in the VS-project (currently
>> a complete rebuild takes ~45min with 3 of 4 cores idling... I do not
>> know about VS-backwards compatibility here however).
>>
>> 2. Some of our rules make have use of the group operator. There are
>> two bugs in the GreAt decorator which - I hope - could be easily
>> fixed, but sometimes make modelling a pain:
>>   1st, when copying a rule containing a group operator, the "criteria
>> for grouping"-attribute is lost, i.e. it is not copied, but set to
>> default. As the default text contains an unconditioned positive return
>> instruction, this causes misbehaviour which can not be detected at
>> compile time.
>> This problem seems to be a regression as older versions (which did not
>> fill in default code) did not show this behavior.
>> The 2nd thing is also connected to the decorator: when drawing a
>> connection from a group to another FCO (for copy / move), GME crashes
>> if the GroupAction-attribute is set to "bound". This is especially
>> annoying, as the latter is the default value -> one has to strictly
>> follow the sequence "create group", "modify attribute", "connect" (and
>> not reverse).
>>
>> It would be nice if someone could give as a hand here. I tried to fix
>> the first one on my own, but did not find the vcproj template within
>> the GreAt sources.
>> If generally setting the flags is not an option, maybe you could point
>> me to the right spots in the code and help me build our individual
>> GreAt version.
>>
>> Thanks in advance,
>> Simon
>>
>>
>> _________________________________________
>>
>> Dr.-Ing. Simon Görke
>> Institut für Luftfahrtsysteme (ILS)
>> Universität Stuttgart
>> Pfaffenwaldring 31
>> 70569 Stuttgart (Vaihingen)
>> Tel.: +49 (0)711 685-64715
>> Fax: +49 (0)711 685-63591
>> Email: simon.goerke at ils.uni-stuttgart.de
>> URL: http://www.ils.uni-stuttgart.de
>>
>>
>
>