Jump to content

Recommended Posts

I've been using OpenG Builder for several months for distributing my reuse code to myself. All along I have been using OGB's namespace feature. A couple weeks back I was demonstrating OGB to some coworkers and the one of them raised the question, "Why not just use the .lvlib namespace feature?" Aside from the extra step of wrapping all my reuse projects in a lvlib to make use of the namespace, I didn't have a good answer. Anyone want to take a stab at comparing/contrasting the two namespace implementations?

Tangential question: Do LVOOP classes automatically generate their own namespace making OGB and lvlib namespaces unnecessary?

Link to comment

A library is a namespace. There are many types of libraries. Among these are the .lvlib file and the .lvclass file. So, yes, there is already a namespace for the VIs in the class. Now, if you want to namespace the class itself, put the class into a .lvlib.

I've never heard of the OGB system so I can't do the compare/contrast that you asked for.

Link to comment

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM)

OGB = OpenG Builder. (I edited the OP for clarity--I used only the acronym the first time around.) OGB creates namespaces by appending suffixes to filenames when the code is built.

QUOTE (Aristos Queue @ Oct 28 2008, 04:25 PM)

A library is a namespace. There are many types of libraries. Among these are the .lvlib file and the .lvclass file. So, yes, there is already a namespace for the VIs in the class. Now, if you want to namespace the class itself, put the class into a .lvlib.

So if I understand the ramifications correctly all of the following are true...?

1. Assume I have a Boat class and a Car class that are independent of each other. Both classes have a Start method. I am safe using these classes within a single project since the two Start vis belong to different namespaces.

2. Assume I have one Honda class that inherits from a Car class and another Honda class that inherits from a Lawnmower class. Since the class itself isn't namespaced, I'll run into conflicts if I try to use both of these classes in a single project, regardless of whether or not they have any common vi names. (If this is true, that implies namespaces don't propagate down through a class hierarchy. i.e. Instead of Car.Honda(.Start.vi) the namespace is just Honda(.Start.vi.))

3. VI filenames are independent of the namespace that contains them, therefore VIs with different namespaces may have the same filename and I may run into occasional conflicts if I'm not careful to separate my namespaces into different directories in both source and distributed code.

Are there other namespaces outside of .lvlib, .lvclass, and (presumably) .llb files?

Link to comment

QUOTE (Daklu @ Oct 28 2008, 11:31 AM)

Anyone want to take a stab at comparing/contrasting the two namespace implementations?

I use the OGB namespace feature to build .LLB files for sets of plug-in VIs. The LLB contains all the top level plug-ins and all of their sub vis, namespaced to the name of the LLB.

This way, I can call plug-ins from more than one LLB at the same time, each with different revisions of a common sub-vi and be sure that the plugin loads with the version of the sub-vi it was tested and released with.

I do not think you can do this with LVLIB files. I don't think this is what they were intended to do. A source file on disk cannot be a member of two different LVLIB files. In my case, i want to build my LLBs from the same set of source sub-vis but lock down the version I built with so I don't have conflicts when using multiple versions from my app.

It does add an extra step to my build process (first need to build the LLBs with OGB and then build an installer for the LLBs with LV).

Finally, I am not aware of a means to build an LLB from a set of files and remove the diagrams and typedefs within LV. Even if you could do this, they don't offer a way to namespace them like OGB does.

Hope that helps explain the value of OGB to your coworkers.

-John

Link to comment

QUOTE (jlokanis @ Oct 28 2008, 06:10 PM)

I use the OGB namespace feature to build .LLB files for sets of plug-in VIs. The LLB contains all the top level plug-ins and all of their sub vis, namespaced to the name of the LLB.

This way, I can call plug-ins from more than one LLB at the same time, each with different revisions of a common sub-vi and be sure that the plugin loads with the version of the sub-vi it was tested and released with.

I do not think you can do this with LVLIB files. I don't think this is what they were intended to do. A source file on disk cannot be a member of two different LVLIB files. In my case, i want to build my LLBs from the same set of source sub-vis but lock down the version I built with so I don't have conflicts when using multiple versions from my app.

I think I'm following you... it sounds like you are building LLBs to take a snapshot of your reuse code and by using the snapshot in your application code you avoid breaking the app with future changes to your reuse code. You avoid conflicts by giving each snapshot a unique namespace via OGB. If that's correct, couldn't the same thing be done by copying your reuse code to a different location and wrap it in a uniquely named LVLIB, since, as near as I can tell, that's essentially what you're doing with the LLB. (With the obvious difference that you're wrapping it in an LLB instead of an LVLIB.) What am I missing?

Link to comment

QUOTE (crelf @ Oct 28 2008, 09:30 PM)

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

Link to comment

QUOTE (Daklu @ Oct 29 2008, 12:54 AM)

Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for n VIPM licenses is sure to raise a few eyebrows.

That is so sad - I'm sorry to hear that your managment is like that.

Link to comment

QUOTE (Daklu @ Oct 29 2008, 02:27 AM)

XControls (but namespacing is a side effect, the main target is creating a new control)

LLB files don't do namespacing, the actual VI name (as it can be called via a Open VI reference function) stays the same so you can't have to 'Start' VIs in two LLBs in the same project.

QUOTE (Daklu @ Oct 29 2008, 06:54 AM)

As much as I'd like to use it, cost is the barrier stopping me from using it. Yeah, it would pay for itself by saving me time, but my incremental cost is somewhat hidden while cutting a PO for
n
VIPM licenses is sure to raise a few eyebrows.

You don't need n only one will be enought (i assume) just for the person that is creating packages, loading packages and installing them needs no license, however you could tell your management that you have a bargain 10 licenses for the price of one.

Ton

Link to comment

QUOTE

That is so sad - I'm sorry to hear that your managment is like that.

My experience is that management in most places is like that. VIPM isn't required to do the job, it just makes certain aspects of it easier; therefore it is an unnecessary expense. On top of that Labview isn't that widely used in my group...

QUOTE ( @ Oct 28 2008, 11:34 PM)

10 licenses for the price of one.

10 for 1? That I might be able to sell, but I didn't see the offer on the VIPM website.

Link to comment

QUOTE (Daklu @ Oct 29 2008, 12:11 PM)

10 for 1? That I might be able to sell, but I didn't see the offer on the VIPM website.

The idea is that you only need one license to build packages. Then anyone who want to use the packages downloads the free version and installs them. You can tell your manager you're getting 10+ licenses because he/she doesn't know that everyone else is getting the free version :ninja:

Link to comment

QUOTE (crelf @ Oct 28 2008, 07:40 PM)

Maybe Stephen's heard of it as the "OpenG Builder" and not just by it's acronym of OGB?
Ah. Yes. That I have heard of, and even seen demos of. :-)

In another context, I might have gotten OGB as OpenG Builder, but as "OGB's namespace feature", I was searching the internet for some sort of naming scheme like Hungarian notation or somesuch.

Link to comment

QUOTE (Daklu @ Oct 29 2008, 03:11 PM)

My experience is that management in most places is like that. VIPM isn't required to do the job, it just makes certain aspects of it easier; therefore it is an unnecessary expense.

I'm not so sure - if you can show a positive ROI, there aren't many managers in the world that wouldn't be at least interested in hearing what you've got to say :) Your time is worth a lot more that a license of VIPM (TobyD is soooo right about the 10 for 1 model), and buying tools gets you back to doing what you're really paid for. You wouldn't try to write a replacement for Microsoft Word - you'd just pay the license fee and use. I know that's an extreme, and you need to weigh up the functionality vs cost model, but in my experience VIPM is easily justifiable. We write our own tools, and the support that's required to keep them going is costly (imagine if you left the company and someone else took your place - how much IP do you have in the process that you're carrying out that's not on paper?) Not buying tools like VIPM stops you from doing your real job, and that's what your clients are paying for - that means that you need to hire others to share the load that you're supposed to be doing, so there's more cost there. Ok, I'll get off my soapbox now.

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
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
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.