Strange "rendezvs" and "semaphor" project dependencies

[Jim Kring]

[status: Reported to NI]

Related to the post, here, I have isolated the steps to reproduce the problem.

Steps to Reproduce

1) Open a new project

2) Add a new VI to the project

3) Place "Create Rendezvous.vi" (.\vi.lib\Utility\rendezvs.llb\Create Rendezvous.vi) and "Create Semaphore.vi" (.\vi.lib\Utility\semaphor.llb\Create Semaphore.vi) on the Block Diagram of the VI.

4) Save the VI to some location on disk.

5) Close the VI's front panel (which will unload it from memory).

Observed Results

Two new items, "rendezvs" and "semaphor", appear in the project's "Dependencies" list.

Expected Results

I do not expect these new items, "rendezvs" and "semaphor", to be in the Dependencies list. They are not VIs or project libraries. Rather, they are the names of the LLB files where these two VIs are located (respectively).

[Aristos Queue]

Actually, they are VIs. The .ctl files are saved without .ctl file extensions. I don't have LV with me to double check, but I'm pretty sure that's where the dependencies are coming from. Double check me by looking inside the .llb.

[Justin Goeres]

QUOTE(Aristos Queue @ Oct 29 2007, 06:25 PM)

Actually, they are VIs. The .ctl files are saved without .ctl file extensions. I don't have LV with me to double check, but I'm pretty sure that's where the dependencies are coming from. Double check me by looking inside the .llb.

I looked inside semaphor.llb and found sort of what you're talking about, but not exactly. It looks to me like the file is Semaphore Refnum, not semaphor.

EDIT: The situation is the same in rendezvs.llb: The file is Rendezvous Refnum, not rendezvs.

This interests me because I've seen a dependency called systemexec in some of my projects that I can't trace to anywhere:

Is it another instance of the same thing?

[Aristos Queue]

Hm... then I don't have any clue why those are showing up. I thought it might be some weirdness with the lack of file extension (that shouldn't be an issue, but with LV so Windows-centric sometimes the cases that we used to handle well that are more common on Mac get missed; seems that's not the case this time).

[Jim Kring]

QUOTE(Aristos Queue @ Oct 29 2007, 06:25 PM)

Actually, they are VIs. The .ctl files are saved without .ctl file extensions. I don't have LV with me to double check, but I'm pretty sure that's where the dependencies are coming from. Double check me by looking inside the .llb.

I'm pretty sure that these are the names of the respective LLBs and that these names don't show up anywhere else in LabVIEW.

QUOTE(Justin Goeres @ Oct 30 2007, 07:28 AM)

...

This interests me because I've seen a dependency called

systemexec

in some of my projects that I can't trace to anywhere:

Is it another instance of the same thing?

Yes, I think so. Actually, I've got loads of similar strange dependencies. For example, I have also have a dependency called mscorlib (which no extension) which seems to come from the fact that the code is calling into the mscorlib.dll .NET DLL. And, when I'm calling other .NET DLLs, these show up as root-level dependencies with no file extension.

[Jim Kring]

Update...

Status: Reported to NI, CAR Number 4EUGI2HE

[Jim Kring]

I've done a little bit more experimenting and found another quirk. Please see the attached sample project.

Download File:post-17-1194298015.zip

1) Open the "DotNetTest.lvproj" project.

2) Note that there is nothing in the "Dependencies" node of the project.

3) Open the Front Panel of "DotNetTest.vi"

4) Note that "System" appears in the "Dependencies" node of the project.

5) Close the Front Panel of "DotNetTest.vi"

6) Note that "System" disappears from the "Dependencies" node of the project.

Comments:

"DotNetTest.vi" calls into the "System" .NET assembly (System.dll), which is part of the .NET framework and is in the Global Assembly Cache (C:\WINDOWS\assembly). I do not understand why this appears in the dependencies list as a VI and why it only appears in the dependencies list when the VI is in memory and disappears when the VI is not in memory.

And, here's some more info:"rendezvs", "semaphor", and "systemexec" are the names of Code Interface Nodes (CIN) that are called by the Renzezvous, Semaphore, and System Exec VIs.

For example, these are the names as they appear in the output of the VI Server Application method "Linker:Read Info From File".

Thanks,

-Jim

[Rolf Kalbermatter]

QUOTE(Jim Kring @ Nov 5 2007, 04:37 PM)

I've done a little bit more experimenting and found another quirk. Please see the attached sample project.

Download File:post-17-1194298015.zip

1) Open the "DotNetTest.lvproj" project.

2) Note that there is nothing in the "Dependencies" node of the project.

3) Open the Front Panel of "DotNetTest.vi"

4) Note that "System" appears in the "Dependencies" node of the project.

5) Close the Front Panel of "DotNetTest.vi"

6) Note that "System" disappears from the "Dependencies" node of the project.

And, here's some more info:"rendezvs", "semaphor", and "systemexec" are the names of Code Interface Nodes (CIN) that are called by the Renzezvous, Semaphore, and System Exec VIs.

For example, these are the names as they appear in the output of the VI Server Application method "Linker:Read Info From File".

That was my first guess starting to read this thread and I'm pretty sure you hit the nail on the head. The Dependancies scan in the project is almost certainly using the "Linker:Read Info From File" but probably only when loading a VI. This function is very fast in returning all relevant dependancies including CINs, external code libraries and such so it makes sense to use it instead of trying to do something in LabVIEW itself which would be WAAAAAY slower.

I'm not sure it makes sense to show the CIN as a dependancy as it is really already embedded in the relevant VI and as such there is no physical file on disk that could be mapped to this item. So probably the filtering of the items should have taken out CINs or otherwise it should at least use a different icon.

Rolf Kalbermatter