VIPM and separate compiled code

[maristu]

I’m a big fan of JKI VIPM, and I’ve been usen Source code control with labview for some years (First with mercurial and now with GIT). Following the good practices with SCC and LabVIEW I always check the separate compiled code from vi to avoid unwanted changes on Vis.

In the other hand I’ve read that the performance of labview is better with the compiled code in the VI. Besides that the labview IDE does not allow you clear compiled cache of some of your vis, you have to delete all the compiled cache…When I have some compilation errors and I delete the compiled cache It takes a lot of time to open again the project…

My question is… VIPM allows you to execute some code after the package installation (post-installation-action). Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?.

Maybe I have to make this question in VIPM forums also, to check when is executed that post-installation-action, if it is executed before or after the masscompiling

 

Thanks!!

[LogMAN]

Welcome to LAVA 🎉

2 hours ago, maristu said:

I’ve read that the performance of labview is better with the compiled code in the VI.

Not sure where you read that, here is what the LabVIEW help says:

Quote

LabVIEW can load source-only VIs more quickly than regular VIs. To maximize this benefit, separate compiled code from all the files in a VI hierarchy or project.

-- Separating Compiled Code from VIs and Other File Types - LabVIEW 2018 Help - National Instruments (ni.com)

 

2 hours ago, maristu said:

Could it be a good idea to unmark the separate compiled code programmatically on each installed file (vi, ctl, class, lvlib… )?

I don't see the benefit. Your projects will take longer to load and if the compiled code breaks you can't even delete the cache, which means you have to forcibly recompile your VIs, which is the same as what you have right now.

[joerghampel]

I wrote a blog post about separating compiled code a while ago, it might be interesting for you:

https://www.hampel-soft.com/blog/separate-compiled-code-from-source/

[X___]

I learned about the Project-level "Mark Existing Items" button reading that blog post...

[ThomasGutzler]

I remove all compiled code from my vis and rarely see problems with it. Nothing that can't be resolved by clearing the compiled object cache. However, I found that the project-level check box doesn't work properly, so I wrote my own quick drop plugin that goes through the project to fix everything up.

In VIPM I usually keep the mass compile option after install checked, except for our build servers because they install a different set of packages with almost every build and it takes longer to mass compile everything.

Remove Compiled Code.vi

[X___]

On 3/11/2021 at 1:32 PM, ThomasGutzler said:

I remove all compiled code from my vis and rarely see problems with it. Nothing that can't be resolved by clearing the compiled object cache. However, I found that the project-level check box doesn't work properly, so I wrote my own quick drop plugin that goes through the project to fix everything up.

In VIPM I usually keep the mass compile option after install checked, except for our build servers because they install a different set of packages with almost every build and it takes longer to mass compile everything.

Remove Compiled Code.vi 36.91 kB · 1 download

Similar to the VI posted at the end of the blog post 3 above (with less granularity and the option to do the reverse by mistake! :-)

In what sense is the project-level check box not working? I am interested because I have set the app-scoped flag to "remove compiled code" but still occasionally find some new VIs (created by "Create sub VI from selection") with their flag turned OFF. It is probably time for me to ask whether I am just victim of a LV virus or this is indeed a reportable bug (very irreproducible, so not very convincingly reported).

[maristu]

Thank you very much for your comments. My troubles started trying to use same clases in a realtime project and later in a PC project.

Thak you @joerghampelfor your blog, it is very useful. 

what it really annoys to me it is when a class or file is corrupted and then I have to clear the compiled cache... It takes a looooooot of time... and I was trying to avoid that. I think that I've found a workarround prior to clear the compiled cache. It is unmark all the content in a directory to remove compiled code and later mark again all the content... at least it worked for me twice.

[Yair]

On 3/13/2021 at 4:44 AM, X___ said:

 I have set the app-scoped flag to "remove compiled code" but still occasionally find some new VIs (created by "Create sub VI from selection") with their flag turned OFF. It is probably time for me to ask whether I am just victim of a LV virus or this is indeed a reportable bug (very irreproducible, so not very convincingly reported).

Don't know about new VIs, but there is a bug where if you crash LV and then restore auto-saved VIs, they always have the flag turned off.

[Rolf Kalbermatter]

On 3/18/2021 at 8:27 AM, Yair said:

Don't know about new VIs, but there is a bug where if you crash LV and then restore auto-saved VIs, they always have the flag turned off.

New VIs should simply inherit the default setting you made in your Tools->Options->Environment->General unless you create them from inside a project, in which case they inherit the setting as made in the project properties.

The bug mentioned by Yair may be related to the fact that the restoring of auto-saved VIs is not happening in the project context but in the global LabVIEW context and therefore uses the global settings from the Tools menu.

Edited March 19, 2021 by Rolf Kalbermatter

[Yair]

Yeah, I meant "I don't know about anything wrong with new VIs, but here's one way to cause this with a VI you create".

The global setting I have is also configured to separate, so I think your idea is unlikely to be the cause.

Anyway, the bug# for that one is 961456. By the time I thought about reporting it, the 2020 beta was already happening, so I don't know if NI fixed it for 2020 or SP1 or 2021 if it ever comes out.