Add architectural warnings to the error log

[HenrikDueholm]

I recommend the implementation of architectural warnings in the error log for detection of architectural mistakes. It would be nice if this could be toggled from the error log (like warnings) or had a viewer of some sort.

So far, I only have one architectural error that I’d like to catch, but I’m sure there are many others as well. Feel free to add suggestions for more architectural errors you'd like to catch.

Below I’m demonstrating the problems with bi-directional library dependence when using ppls. In this case the warning should state that: “Bi-directional dependence detected between Lib3 and Lib4”.

• Initial state:
  Lib4 initial state
  and
  Lib3 initial state
  So we have bi-directional dependence which can only be seen through usage of multiple projects.
• Lib3 built to Packed3 and replaces Lib3:
  Lib 3 replaced with Packed3
  Everything seems fine and the replace operation worked.
• Now look at the project used to build Packed3:
  Lib3 code locked
  Lib3 depends on Lib4 but Lib4 has had a replace operation so it depends on Packed3 --> Packed3 will always be in memory --> it is no longer possible to rebuild Packed3.
  Reverse replace not possible, so manual reverse is required to fix the code again.

Note:

The VI hierarchy does not help at all 😞

:No help from VI Hierarchy

[AristosQueue (NI)]

Unfortunately, this isn't an error. It's intended behavior. Not behavior I would recommend using, but libraries are allowed to be circular. Only packed libraries are not. There's no error in the source files.

[HenrikDueholm]

Sorry, I guess I wasn't quite clear. My suggestion is not to have the above case be an error. It is to have a way to be warned about the circularity of the libraries. I doubt that people make libraries circular on purpose (except maybe for the AF/AF debug?), but there is no easy way to detect that it has happened.

We can toggle warnings from the error log and that's the functionality that I suggest you expand on.

Perhaps with something like this:

Architectural warnings enabled

Here we could show warnings that would help you notice that you are moving away from good practice and that you're potentially heading towards a sad, sad future. I'm sure you can think of other cases where users have pushed themselves into a corner due to some unwise architectural practices. They would probably have liked this feature as well :).

Maybe I should not have called it an architectural error and kept to calling it a warning, however when you do the ppl replace you've put yourself in a situation where it feels more like an error than a warning :P.

In short: I would like a feature that can warn me (not as an error) when I'm doing something that is clearly not recommended (though still 'legal') and possibly even state why. 

[AristosQueue (NI)]

Oh.

Yeah. That seems reasonable.

I'm not sure why I didn't get that the first time.

[wiebe@CARYA]

This might be more of a VI Analyzer thing to check? It would be hard no matter where it's checked. Not sure if it's technically feasible to make a reliable check for this. 

[HenrikDueholm]

I agree it could also be implemented as a project analyzer. Implementing it in the VI analyzer would not match the name of the analyzer very well. The problem with putting it in a special analyzer is that the user base of the tool would be limited. I use the error log all the time but very rarely the VI analyzer.

Regarding the feasibility of the idea I believe it's technically possible as the project explorer tracks all the dependencies already and as it doesn't stall when it encounters a circular dependencies they must handle it in some way already (but that could just be a 'already loaded' check).

Anyway I'm more interested in the why (and when) of things. I leave the how to NI.

Another potential warning I've thought of:

• Lowest common folder of the files contained in a library is at a lower path than the library file itself.
  • When building a PPL from the library this will lock the path structure to the lowest common folder making the contained paths long and weird.
  • If your files are too far apart they might not even be in the same repository!

Libraries within libraries could also possibly be one?

[SteenSchmidt]

I think this is a really good suggestion Henrik, and I can think of many more valuable "architectural warnings". Use of error/no error case around all the code in close/destroy VIs for instance, checking refnum validity with not-a-refnum and so on.

I also agree with Wiebe that some of these might belong to VI Analyzer, but then again I'd love a future where VI Analyzer and even unit/component tests were run continuously on my code so I could have immediate feedback from those as well. Just as immediate as current type prop resulting in a broken wire.

Circular dependency will trip the error list immediately for recursion, but only with first level cycles. Deeper cycles aren't analyzed today by LabVIEW, so we could have three or more VIs which depend on each other in a recursive cycle and LabVIEW wouldn't detect it. Depending on exit conditions such a cycle could work or not (but so could a cycle with two VIs). This specific issue with libs and PPLs is similar; bi-directional dependency trees could be quite easily detected, but bigger cycles will take more time to analyze.

The idea itself - an entirely new class of warnings - is very good in any case. Kudos.