Leaderboard

I'm sure someone else can chime in if I'm wrong about any of this, but from what I've seen the VIP and OGP file format is very similar. They both are essentially a zip archive, with file groups, and a spec file, and I believe an icon file. You can unzip both programatically, and read the spec file if you want to read information about the package. The spec file is in an INI file format and you should have no problem reading. The main difference I know of, is the VIP files cannot be created or edited manually. You cannot take an existing VIP, extract it, add files, then rezip it and use it. This is because there is added checksum information telling VIPM that the package has no corruptions. I don't believe the mechanism to recreate this checksum is documented so editing the package after it is built is prohibited. There is no such restriction on OGP. Extract, replace, and zip works just fine. Both can be installed using VIPM.

I'm having a separate GChat about this issue, and will copy what I just wrote moments ago: "the main prob is that filenames (rather than embedded GUIDS) are used as identifiers in class hierarchies. it's frustrating. same thing bites you with Dynamic Dispatch VIs -- they must have the same filename (which I personally find annoying)... filenaming convention should be abstracted from class functionality" So, I think we're independently coming to the same conclusions here, crelf *** EDIT: and this is not a bash against the current convention, I'm sure it exists for good reason. It's just that I'm running into problems, and just trying to flesh out the best practice ***

Important Point of Clarification: uploading code to LAVA does not automatically limit its use to the BSD protection/limitations. Code posted to threads are, by default, covered by Creative Commons, and uploaders of submissions to the Code Respository are given a choice on what license to apply to their Code Repository submission - we put the control in the hands of the creator by allowing them to select from a list of pre-defined licenses (the most common ones), but we also allow the upload to be covered by any other license - just include it with your submission. We offer this flexibility to allow the creator to choose how they want their code to be used - rather than us taking control of it (which is completely the opposite of what lavag.org was founded on, and continues to strive for today). I'm struggling to see how any of this issue can be at the feet of LAVA, as we have an as open system as I can imagine. So here's a constructive suggestion: rather than pushing LAVA members to upload their code to ni.com so NI can do whatever they choose with it (include selling it for profit without passing any of those profits on to the creator), maybe NI should suggest an appropriate license that people should use on lavag.org (or anywhere else) that NI can work with. Even if it's one that's not currently in the list, members could include it with their submission. We could even add it to the standard list, if that's what our members want. We could even make it the default selection, if that makes sense. We're here for our members - we're not resisting changes - if you want us to change, and it makes sense to Mike, we'll do it. It's really as simple as that. More information on how the LAVA Code Repository works is here: http://lavag.org/top...repository-work

Here is a strange request but I am casting a wide net to see if anyone has seen a solution to this. I need a device that can route a USB dongle to a DUT's USB port. I need to be able to simulate the insertion and removal of the USB dongle without physical access to the dongle. I need this to be controlled via Ethernet. Ideally, this product would allow me to insert a single USB dongle and route it to multiple DUTs simultaneously. If that is not possible, I could insert multiple dongles and route them 1 to 1. So, why do we need this? Well, our product is designed to boot off a USB dongle and get us a basic OS that we can then use to load a full test OS from a network server. But, once we install the network OS, we want to reboot and not see the dongle anymore. Right now we need someone to physically pull the dongle from the DUT. We would like to automate this process. thanks for any ideas, thoughts or sympathy... -John