Jump to content

Should I abandon LVLIB libraries?


drjdpowell

Recommended Posts

But these aren’t real dependancies.  "A calls B which calls C†is a dependency of A on C.   “A calls B which is in the same library as X, which calls Y, which is in a library that also has Z, which calls C†is not.  I have no interest in managing false dependancies introduced by lvlibs.  

 

 

This is the real problem.  To simplify my example i had two classes in a library.  One was a GUI Class and the other was a Hardware class.  I did this to group them together for ease of reuse in future projects.  However, I had no intention of using the GUI class on the CRIO so when i re-used my hardware class, i had no idea that the gui class would become a dependency solely b/c they were both in the same library.   My GUI class used subpanels and all sorts of things that CRIO's don't' like and was causing a hard crash out of lab view every time i tried to build my real time application (totally separate issue but also a learning experience).  Granted i was not as familiar with libraries as i am now but still it is confusing and while training may help it seems counter intuitive.  

 

Paul's suggestion of loading the libraries into an empty project is what eventually helped me track down my issues, and i was familiar with that method from older posts on this forum.  As a side note its a decent way to track down corrupt classes and libraries as well. But all of that just gets me back to, why doesn't the individual class or library "project window" show the dependencies of the library/class.  

 

I was basically looking for a way to group similar code so that i could re-use it for later projects and what i learned is that instead of libraries i should use GIT repos or VIPM and leave it at that.  

I understand.  Fair enough.  I think we all agree that A and B in drjpowell's second case, which correspond to odoylerules' Hardware and GUI classes, shouldn't be be in the same project library.  I think we also agree that pitfalls like these are not immediately obvious to all those who design LabVIEW applications.  My experience, once I understood how library dependencies work, was that it was advantageous to use project libraries when needed, putting A and B in separate project libraries as appropriate.  Once I knew the rules this was not difficult, and it even drove me to end up with very clean projects with code in easily reusable packaged, namespaced libraries; in my experience it was well worth the effort.  This is a good capability to have, but does require careful application.

  • Like 1
Link to comment

But libraries don’t need to just be a good capability to have for the very advanced programmer who has learned to use them carefully “when neededâ€.  Libraries could be broadly useful at a range of ability levels and for a wide variety of things.

Fair enough.  My perspective is that we need to equip a broader range of developers with an understanding of interfaces, etc., so that they can use project libraries effectively.

Look, I think the loading-of-dependencies approach is consistent (the loading of parent libraries, maybe less so) with LabVIEW's overall linking model, and I think there would be trade-offs if LabVIEW were to depart from that model.  I think it is straightforward to work with that model, in such a way that project libraries are helpful (in certain circumstances), especially when coupled with interfaces, so I don't think it is helpful just to bash the project library concept.  It is a useful concept!  Perhaps proposing an alternative concept that would address competing needs would be more likely to yield results.  Keep in mind, though, the LabVIEW IDE's overall approach to loading dependencies.  Changing that may be more convenient for some use cases, but it would have to be in a manner such that it would be obvious to a broad range of developers, even me!

Are there examples from other development environments that more closely represent what you need?

Link to comment
  • 6 months later...

Beautiful discussion - this is one of the few things I find really awful about LabVIEW, and a thing I really really hope will change.

 

For deployment LVLIBP can work, but not for dev tools (which I do most of involving libs) as they need to be cross-platform and cross-version. LLBs are out of the question for me because they're so arcane. Everybody has mentioned all the pros and cons of these files except for one thing: Security.

 

I use LVLIBs for three features, here in the order of importance (for me):

 

1) Namespacing.

2) Security against someone else replacing my code.

3) Scope.

 

I wish LVLIBs also had this fourth feature:

 

4) Single file on disk.

 

/Steen

 

I just offloaded a portion of our main application code into lvlibs and when building the executable, placed them outside the exe itself.  Where did I put them? In an LLB.  The LLB contains only the library and it's members.  Isn't that (more or less) your point 4) ?

 

I use normal lvlibs in development but the application builder slaps them into an LLB for our application (and automatically re-links to the LLB of course).

Link to comment

I just offloaded a portion of our main application code into lvlibs and when building the executable, placed them outside the exe itself.  Where did I put them? In an LLB.  The LLB contains only the library and it's members.  Isn't that (more or less) your point 4) ?

 

I use normal lvlibs in development but the application builder slaps them into an LLB for our application (and automatically re-links to the LLB of course).

 

Which LabVIEW version? According to my own tests some time ago, there was no way to get lvlib, lvclass or similar >= LabVIEW 8.x files into an LLB.

Link to comment

Which LabVIEW version? According to my own tests some time ago, there was no way to get lvlib, lvclass or similar >= LabVIEW 8.x files into an LLB.

 

I think they mean creating Destinations set to LLB on the Destinations tab of the EXE build spec.  I tried putting LVLIBs in these Destinations and it seems to work.  

 

Added later>> shoneil posted while I was experimenting.

Link to comment
  • 9 months later...

This thread got me to reorganize my workspace and project structure to most importantly improve load and build times and reuse workflow. It came to me as a surprise that LVLIB's although great in some ways force static links to everything in the library. I had previously seen this with classes but for some reason didn't expect the same from LVLIB's. Anyway, I ended up breaking apart a lot of reuse code and restructuring a large project. This seemed obviously a pretty daunting task at first and I was looking to utilize the "links" application by JackDunaway/Wirelabs. Unfortunately, I didn't manage to get it working fully so what I ended up doing was grabbing the hidden "App.Read Linker Info From File" invoke node from the code and searching the list for items where links jump to unintended libraries etc. The few hours of work were definitely worth it and I can recommend similar procedure to anyone starting to see the effects of unwanted coupling.

  • Like 2
Link to comment
  • 3 years later...
On 9/18/2015 at 10:36 AM, shoneill said:

In my build spec, I define a target directory, tell it to store it in an LLB and then just put the lvlib (and all lvlib files) in there.  Seems to work fine.

 

OH, and LV 2012 SP1

Any tricks to this? (I'm using LV2018)

If I try to target an lvlib to an llb (because I want the llb to be a single file, to be used as a plugin), I keep getting several folders outside the llb, and none in the llb. This is with the whole lvlib included and the destination set to an output directory set to be an llb.

Right now the lvlib I want included in an llb is the JKI Serialization.lvlib, which has classes included as well so it is not the simplest lvlib. I have tried all kinds of variations on where to target dependencies too..Including the lvlibs in the executable seems to be the only way to get everything nicely packaged into one file, but in this case I do not want to update the executable, I want it portable with a/several plugin(s). Not excluding unused items and allowing the build to modify libraries seem to help avoid subVIs ending up in directories outside of the target directory in some instances, but it does not help getting lvlibs into an llb. The second tidiest working solution seems to be to target the lvlibs to a directory. That fills the directory with hundreds of files (a mess I do not like), and you might get into naming collisions if you point several lvlibs to that directory because the name spacing is not kept (could have automatically separated the subVIs to namespaced folders e.g.). Using packed project libraries is perhaps one solution, but that is cumbersome, especially when dealing with lots of different targets.

Edited by Mads
Link to comment
29 minutes ago, Mads said:

Any tricks to this? (I'm using LV2018)

I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name).

I suppose the PPL is the proper replacement for this now, although that's not source code....

  • Like 1
Link to comment
1 hour ago, shoneill said:

I love it when old posts come up and I simply can't remember writing them, but my name is on it, so it must have been me..... No, no tricks. Haven't done that in years. It was for simply LVLibs, no classes, no hierarchies. LLBs don't play well with classes (no sub-folders, no ability to store multiple VIs with the same name).

I suppose the PPL is the proper replacement for this now, although that's not source code....

Ah, it's just the classes that mess things up then.

One more vote for the idea of a single file distribution for classes then on the idea exchange... (or even better as fabions mentions in the comments; an upgraded and backwards compatible llb format with support for subdirectories? 👍).

Link to comment
6 hours ago, Mads said:

Ah, it's just the classes that mess things up then.

One more vote for the idea of a single file distribution for classes then on the idea exchange... (or even better as fabions mentions in the comments; an upgraded and backwards compatible llb format with support for subdirectories? 👍).

The upgraded LLB almost certainly never ever will happen. The lvclassp or whatever it would be called probably neither because you can do that basically today by wrapping one or more lvclasses into a lvlib and then turning that into a lvlibp.

While these single file containers are all an interesting feature they have many potential trouble as can be seen with lvlibp. Some are unfortunate and could be fixed with enough effort, others are fundamental problems that are hard to almost impossible to be really done right. Even Microsoft has been basically unable to plugin an archive system like a ZIP archive into its file explorer in a way that feels fully natural and doesn't limit all kind of operations that a user would expect to be able to do in a normal directory. Not saying it's impossible although the Windows Explorer file system extension interface is basically a bunch of different COM interfaces that are both hard to use right and incomplete and limited in various ways. A bit of a bolted on extension with more extensions bolted on on the side whenever the developers found to need a new feature. It works most of the time but even the Microsoft ZIP extension has weird issues from using the COM interfaces in certain ways that were not originally intended. It works good enough to not having to spend more time on it to fix real bugs or to axe the feature and let users rely on external archive viewers like 7-ZIP,  but is far from seamless.

At least for classic LabVIEW I think the time has come where NI won't spend any time in adding such features anymore. They will limit future improvements to features that can be relatively easily developed for NXP and then backported to classic LabVIEW with little effort. Something like a new file format is not such a thing. It would require a rewrite of substantial parts of the current code and they are pretty much afraid of touching the existing code substantially as it is in large parts very old code with programming paradigms that are completely the opposite to what they use nowadays with classes and other modern C++ programming features. Basically the old code was written with standard C in ways that was meant to fit into the constrained memory of those days with various things that defies modern programming rules completely.

Was it wrong? No, it was what was necessary to get it to work on the hardware that was available then, without waiting another 10 years to have on the architecture and hope to get the hardware that makes a modern system able to run, with programming paradigms that were nowhere used at that time.

Edited by Rolf Kalbermatter
Link to comment
2 minutes ago, Rolf Kalbermatter said:

The upgraded LLB almost certainly never ever will happen. The lvclassp or whatever it would be called probably neither because you can do that basically today by wrapping one or more lvclasses into a lvlib and then turning that into a lvlibp.

While these single file containers are all an interesting feature they have many potential trouble as can be seen with lvlibp. Some are unfortunate and could be fixed with enough effort, others are fundamental problems that are hard to almost impossible to be really done right. Even Microsoft has been basically unable to plugin an archive system like a ZIP archive into its file explorer in a way that feels fully natural and doesn't limit all kind of operations that a user would expect to be able to do in a normal directory. Not saying it's impossible although the Windows Explorer file system extension interface is basically a bunch of different COM interfaces that are both hard to use right and incomplete and limited in various ways. A bit of a bolted on extension with more extensions bolted on on the side whenever the developers found to need a new feature. It works most of the time but even the Microsoft ZIP extension has weird issues from using the COM interfaces in certain ways that were not originally intended. It works good enough to not having to spend more time on it to fix real bugs or to axe the feature and let users rely on external archive viewers like 7-ZIP,  but is far from seamless.

At least for classic LabVIEW I think the time has come where NI won't spend any time in adding such features anymore. They will limit future improvements to features that can be relatively easily developed for NXP and then backported to classic LabVIEW with little effort. Something like a new file format is not such a thing. It would require a rewrite of substantial parts of the current code and they are pretty much afraid of touching the existing code substantially as it is in large parts very old code with programming paradigms that are completely the opposite to what they use nowadays with classes and other modern C++ programming features. Basically the old code was written with standard C in ways that was meant to fit into the constrained memory of those days with various things that defies modern programming rules completely.

Was it wrong? No, it was what was necessary to get it to work on the hardware that was available then, without waiting another 10 years to shave on the architecture and hope to get the hardware that makes a modern system able to run, with programming paradigms that were nowhere used at that time.

Sure. The idea exhange and the whole NXG vs current LabVIEW scenario always makes me think of one particular song by the Fugees...😉

Link to comment
1 hour ago, ShaunR said:

It's the other way round. You include the files contained in an LLB in a lvlib. You end up with two files, the lvlib (XML description) and the LLB (the Vis).

Not really, but that would be one way to attack it yes, if it was not for the classes.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.