Leaderboard

Write your own compiler.

A question from the twittersphere:

See this - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-property-of-Method-to-indicate-if-an-input-of-a-sub-VI-is/idi-p/926281

Just to add some real world experience from someone who has lived on both sides of the fence: For many years I used Windows PCs professionally and at home (having built many myself over the years). I still use Windows7 at work everyday. However, when our last Dell laptop died, I decided to give the Mac a try. My wife already had an iPhone and I was impressed with the quality and ease of use it offered. Long story short, we now have 2 MacBook Pros, 2 iPhones and an iPad2. The first MBP is used for what I call family activities. Photos, web browsing, kids games, school projects. All the things that pretty much any computer can do, but the Mac makes it easier to get done. No extra SW to buy in many cases and very few bug or compatibility issues. The second MBP is mine. I use it for music production (hobby) and consulting (LabVIEW). I run LabVIEW under MacOSX and in Win7 VMs. Whatever is needed for the job. The iPad is used as a consumption device. The kids have lots of games and learning software (it is amazing how a 5yr old can figure out how to use iOS with basically zero instruction). I use it for Twitter, web browsing, video streaming, news apps, etc. My wife uses it for email (as noted, you only get one 'user' per device in iOS), Facebook, web and TV. It is a great device when you just want to look up something quick or want to sit on the couch and 'consume' content. I would never use it to write long docs or even attempt to do real work on it. It is not intended for that purpose. As for the debate about Apple vs the rest of the companies out there, I will say this: When we were a PC house, I spent a great deal of my time fixing problems with our PCs. Software bugs, HW compatibility issues, random weirdness that seems inherent in all Microsoft software. After switching all that has gone away. I know a great deal about fixing Windows but I know very little about Unix or MacOSX. Fortunately, the few times I have had to figure out how to fix something on the Mac, it has been very simple to diagnose and correct. So, if you like playing an IT support person in your free time, by all means get a netbook, Andriod tablet or whatnot and hack away. But if you want to come home from a long day at the office and just use your devices, then seriously consider an iPad. As for all the comments about Apple being a 'walled garden' I'll add that their garden is 1000x bigger then the rest of the ecosystem out there (as far as apps go) and a wall is not such a bad thing if it keeps out the snakes and bugs and other things that waste your time. In the meantime, I am patiently waiting for my parents old Dell desktop to die so I can get them to move to a Mac. Then I will finally be able to eliminate 'IT Support' from my list of job titles. -John

I released it specifically so other LV developers can use it in their day-to-day work, even if you are hiring out as a contractor/consultant. I have no problem with anyone using it as part of a customer's application or including it in the source code given to the customer. To be honest I have mixed feelings about people redistributing it to other developers as a toolkit and claiming it as their own. I don't really like the idea of someone else selling LapDog as a LV toolkit, but I haven't specifically taken steps to prevent it and I don't anticipate doing it in the future. I've considered a 'shout out' license, which means if you use it in a for-profit endeavor you have to drop me a note letting me know--just 'cause I'm curious how it's being used. But I haven't done that either. So no, there are no restrictions on its use. You can use it in a commercial application. You can give it away to your friends. You can change the banner color and re-release it as LapFrog if you're so inclined. It's free, it's open, and it's there to be used.

Unfortunately, NI Tech Support was dead wrong when they said, "Unfortunately you cannot use file paths that are inside build specifications (e.g. exes, dll, lvlibps)". I'm surprised you didn't jump back at them, since you had just proven that you can, in fact, use file paths inside lvlibp; You did it for Child 1 and Child 3 classes. It will actually work for Child 2 in your code if you form the path to the lvclass like this "Loading Plugins\Child Library\Child 2.lvlibp\Child 2\Child 2.lvclass" The reason for this is that Child 2 depends on your CommonLibrary.lvlib. When LabVIEW builds this into a packed project library, it retains the disk hierarchy inside the lvlibp so relative paths between your code and any of it's dependencies remain intact. I'm not sure where it puts vi.lib stuff though, you'd have to ask NI about that. Thankfully, LabVIEW helps us out with this issue! Drill down in the tools pallette to 'File I/O>>Advanced File Functions>>Packed Library' and you'll find some helpful VI's (two of them in labview 2010, and one extra new one in 2011). The new function 'Get Exported File Path' in LabVIEW 2011 is precisely what you need in this situation. Wire the qualified name to it (like "Child 2.lvlibp:Child 2.lvclass") and it outputs the path to that file within the lvlibp. In 2010 you'd have to get the whole list of exported files and paths and search for the one you want. If you wire this path to 'Get LV Class Default Value' you won't get error code 7 anymore. I plan on revising the code and presentation I published in NI Community/Large App Development to explain all this. I find this method far superior to source distribution for a plug-in architecture because source dist. inevitable results in nasty name-conflicts plus gives you a big messy load of source files that must be carried around with your build application... yuk!

I have seen this error a few times when the application builder has not managed to successfully built a valid executable but hasn't returned an error either. Last time I saw this error was when there was not enough memory in the build machine for LabVIEW to build a proper executable. As a result the executable didn't really contain anything and the final size of the executable was too small. When executing it, you got this error, which was natural because the executable was corrupted. The problem really was in LV application builder. We fixed the issue first time by getting LabVIEW to address more memory in 32-bit machine during the build and the second time by moving the 32-bit LabVIEW used for building to 64-bit machine.