crelf

That must be a new feature - our VIPCs rarely have their packages inside them: they usually point to a location on a newtork server. Say I'm not using the enterprise edition to manage a repository: can I still have my VIPCs point to network location(s)?

It depends. We do most of our development in the earliest version that we need to support *in active projects*. You can create VIPCs with the Professional License. Geez - if it was real beer I might have thought about it The enterprise license is used to *manage* the repository, and is usually on the PC of your designated librarian - there's not VIPM software on the server where your repository resides. That looks right to me.

Yeah - sorry about that - I should have made a note in the thread that it was being split. Well, that's not really deprecation - deprecation is whan, as the reuse library manager guy, you mark a reuse component as no-long-to-be-used-in-new-projects. This means that existing code that depend on it can still access it, but new projects need to jump through a loop to get to it (you usually only deprecate a reuse component when a new component exists that superceeds the deprecated component). You can save a snapshot of yout installed packages by creating a VI Package Configuration (VIPC). You can either embed all of the packages inside the VIPC, or (more commonly) refer to packages that exist on a common location (that's how we do it). These "snapshots" are saved on a project-by-project basis, which is great for a few reasons: we can bring a new developer onboard on a project very quickly (they just apply the VIPC for the project and they're ready to go), we can switch between projects that use different reuse library component configurations quickly, and we can put the reuse configuration for a project under SCC (great when a customer calls us three years down the track for a minor software mod - we can quickly get our LabVIEW configuration back to what it was when we originally worked on the project). Note: all of this is now embedded in the lvproj - so when you open a project, you're prompted if you'd like to apply the VIPC for that project (if it's not already applied). Also, when you close the project, you're prompted to scan the project for any changes in the reuse components that you're using, and if you'd like to add those to the project's VIPC <- this is a very cool and important feature that you won't get from using SCC. Awww - that's a shame. Especially since the guys did so much work to get almost everything in there under the BSD license I can't really answer either of those questions Let's just say that it took a short amount of time to develop the process, but the it took longer to document it (we have very well-defined processes at V I Engineering, Inc. - it's something that we're extremely proud of). I haven't heard anything in the last 12 hours or so, so let's hope that all got some sleep last night!

That's a good point - you should report that to the moderators.

I'm glad you asked - they're right here. Sumission instructions are here.

Sure - but then how do you manage the reuse library? VIPM allows deprecation (it's not an important feature - until you need it ), as well as dependancies (a really really important feature) that track between the versions of the library components, and you can create reuse snapshots (useful not only when baselining a project, but also when switching between projects that depend on different versions of different components: don't laugh at me - it happens! ) All that, *and* a tidy methodology of distributing your reuse components, *and* access to the OpenG packages too (if you use OpenG, your users already have a copy of VIPM installed, right?) Besides, it's just so much more organised. We have a formal process in place that controls how and when items get into our reuse library (we don't want just anything in there, potentialy taking down our projects, plus we don't want duplication, plus we need a controlled method of getting updates out to users, etc, etc, etc). I'm sure Jim would butt in here and give you a billion more reasons on why SCC is so difficult to manage, but his missus Beth is currently in active labour to deliver the kingling - we're all thinking of you Jim and Beth!

That's right - your submission has to be reviewed and approved by a "LAVA Certified" team member. It's one of the strengths of the LAVAcr over other forum reposotories - we only let code in that meets the LAVAcr standards.

Not really - what you're proposing (as far as I can tell) is a monolithic reuse library - read here and here on why that's a bad idea. Having a monolithic reuse library is fine to start with, but then becomes unmanagable over time (trust me - it's happened to companies that I've previously worked at - twice! )

You guys sing that one as well?!?! Wow - I thought it had limited range...

Yeah - using SCC doesn't *manage* your reuse library (and, hence, the reuse in the projects that you work on) - it only distributes it. We used to use SCC for our reuse, but it's next to useless when looking at reuse on a project-by-projcet basis.

I actually LOLed I'd love to see them playing "pong" on that! No, but I've seen a kookaburra do it - little bastards used to steal meat off our bbq on the deck

Microsoft isn't a dirty word here - you're thinking of info-MacVIEW

The last job I did that required translations had a bunch of them, and the file format our translation code uses was compatible with the output we got from the translation services (they would give us an Excel file, we would save it as tab-delimited ASCII and we were done).

We used to, but binned that when the NI product came along.

Well, yes and no - the unit test framework paradigm is a little different to the xUnit paradigm, but the NI toolkit can help with both test-driven development and it can produce regulated industry artifacts. Also, the NI toolkit doesn't require you to write code (except for setup and teardown, which, essentially, almost every test needs). I don't know your situation fully, but that sounds wise.

If ya'll think it's worthwhile enough, I'm happy for someone to toss it into the LAVA Code Repository.

I'd give AVT a call on 877-USA-1394 (see what they did there? ) - the staff are very knowledgable. As an aside, I'm personally a big fan of AVT cameras - we almost exclusively use them on our projects: http://goavt.com/

IMHO the JKI product would be useful for test driven development, whereas the NI Unit Test Framework extends that to include traceable artifacts.

That's totally valid. I'll mention it tomy mate that the survey should have been designed differently. I had considered that, but I didn't think that there was enough in your post to suggest you were being silly That's what she said.

No worries - I'd have done it earlier, but I thought it was already there for some reason. Hopefully it'll get some good exposure over there.

Then the answer is easy: stop paying for all the licenses.

The idea is that the bag is reuseable - you put food in it, eat the food, wash out any leftover food, reuse. For example, most people wouldn't put a fish in a container for storage, take it out, then put bread in the same container without washing the container first. Unless they like fishy bread, of course.

or does it?

A buddy of mine is doing his masters in business (or something boring like that) and part of his thesis is managing the marketing of a product. He's create a survey - if you've got about 45 seconds spare (well, you've already used some of that to read this post), I'd appreciate it if you could fill out this annonymous survey.

I use the keyboard in this picture from HP (sorry I don't know the model number - will try to remember to look when I get home) - it's simple, full featured (without too much crap) and works great. I also use the remote in that picture too - for both my HP HTPC and my Sony media extender - it works great, and it's nice to have the same remote in two rooms.