LabVIEW
Is putting an .lvlibp into an .llb supported?
LLBs are from the stone age of LabVIEW and mainly developed to circumvent the 8.3 naming limitation of DOS, which was the underlying OS for Windows 3.1.
It’s usefulness was pretty limited after LabVIEW for Windows 3.1 was history and a major liability for use with version control systems. Accordingly it was already considered bad form long before LabVIEW eventually gained lvlib and lvclass. While not fundamentally impossible to support adding lvlib’s to llb’s, it’s synonymous to trying to fit a square peg into a round hole.
Also there are (used to be) quite a few reports of users whining about loosing months of work after a crash or power outage during writing of an LLB corrupted it. The LLB format is not an advanced journaling file system but a pretty simple and crude implementation of a minimalistic archive format. A single byte error can render it unreadable and there is nobody who will help you to recover it. NI support has long ago stopped to do that, and nobody else knows enough about the format to have much chance of doing that.
@rolfk wrote:
It’s usefulness was pretty limited after LabVIEW for Windows 3.1 was history and a major liability for use with version control systems. Accordingly it was already considered bad form long before LabVIEW eventually gained lvlib and lvclass. While not fundamentally impossible to support adding lvlib’s to llb’s, it’s synonymous to trying to fit a square peg into a round hole.
NI is even changing all of the LLBs in vi.lib into folders. Legacy programs are the only reason LLBs are still around. LLBs are on my list of items that should be completely deprecated, granted much farther down the list among a lot of other arcane features that nobody knows about.
@JÞB wrote:
@jondbaker42 wrote:
When I try to put an .lvlibp into an .llb, it inserts fine, but when I try to open the .lvlibp from the LLB manager, LabVIEW can't find the .lvlibp (browse for file dialog, then File not found error.)
Is this supported and I'm just doing something wrong, or is it not supported, but with poor error management?
Some background, (why I want to do this.)
We have a compiled LabVIEW program that is capable of running outside vi's. These outside vi's ..... must have Separate Compiled Code turned Off. We have all our dependencies packaged into a single .llb.
Thanks in advance.
This makes no sense. A Packed Project Library contains no source code and cannot be edited! A *.lvlibp is a build output of a *.lvlib. PERIOD! IT CANNOT BE UNPACKED to source code. The LLB manager is not going to find any source to open.
Maybe the error is not as informative as it could be but, who would have expected the LLB Manager to fully support a file format that wasn't even conceivable? It's like expecting whales to use fire.
Oops. I missed the p at the end. Indeed PPLs inside an LLB are entirely useless. There is no way this could be cleanly supported.
@JÞB wrote:
@rolfk wrote:
Oops. I missed the p at the end. Indeed PPLs inside an LLB are entirely useless. There is no way this could be cleanly supported.
So, teach us! I know a few things. But, the details are beyond my understanding.
It makes no sense. LLBs do not support multilevel hierarchies. It may be possible to extend the LLB format to do so, but chances that that is ever going to happen is probably smaller than that the hell is going to freeze over. To much liability, legacy cruft and general limitations together with a poor mans archive management scheme that was enough at that time to make it work but to little to be able to be reliable. Even ZIP files have more stability and robustness built in. zlib got available only in 1995, otherwise they would have gone with that. (They did later, >= 8.0, integrate that to add internal support for the deflate and ZIP format to LabVIEW but at the time they would have needed that, 1990 to 1992, it did not exist publically.)
Even multilevel lvlib's are not really going to work, The LVLib part is not prepared to deal with the additional redirection level needed to support that. It expects to be able to access the files in the lvlibp internal packed archive, which seems to be using some LEIF format, or directly on disk but not in another obscure archive container. And LLBs never where transparently integrated into the file functions. A few such as List Directory have special code to detect that they operate on an LLB rather than a real directory and then call the according LLB List Content function, but File Read and File Write do not know about such a redirection.
