search

vipm-io / caraya

Assertion and unit test framework for LabVIEW
Other
59 stars 33 forks source link

Caraya Custom LabVIEW CLI Operation #119

Closed felipefoz closed 3 years ago

felipefoz commented 3 years ago

Hi Everyone,

I've been developing this custom labview CLI operation for Caraya to use in my applications. You can check it out here.

https://gitlab.com/felipe_public/gitlab-tools-labview/caraya-cli-operation/-/releases

By the way, I modified myself a version to get the results object as mentioned in #112 .

I am using a docker image to run the tests in Gitlab CI. In order to this image work with Caraya, I manually masscompiled and copied Caraya Files into vi.lib. So far, no problems.

When I try to run Caraya from a normal Caraya method, it works. When I try to run from this Custom Operation, it hangs.

The same operation I repeated on my machine, and they both work. Also, I use a custom CLI operation for VI Analyzer and I don't have any issues.

Any idea what is going on?

felipefoz commented 3 years ago

There was a dependency problem. Sorry for bothering about this problem.

There must be a rule for not reusing classes in LabVIEW, always start from scratch. :P

Anyways, issue was solved, but the post is here also to offer the possibility of including this custom labview cli in the Caraya Package in the next version, if you wish. I don't know much about the backwards compatibility, but as long as labview cli is installed, it should work.

jimkring commented 3 years ago

Glad it's working for you. Yes, I've heard people say to NEVER rename an existing LVClass.

francois-normandin commented 3 years ago

I think this is a case where the rarely used "Clear Compiled Object Cache" would have helped.

I've heard people say to NEVER rename an existing LVClass.

(Off-topic) How else would you reset the class mutation history? ;-)

jimkring commented 3 years ago

That's a great point @francois-normandin. I always delete the object cache as the first step of CI, prior to any work with LabVIEW (unit testing or building)

felipefoz commented 3 years ago

That's I believe an advantage of using docker, it is a clean LabVIEW installation every time, but on the other hand, it is extremely hard to debug, as you can't see any output visually (I mean not CLI), because LV is very dependent on the UI.

About LV Classes, they are a mistery sometimes.

(Off-topic) How else would you reset the class mutation history? ;-)

@francois-normandin Never felt the need to. What is the use case?

francois-normandin commented 3 years ago

Mutation history is one of those things that we should never worry about, but is one of the things I check when something is not quite working right with classes and I don't know why.

Mutation history, as far as I can tell, is only useful to unflatten LabVIEW objects that have different versions of private data (addition our deletion of elements) such as when two applications compiled with different versions of the same class are messaging each other across application instance boundaries.

If you do not flatten and unflatten your objects across the application instance boundary, them the object is always of the same revision and does not need to maintain mutation history. In such cases, resetting the mutation history has a few benefits: smaller footprint, faster load time, faster compile time, faster build time. None of these brings any human-noticeable difference except in one particular case: you have deleted a typedef from the private data, or removed a dependency that used to load a library in memory that should never have been loaded.

It also fixed a problem I had, once, where a class would fail to compile for RT after I had made a change in the PC instance and reopened the RT project. I had added a control to the private data and somehow it would not compile correctly in the RT project anymore. That must have been a rarely stumbled upon bug in the early days of classes because nowadays, clearing compiled object cache is the thing that usually solves all these little quirks for me.

felipefoz commented 3 years ago

Mutation history is one of those things that we should never worry about, but is one of the things I check when something is not quite working right with classes and I don't know why.

I might remember that when I got into trouble next time. It always good to know these issues with LV Classes. Thanks.

joerghampel commented 1 year ago

Old thread, but still: We clear the compiled object cache all the time, and definitely before each job on the build server.

Regarding clearing the mutation history, this might be helpful: https://dokuwiki.hampel-soft.com/kb/labview/debugging#building