Jump to content

Should I abandon LVLIB libraries?


drjdpowell

Recommended Posts

Something I did not appreciate till today:

 

If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies).

 

In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. 

 

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? 

 

— James

 

Added later: Must be getting old, as I forgot that I already knew this.  But the question remains of what to do about it.

Link to post
  • Replies 67
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

LLBs and LVLibs solve different problems (and create different problems), and are not interchangeable or really related beyond sharing the word "library" in their acronyms.   Here are some character

Can we get rid of LVLIB “libraries†then?  Or at least rename them as they don’t match the English meaning of library?   Libraries are not "collections of books that cannot be read except all at

@JackDunaway Great analysis with which I agree with 99.9% (except for your first sentence). You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and a

Posted Images

At work we favor packed project libraries for production deployment (VIPM packages for development deployment) so lvlibs are unavoidable for us.

 

But we do run into the "load the earth" scenario too. The best compromise we have found is to break down the component into smaller pieces.

Link to post

Yeah this "feature" kinda sucks at time.  And I'm a little disappointed that no other posts have been tagged with "things about labview that suck" but whatever.

 

If it makes you feel any better, in the build environment generally these unused dependencies are removed.  In the build specifications under Advanced there is a checkbox for removing unused items.  Then at least they won't exist in your EXE, taking precious loading time.

 

As for the development environment, yeah modulating code helps.  But doing so usually means more VIs in general, which means more dependencies on disk.  I don't find it that bothersome, but if you have 100s of libraries and classes I would be pulling my hair out trying to find a better solution.

Link to post

Unless VIPM is involved, I Use LLBs instead.

Not trying to change the subject, but I avoid LLBs at all costs.  Every time I find one the first thing I do is extract the VIs from it.  I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway.  I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it.  I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

  • Like 1
Link to post

If it makes you feel any better, in the build environment generally these unused dependencies are removed. 

True, but how do I identify real dependancies from all the fake ones?  

Unless VIPM is involved, I Use LLBs instead.

LLBs don’t seem to be equivalent (though I never really used them).  No namespacing, no Private scope.

Link to post

Not trying to change the subject, but I avoid LLBs at all costs.  Every time I find one the first thing I do is extract the VIs from it.  I feel that way because it seems like a zip or an archive, where to use it with the normal tools, I need to extract it anyway.  I also know there were odd bugs a while ago where the LLB would get corrupted and ruin all the VIs in it.  I know that is petty especially since it probably has been fixed long ago, but it still lingers as a thing to avoid in my mind.

 

They fell out of favour because they hide VIs from source control rather than any bugs or funny behviours. However, VIPM can pack directories into LLBs so it's not that much of an issue anymore for most people (can keep directories for development if its an issue). Your animosity towards them is unfounded :D

Edited by ShaunR
Link to post

True, but how do I identify real dependancies from all the fake ones?  

LLBs don’t seem to be equivalent (though I never really used them).  No namespacing, no Private scope.

 

Well. If you abandon LVLibs, you will only have a directory of VIs which are very easy to cross link and not as easy to distribute or organise as well as no namespacing or private scope. If you want scope, put them in a class.

 

For dynamic loading plugin distros, LLBs are great because they are monolithic containers that don't load everything into memory unless linked or loaded explicity . For identical to LVLib without the [arbitrary] bits you don't want-probably asking too much.

Edited by ShaunR
Link to post

Something I did not appreciate till today:

 

If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies).

 

In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. 

 

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? 

 

— James

 

Added later: Must be getting old, as I forgot that I already knew this.  But the question remains of what to do about it.

 

I'd say your lvlibs are probably too big. I tend to consider them to be a single API, not a library of many APIs. This matches well for the features of the lvlib. For example, I can add a icon overlay as part of the lvlib file. If I have too many things I can't make a single good icon. Everything in the lvlib should be something you want to be loaded atomically, in my opinion. I'm not sure what I would do in situations where the stuff in the lvlib is not an API I want to use.

 

All that having been said, I've never really used the dependencies for anything except to get to parent classes and the like, so I'm not sure what sort of filtering you want to do on that information. But I would also say that keeping dependencies in lvlibs makes your dependencies organized -- you don't have 1000 stray files from VI lib, you have 5 classes and 5 lvlibs.

 

In fact, I have the reverse problem you have. Since labview counts things in lvlibs as dependencies but doesn't necessarily load them into memory, things like find and replace or "show error window" don't actually work on them unless you manually open the front panel of every VI. 

Link to post

Everything in the lvlib should be something you want to be loaded atomically, in my opinion.

 

Is that wise?  What if your API optionally interacts with some other API, and you have optional methods to support easy interoperation.  It’s possible that a particular programmer my want to use one or the other APIs by themselves.   Where do the optional VIs that depend on both go?

 

An example might be: I have a message-passing API, and a TCP API, and I want to pass messages by TCP sometimes, without tying these two APIs forever together?  And without having the extra burden of stewarding LabVIEW to do the obvious: don’t load it it it isn’t used.

Link to post

Is that wise?  What if your API optionally interacts with some other API, and you have optional methods to support easy interoperation.  It’s possible that a particular programmer my want to use one or the other APIs by themselves.   Where do the optional VIs that depend on both go?

 

An example might be: I have a message-passing API, and a TCP API, and I want to pass messages by TCP sometimes, without tying these two APIs forever together?  And without having the extra burden of stewarding LabVIEW to do the obvious: don’t load it it it isn’t used.

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system).

Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable.

 

Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

  • Like 1
Link to post

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system).

Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable.

 

Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

 

A comment on smithd's description of "package management" with lvlibs - this type of management is common in our other Java and .NET applications for packaging dependencies. Discussions around how to manage packages in order to reduce dependencies / coupling between dependencies has been a common topic of discussion in the development world (outside of LabVIEW) for many years now. LabVIEW has it's own take on the same concepts. We typically try and use the "stairway" pattern for dealing with dependencies but that relies heavily on LabVIEW "interfaces/abstract" classes. It works most of the time; on occasion we have the same sort of bloat but that typically occurs when we have multiple copies of basically the same dependency loaded from different packages.

  • Like 1
Link to post

So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool?

 

I did.

 

(That is, after years and N00's hours investigating LVLIBs in the context of namespacing/distribution/building/linking/encapsulation/scoping/reuse/load time/dependency management and so forth. James, I am not surprised if you independently draw the same conclusion, and I'm interested to hear if you conclude otherwise.)

  • Like 2
Link to post

I did.

 

(That is, after years and N00's hours investigating LVLIBs in the context of namespacing/distribution/building/linking/encapsulation/scoping/reuse/load time/dependency management and so forth. James, I am not surprised if you independently draw the same conclusion, and I'm interested to hear if you conclude otherwise.)

 

Do you favor LLBs as the alternative? I'd be interested in hearing more of how you manage the same use cases.

Link to post

Massive no from me on LLBs. I do not need to distribute my code like that, so really have no purpose for them. As others have pointed out, no namespacing, no access scope makes these a stale technology (for my situation at least) in LabVIEW.

 

 

I still do use libraries though (and classes of course, which are also libraries), even with all the pain associated with the loading the entire contents etc. It troubles me too much me to have to manually namespace every VI, so I am not sure I will move away from libraries or some form of them any time soon.

Link to post

Food for thought:

If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?

 

Those outcomes are possibilities, not guarantees. Not every application has 8000 VIs, and in a lot of situations the careful use of libraries can be really beneficial.

 

I am not ready to give up on them yet.

Link to post

You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations.

 

Isn't that upside-down? LVClasses are specializations of LVLibs, so they inherit the strengths and weaknesses of LVLibs, not the other way round.

 

If LVLibs are improved, then LVClasses will automatically gain those improvements too.

 

 

2. A function per VI is a purely semantic imposition for dynamic dispatch.

 

If I've understood Jack's point correctly, the issue is that the one-function-per-VI system significantly increases the number of files in a project. This increases the effort required to write and refactor code (all LabVIEW code, not just LVClass code). This also amplifies the lags caused by widespread static linking.

Link to post

You are skirting around a couple of fundamental issues, not directly to do with LVLibs but with LVPOOP and are the reasons why LVLIbs fall short of expectations. I think you have seen and hinted at, but not articulated, though.

 

1. it is impossible to create LVPOOP components with zero static linking (this is trivial with an open VI and a LLB full of functions which can be loaded and unloaded dynamically).

 

It's tenable at worst, desirable at best, for an LVCLASS and its members to be statically-linked. Any desire otherwise could be an indicator of class design or object model that could use refactoring, or a desire for more appropriate language facilities (more on that later).

 

For an illustrated example, here's one annotated section of the diagram above:

 

post-17237-0-81410800-1417186519.png

 

The top arrow shows methods from a third-party hardware driver that are required by the application, the middle arrow is very likely an LVCLASS or LVLIB, and the bottom arrow shows unreachable, unused dependencies -- portions of the hardware API that bloat the application.

 

Although not ideal, this scenario of roughly ~30 unused source files may not be measurably bad. The birds-eye view of this application indicates ROI of refactoring this class probably isn't justified. Though, used in another application, that exact same library could cause problems (such as even further unwanted linkages, perhaps even some that break the application with unsatisfied dependencies such as uninstalled packages or platform-specificity).

 

Different application space yields different polarizing filters through which we choose tradeoffs. As library designers, it's worthwhile to consider our responsibility to enable our developer-end-users, and explicitly avoiding designs which cause them heartache.

 

--

 

I wasn't going to bring up Inheritance as another type of static linkage best cut with our figurative link scissors, but it's now relevant in the context of LVOOP. Inheritance, in and of itself in any language, represents a code smell worth investigating.

 

But... Inheritance! Dynamic Dispatch! This example demonstrates precisely the value of traits/mixins in an OOP language. With traits/mixins, we can achieve all desirable outcomes discussed above in terms of higher cohesion and looser coupling (and re-use!), by eschewing 1) suboptimal/incorrect inheritance hierarchies, and 2) classes that do too much, even if there appears "good reason" for the monolithic library (Hardware APIs for LabVIEW are notorious for wrapping serial protocols as one-command-per-VI in monolithic libraries. There are thoughts/considerations of dynamic versus static programming as another solution, but that's another thread).

 

Lacking Mixins in LVOOP, Inheritance sometimes is workably sufficient to describe and implement the real-world, but oftentimes it can't. Again, to be fair, it's healthier to focus on measurable negative value than pedantry, and oftentimes it's workable to incur these tradeoffs introduced by inheritance.

 

@ShaunR, for this reason, I don't think LVCLASSes fall short in the way you might be describing. (Except for one debatable behavior in the IDE, where all classes in a hierarchy are broken if one is, and where the explanation as to why in that link is tenuous, where the more desirable behavior is to throw run-time exception in the scenario presented in that link) The way that LVCLASSes fall short is by lacking Mixins, which provide targeted and precise linkages to atomic units of relevant code.

 

(for clarity, regardless whether industry is landing on the term Trait or Mixin, I support the construct that also provides extension of mutable state, not just method implementations, and certainly not just interfaces with no implementations. I think "Mixin" is most appropriate, its distinction from "Trait" being "Trait" might not connote further extension of state)

 

 

it is impossible to create LVPOOP components with zero static linking

 

tl;dr The design goal when designing an LVOOP object model is not necessarily to avoid all static links, but rather to intentionally design dependency vectors, especially recognizing and avoiding anomalies and incidental linkages that have detectable negative value. And, LVOOP needs Mixins.

  • Like 1
Link to post

@ShaunR, for this reason, I don't think LVCLASSes fall short in the way you might be describing. (Except for one debatable behavior in the IDE, where all classes in a hierarchy are broken if one is, and where the explanation as to why in that link is tenuous, where the more desirable behavior is to throw run-time exception in the scenario presented in that link) The way that LVCLASSes fall short is by lacking Mixins, which provide targeted and precise linkages to atomic units of relevant code.

 

Sorry Jack. Everything will be fine if only we had X,Y Z is just adding more goo to a sticky mess. I think this discussion needs to be taken to another thread so as not to derail the OP (any further?) as there are some very simple premises here that are being conflated.

Edited by ShaunR
Link to post

Food for thought:

If huge amounts of analysis and tribal knowledge is required to not write bloated, unscalable and buggy code with a certain tool. Is it not a better strategy to just not use that tool?

 

To carefully dereference "certain tool", if that refers to LVLIB, yes -- it's worth considering whether this tool belongs in our toolbox.

 

If "certain tool" dereferences to LabVIEW -- LabVIEW as a language is excellent and certainly not worth abandoning. Conversely, it's worth considering if you're not already using it. LabVIEW has rooms for significant improvement, but its syntax is currently unparalleled in programming, period.

  • Like 1
Link to post

Awesome chain of discussion guys.  Sorry OP if this is derailing the conversation but I think it still is relevant to the original question.

 

Making and using polymorphic VIs is a major pain point for several reasons.  And from a reuse stand point there isn't many other options.  Replacing polymorphics with XNodes (if every officially supported) I think would help because you replace the 40+ instances with a custom scripted VI.  No idea if it scales well.  Jack you mentioned replacing polymorphic VIs with their instance.  In my mind this is something that could be done quite easily with scripting for a while project.  This could be a VI that is ran periodically, possibly as part of the Pre-Build VI that could help clean up the project.  Did you ever make this scripting VI?  Could you see sharing it if you ever did?

Link to post

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.

  • Similar Content

    • By GregFreeman
      I am running calls to a various stored procedures in parallel, each with their own connection refnums. A few of these calls can take a while to execute from time to time. In critical parts of my application I would like the Cmd Execute.vi to be reentrant. Generally I handle this by making a copy of the NI library and namespacing my own version. I can then make a reentrant copy of the VI I need and save it in my own library, then commit it in version control so everyone working on the project has it. But the library is password protected so even a copy of it keeps it locked. I can't do a save as on the VIs that I need and make a reentrant copy, nor can I add any new VIs to the library.
      Does anyone have any suggestions? I have resorted to taking NIs library, including it inside my own library, then basically rewriting the VIs I need by copying the contents from the block diagram of the VI I want to "save as" and pasting them in another VI.
    • By Petr
      I'm not able to solve DVRs problem. See project file.
      1. IO.lvlib exists in two versions: one with single variables + processSimulation.vi that simulates process/machine i.e. takes outputs, calculates process behaviour and writes inputs; the second version of IO.lvlib has variables as IOaliases. Simply swaping these two versions allows to run project on real target with machine or to run project on PC without target/machine. Thats why I use these IO.lvlib variables.
      2. Every subsystem is an object/class with method DoSomething that calculates response to inputs and writes outputs.
      3. I¨d like to call these objects DoSomething.vi method in one loop. Thats why it's not possible to have inputs/outputs as terminals of DoSomething.vi
      4. I've tried to solve the problem with DVRs: every object is created by constructor including inputs/outputs DVRs initializing. However I'm not able to use DVRs inside DOSomething method. What am I doing wrong?

      One solution is to avoid loop call and spread all (about 50) DoSomething.vi calls including inputs/outputs terminals onto block diagram. But this is definitely not well arranged solution.
      Do you see anything wrong concerning my solution in general? How to access DVR inside class method? Any other ideas, comments? Thanks.
       
       
      IOrefs.zip
    • By drjdpowell
      I cannot figure this out.
       
      I made some changes to the private data of a class that caused the various unbundle nodes to get mislinked when they tried to auto-select the right new elements, leaving several broken methods.  No problem, I thought, I will revert to the previous clean copy in Source-code control (using TortoiseHg).   However, whenever I reopen the class, the unbundle nodes are still mislinked and VIs are broken!   I reverted the entire codebase to a week ago to be sure I had a good copy, and I rebooted the computer — still broken!   All my methods, even the unbroken ones say they need to resave because “Type Definition modifiedâ€.
       
      My question is: what is modifying my “Type Definitionâ€?   It can’t be any of my source code, so what can it be?   Where is the change located on disk?
    • By cgiustini
      Hey,
       
      I am going to be developing a lot of .lvlibs for reuse by others, and I would like to quickly generate documentation for them. I started programming a tool that recursively looks through a library by using the "Owned Items[]" property and iterating through those in order to find folders, .vis and .ctl. Then using the "VI Documentation VIs", the tool would just output a word document that contains VI icons, terminal lists, and descriptions. Does a similar tool already exist? I would gladly use such a tool if it already does.
       
      C
       
       
    • By JimboH
      I've been using Labview for 6 years now for research and one of the most confusing things for me is how code is supposed to be managed. I have been using Tortoise SVN with folder organization but with things getting more complicated I am starting to wonder what the "right" way of doings things is.
      I've looked through a variety of posts and official documentation and haven't found what I am looking for (or haven't realized it was what I needed).
      I'm using LV2009 32 bit, JKI TotoiseSVN Tool 2.2.0.186 (demo), Tortoise SVN 1.7.6, Win 7 x64, and have little interest in actual code deployment.
      Features I am looking for:
      - avoiding cross linking problems
      - prompts to save a vi only when it has been changed
      - svn integration
      - code that works with multiple developers instead of corrupted files (mainly thinking about project files)
      My code base consists of project or modules (not lvproj) just a set of code in a directory & subdirectories. When I am running a program, many of these modules will run together and collect data, with a messaging system in between where necessary. In addition I have generic code libraries (not lvlib), with generic functions (math, string, table, server, etc). It seems like my code libraries should be lvlib files. After some reading it seems like Project Libraries can be used for preventing namespace collisions. On a side note the term Labview Project Libraries is very confusing because I think of Labview Project Explorer which I have no gathered does nothing for changing the namespace. I did happen to find this link, which helped get me started but I'm still not understanding some things.
      As a general rule I pretty much want library membership to always apply to files that are in my libraries directory, which doesn't seem possible.
      Question 1: How do I delete a library file via SVN and remove it from the project. I am using the JKI TSVN toolbox and removal of the file doesn't seem to effect removal from the library.
      Question 2: If I create a vi and later decide to move it into the library, how do I accomplish this in Labview with SVN tracking. For example, if I create a vi in one of my modules and realize that it is fairly generic and would be better in a library, how do I move it to the library (ideally on disk and into the library file) so that both Labview and SVN are happy. Another situation might be moving a file from one module to another module, ideally I could move both library association and disk location.
      Question 3: If I am running multiple modules, how do I ensure that they have no namespace collisions? Should these be libraries as well? Do I only need a project if I want to deploy my code?
      Question 4: When someone creates a vi outside of the library but in the library directory how can this be detected and fixed?
      Question 5: Is there any way to get better svn integration into the lvlib and lbproj right click menu? My current approach would be to do this through the tools menu (tools -> TortoiseSVN -> rename). Side note, this doesn't doesn't currently work on my computer although the actual TortoiseSVN through Windows Explorer works just fine.
      Question 6: My files are constantly prompting for saving. It seems like most of these are changes from other files and not the file I changed. Since I don't know really know how this works I am not sure what exactly is going on. The end result though is that I want to minimize version changes (as tracked through SVN). I seem to remember reading somewhere that in LV2010 you can separate source code and compiled code. Thoughts? Would this be fixed by better lvlib and lvproj usage or is something else going on?
      Thanks,
      Jim



×
×
  • Create New...

Important Information

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