Closed rtzoeller closed 4 years ago
Bleep bloop!
LabVIEW Diff Robot here with some diffs served up hot for your pull request.
Notice something funny? Help fix me on my GitHub repo.
Do we need a shared library? Or can the System Explorer PPL just pull in some of the Engine PPL?
Are you describing having the System Explorer PPL depend on the Engine PPL, or depending on the original source VIs found in the Engine lib and pulling its own copies into the System Explorer PPL?
Are you describing having the System Explorer PPL depend on the Engine PPL, or depending on the original source VIs found in the Engine lib and pulling its own copies into the System Explorer PPL?
I think he's referring to the latter, where source would live in the engine lvlib, but some VIs would get pulled into the System Explorer PPL. The alternative is to create another library with the shared items and have both PPLs pull that in.
I think he's referring to the latter, where source would live in the engine lvlib, but some VIs would get pulled into the System Explorer PPL. The alternative is to create another library with the shared items and have both PPLs pull that in.
I think that's the way to go. I don't see the need for a new shared lib at the moment.
Minor: Rather than a 4-iteration ForLoop, I'd prefer a string concat of "........\" prepended to the CHM file name before being passed to the build path.
@niphilj how do you feel about dynamically finding the .lvlibp extension or searching for the first folder on disk from the path and truncating there? Hard-coding a specific number feels like a hack; the code needs to know how it's built and it shouldn't need to.
@niphilj how do you feel about dynamically finding the .lvlibp extension or searching for the first folder on disk from the path and truncating there? Hard-coding a specific number feels like a hack; the code needs to know how it's built and it shouldn't need to.
Searching a known path is actually my preference. Please do that instead.
@buckd it's not clear to me if we even need the GUIDs in the custom device. Is there a place you can think of us needing them, or can we limit them to the PPLs only?
Since they're defined the scripting API, it's hard to share them with the custom device (since that isn't top-level in a PPL).
Is there a place you can think of us needing them, or can we limit them to the PPLs only?
I can't think of anywhere we would need them in the custom device. Since we can get them from the item ref in OnCompile
, we wouldn't need them there and any tree navigation would happen from the pages, which already have everything they need in the PPL.
Can we handle System Explorer buttons in a better way then forcing the developer to wrap VIs individually (like we did for RTMs)?
Because you're dealing with a Node Ptr and not a class directly, it looks like you don't have a choice but to have a wrapper, otherwise you'd be able to dynamic dispatch off the interface class directly. That's my thought.
Bleep bloop!
LabVIEW Diff Robot here with some diffs served up hot for your pull request.
Notice something funny? Help fix me on my GitHub repo.
What does this Pull Request accomplish?
Moves the communication bus specific System Explorer code to a PPL.
Add support for Linux x64 (not built via
build.toml
at the moment).VeriStand can only call VIs in LLBs, so we need to do some clever forwarding. Pages can be wrapped in sub-panels, and we do our own dispatching based on GUIDs to find the correct pages and RTMs.
Diffing this change works best with the
--find-renames=10%
option provided by git; moving and resaving the VIs as part of new libraries changed the binary files enough that git doesn't natively detect them as renames.Why should this Pull Request be merged?
The execution units are built as a PPL, since they rely heavily on interfaces and classes. Since the custom device LLBs depend on these PPLs, the System Explorer code is necessarily in a separate project. This makes it difficult to work on the custom device, since changes often need to be reflected in both components.
By moving the core system explorer logic to a PPL, the user can work primarily in a single project, as well as use LabVIEW classes and not worry about file naming conflicts.
What testing has been done?
Hand testing of the custom device; any behavior change introduced by this PR should be considered a bug.
Open work
Open questions
And likely more.