Separate compiled code: possible regression in LabVIEW 2012?

[CharlesB64]

I'm posting here since it's most likely to have an audience  that use source control for their LabVIEW projects.

My project is source controlled, and since 2 years all VIs and CTLs have separate object code to minimize the number of changed file at each commit. This was a huge improvement for me not to have tons of VIs modified when I changed a typo in a typedef.

Now, I upgraded to LabVIEW 2012 in september and some time ago I realized this: if I change a typedef (for example add another control to a typedefed cluster), the VIs that use it will be saved again. This is a regression since in LV 2011 it's not the case.

Realizing this I downgraded to LV2011 (I had to replay all my commits made under 2012, tough stuff!). I'm wondering if there's a reason for this, or is it just a bug?

I attached a sample project that has a typedef'ed cluster used in two VIs. The project is saved both in 2011 and 2012 formats.

To reproduce the problem, simply add a control to the cluster. In LV 2011, the VIs are left unmodified. However in 2012 they show as modified when you open them, and saving them make them look modified in source control

Thanks a lot for any comments on this!

[Elijah_K]

Looking into it... thanks for bringing this to my attention.  I'll see what I can find out and I'll post shotly.

Eli

[Elijah_K · Accepted solution]

What you've discovered was an intentional change that was made specifically for typedefs in LabVIEW 2012.  This change was made to address a rather serious issue with typedefs that occured when multiple revisions were made to the typedef without callers being loaded.  This could lead to lost changes to the typedef, among other problems.

R&D determined that the best way to avoid these issues was to require that calling VIs be loaded and saved.  This is the expected behavior in LabVIEW moving forward.

Sorry I don't have better news - will you be willing / able to upgrade 2012?  Keep in mind that you may run into the issue described above in 2011,

Eli

[TurboPhil]

Eli--

So that's it, there's no plan for improving that behavior moving forward? Seems like a sub-optimal fix to the (admittedly critical) problem. Has there been any thought to including version numbering or something similar with the typedef to ensure changes are correctly propagated (like backwards-compatibility with objects)?

Also, given this behavior, is there any benefit in separating compiled code for *.ctl files at all?

[vishots.com]

That's dissapointing to hear. Typedef propogation changes is a plague that I hoped would be gone for good with the compile code seperation feature.

[Elijah_K]

I agree that it is a sub-obtimal solution. I already plan to regroup with the appropriate internal stakeholders to discuss this further.  I'll update this thread with info as it becomes available.

[TurboPhil]

Any thoughts on separating compiled code for *.ctl files? Is that still recommended? And if so, can you explain what it buys us?

[MikaelH]

I'm happy to hear that this bug is fixed in LV2012, since I got hit severely by this bug, I've never dared to separate the compiled code again.
But now I might try it again.

[CharlesB64]

Thanks Eli for this explanation. I'm staying away from 2012 because of this, it's too important for me to have clean commit history. If a VI is modified in a commit, it's because the code in this VI has changed, not because a dependancy has changed.

I put too much value in the list of changed files of a commit, it brings essential info on what happened. If it's cluttered with dependencies change this info disappears.

This is also important  when tracking a VI's history: I want to see only commits that changed VI's code to have insights on what can happen through the time.

I've been also hit several times by side effects of the problem you mention: unbundle entries that are modified, and behaviour is changed.  Also typedef constants that gets re-initialized to their default value without warning.  Not really acceptable. I'm aware of this and it's good it has been had to be taken into account.

But I believe it could be better handled, at least with a dialog listing the VIs that use the typedef. Better detection of these side effects, would be perfect, in order to list only really affected VIs, since many times a typedef is referenced in VI's connector but not used in its code.

Keep in mind that you may run into the issue described above in 2011,

Oh, thanks for the warning, but I'm OK since I have now unit tests with 100% code coverage! 

...Nah it's just a dream.

[danny_t]

I have not yet moved up to LabVIEW 2012, but have share similar concerns with Charles in terms of a commit to a source code control tools should be recording changes actually made to code.

It is slightly ironic that those who follow good coding practice and use TypeDef's a lot to make well structure code that is maintainable will suffer the most.