LabVIEW Development Best Practices Discussions

cancel
Showing results for 
Search instead for 
Did you mean: 

Update on typedef triggering re-compilation in LV2012

Solved!
Go to solution

David/jlokanis:

Huh? I have tons of projects in SCC, and pretty much all of my development in LVOOP. The level of file change with classes is drastically lower than with typedefs. Multiple orders of magnitude. Under what circumstances would LVOOP make you give up on SCC? If you were ok with the level of churn without classes, you should've been thrilled with the substantially lower churn with classes. If you couple that with enabling "Separate compiled code from source file", you're very low. It goes to hell when you have typedefs involved because typedefs insert their data space into the callers (one of the problems of public data).

If you were part of a larger dev team, there's integration problems with LV classes -- the embedded private data control prevents diffing. But you're both mostly lone developers. What in the world are you seeing? Classes are really good at only putting docmods on files that really did have to get touched (mostly limited to the members of the class). If you aren't checking in the files that get docmoded when you modify a class then you're taking the recompile hit every time you load (which is why the "Separate compiled code from source file" option is so nice for classes).

There's a lot of complaints I hear about classes that I acknowledge. This is one where I usually hear praise. As such, I'm surprised.

-- AQ

0 Kudos
Message 11 of 44
(1,256 Views)

AristosQueue wrote:

David/jlokanis:

Huh?

Any concrete bugs I could have reported about LVOOP are left in LV 2011. I stopped using libraries and classes (except when required by the demand for scoping VIs or dynamic dispatch) shortly after the upgrade to 2012.

If you were part of a larger dev team, there's integration problems with LV classes -- the embedded private data control prevents diffing. But you're both mostly lone developers.

For the record, I'm leading three teams on three different projects now. Staab Engineering has not sat idle.

---------------

I still avoid classes in LV 2013 because of annoyances related to strong type definition, creating/editing/linking them through a series of dialogs and context menus, the difficulty of creating and maintaining unit tests for them, and limited debugging tools for shared reentrant VIs. They inhibit my ability to create and test well-designed code quickly, instead of enhancing it.

0 Kudos
Message 12 of 44
(1,256 Views)

David Staab wrote:

For the record, I'm leading three teams on three different projects now. Staab Engineering has not sat idle.

And last we spoke, each of those projects was a single developer that you're managing. I hadn't heard that they'd expanded. Congrats.

David Staab wrote:

I still avoid classes in LV 2013 because of annoyances related to strong type definition, creating/editing/linking them through a series of dialogs and context menus, the difficulty of creating and maintaining unit tests for them, and limited debugging tools for shared reentrant VIs. They inhibit my ability to create and test well-designed code quickly, instead of enhancing it.

Ok, those are all fine complaints or reasonable opinions (well, except for the reentrant VI complaint -- that impacts all of LV so isn't a reason to drop LVOOP unless you're also dropping LV). You said earlier that problems between classes and SCC was your reason for dropping. That caught my attention.

0 Kudos
Message 13 of 44
(1,256 Views)

AristosQueue wrote:

Ok, those are all fine complaints or reasonable opinions (well, except for the reentrant VI complaint -- that impacts all of LV so isn't a reason to drop LVOOP unless you're also dropping LV). You said earlier that problems between classes and SCC was your reason for dropping. That caught my attention.

LVOOP + SCC was the cause of many bugs, regressions, and general weirdness in LV 2011. That was the straw that broke my back. I haven't gone back since because although many of those bugs are likely fixed, I'm still annoyed at the workflow when using LVOOP.

Regarding reentrancy, LVOOP doesn't (can't) support fully reentrant dynamic dispatch VIs, and debugging shared reentrant VIs is a PITA. Debugging them on LVRT is basically impossible without using an event logger.

0 Kudos
Message 14 of 44
(1,256 Views)

jlokanis wrote:

At the very least, they could tell me WHICH type def or sub-vi is the culprit triggering the change.  Is that so much to ask?

This is the biggest problem. Without this information it becomes nigh impossible to debug or isolate, let alone whittle it down to a case where I can show NI. Instead we have a list of a bunch of VIs that have changed and it's like looking for a needle in a haystack pile of needles.

I have tried to just save everything, then use SCC to get a list of changed files and try to group them to identify a source. No real luck, just lots of wasted productivity.

Anyways, I stand by my three "best" practices. I use quotes around "best" because they really are awful practices, but it's the best I can come up with to maintain sanity while using SCC.

Message 15 of 44
(1,256 Views)

Not wanting to thread-jack, but I will answer your question.  I stopped using SCC while developing LVOOP (and specifically LVOOP based command pattern messaging) because of how often I am creating new classes, and new VIs and then renaming them.  I realize this is due to lack of a detailed design, but I tend to only put my concepts down on paper and leave the implementation details to the coding work.  As a result of this, I find that I tend to add/remove/rename the private data elements often while creating a class.  I then need to cleanup the accessors I already created.  I also often rename a class.  And I often move it on disk after renaming it, since I want my file layout to reflect my code structure where possible.

All this churn at the file level is a nightmare for SCC integrated into the IDE and even if I just turned that off, It is still a mess to deal with between commits.  I would be constantly deleting from SCC and adding the new version with the new name.  Since I really do not care about the history of the code when it is a fresh project that is seeing a high level of change, I decided that I could live with an old school method of simple code backup.

Once my project is stable and working, I will check it all into SCC and then use that for maintenence.

So, it really is not the typedef change issue steering me away from SCC, it is the nature of LVOOP and command-pattern design.  A class is really a collection of descrete files.  What once was a simple case statement edit in a producer-consumer architecture now requires a file rename in LVOOP.  This is really a major problem with programming this way, as it removes the clarity of the block diagram as a way to view and understand your code and makes the way you organize your project files the only way to see and understand your code.  We really need new tools for viewing the interconnections between Actors and messages beyond nested virtual folders in a project.

But I digress.  Back to the original point, can you share with us the triggers that cause LV to think the typedef was changed?  And can you request an enhancement to at least tell us which typedef LV thinks changed?

-John
------------------------
Certified LabVIEW Architect
Message 16 of 44
(1,256 Views)
This widget could not be displayed.
Solution
This widget could not be displayed.

CharlesB64 & kegghead:

I went to talk to the development team. Although 2013 cleared up a lot of issues, we are continuing to work on the typedefs as a pain point. Our lead developer on typedefs believes that both of your complaints should be substantially improved and possibly even addressed in LabVIEW 2014. Please go to ni.com/beta and register for the LV 2014 beta if you'd like to evaluate whether that upgrade has the fixes you need. I am fully aware that upgrading LabVIEW is not possible for everyone and sometimes us saying "it's fixed here!" is not a viable solution. I'm trying to offer what help I can.

jlokanis wrote:

At the very least, they could tell me WHICH type def or sub-vi is the culprit triggering the change.  Is that so much to ask?

No, probably not. I just don't know if it has been asked in so many words... so I'll go ask and get back to you. ;-)

Message 17 of 44
(1,256 Views)

AristosQueue wrote:

jlokanis wrote:

At the very least, they could tell me WHICH type def or sub-vi is the culprit triggering the change.  Is that so much to ask?

No, probably not. I just don't know if it has been asked in so many words... so I'll go ask and get back to you. ;-)

So, the answer is that no tool exists at the moment. No one immediately had an easy way to build one, but it was worth putting on the list of things to consider.

But one developer pointed out that in all probability, when you load a hierachy that "hasn't changed" on a new machine and you get docmods, if you then ask "which typedef is responsible for this change?" the answer is likely to be "all of the strict ones." That's because one of the biggest reasons for this sort of change is the fonts. If the system fonts are different between two computers, that generally impacts the strict typedefs, and they all then push changes out to all the VIs that depend upon them.

Note that when I said earlier that kegghead's issue of typedefs claiming to have changed when they hadn't is we hope fixed in 2014, I meant specifically the cases where that was a bug and they hadn't really changed. The fonts changing is a real change and would still, I believe, be an issue.

Message 18 of 44
(1,256 Views)

AristosQueue wrote:

If the system fonts are different between two computers, that generally impacts the strict typedefs, and they all then push changes out to all the VIs that depend upon them.

you have to be kidding me.

0 Kudos
Message 19 of 44
(1,256 Views)

David Staab wrote:

AristosQueue wrote:

If the system fonts are different between two computers, that generally impacts the strict typedefs, and they all then push changes out to all the VIs that depend upon them.

you have to be kidding me.

Why are you surprised? If it is a strict typedef, all the size and layout computations of the front panel have to be redone when the display font changes. That's a huge, time intensive process, and it triggers a docmod. It's worked that way since strict typedefs were introduced almost two decades ago.

0 Kudos
Message 20 of 44
(1,256 Views)