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

[Kevin Smyth]

Hi Simon,

As I understand it, changing the GReAT code generator to put this at the 
end of _main.cpp would address this issue:
catch( udm_exception &e)
{
     cout << "Udm exception: " << e.what() << endl;
     return 2;
}

I'll make that change for the next GReAT release.

Kevin


On 10/15/2014 11:53 AM, Simon Görke wrote:
> 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
>>>
>>>
>>
> _______________________________________________
> great-users mailing list
> great-users at list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/great-users