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

[Simon Görke]

Hi Kevin,

all your fixes worked as expected. Great.

Regarding the exception / return code issue: I manually added your code
snippet to our rules and this works perfectly fine (i.e. exceptions are
caught be Jenkins as required). 
It would be really nice if this could be included in the next release.

Thanks again,
Simon


-----Ursprüngliche Nachricht-----
Von: great-users-bounces at list.isis.vanderbilt.edu
[mailto:great-users-bounces at list.isis.vanderbilt.edu] Im Auftrag von Kevin
Smyth
Gesendet: Mittwoch, 15. Oktober 2014 20:18
An: A list for GReAT users to share bugs, fixes and ideas
Betreff: Re: [great-users] FW: Visual Studio project Templates and group
operator bug

Hi Simon,

As I understand it, changing the GReAT code generator to put this at the end
of _main.cpp would address this issue:
{
     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

_______________________________________________
great-users mailing list
great-users at list.isis.vanderbilt.edu
http://list.isis.vanderbilt.edu/mailman/listinfo/great-users