Leaderboard

Crazy like a fox!

> Our could we hack some update code in congregation with NI? You don't have to hack. Suppose Alpha.vi calls Beta.vi. When Alpha.vi saves, it writes down the path to Beta.vi in its save image. When you load Alpha.vi, it tries to load Beta.vi at that path. If it doesn't find Beta.vi, it searches disk. Now, modify Beta.vi to be inside Yoda.lvlib. Now load Alpha.vi. What happens this time is Alpha.vi goes to the location it recorded, and it finds a file named Beta.vi. It loads it, and discovers that the file is actually Yoda.lvlib:Beta.vi. That's ok. Normally on load we require that qualified names match exactly, but we make an exemption for "caller last saved looking for an qualified name with no library at all and caller now found -- at *exactly* the same path (no searching) -- a VI of the right file name but different library name, so count that as a match." Now, if Alpha.vi is saved looking for Yoda.lvlib:Beta.vi and you then move Beta.vi out of Yoda.lvlib and into Yolanda.lvlib, now when you load Alpha.vi, it finds Beta.vi at the right path, but the qname doesn't match, so it considers the subVI to be missing, and searches accordingly. This is why upgrading from no library to library is easy. It is why upgrading to a different library ownership requires the same machinations as renaming the VI file itself. > ...though I do now appreciate having the smaller libraries, as loading any one > VI from a .lvlib loads the whole library. (If any does know how to do this, > please tell me -- I'll feel silly for 5 minutes, then really appreciate it!). There are five library types: lvlib, xctl, lvclass, lvsc and xnode (the last of these being somewhat mythical). Lvlib and lvsc do NOT load all of their member VIs. The others do. They do list all their VIs in the project tree, but the VIs are not loaded into memory. All of them do load their nested libraries into memory. > I wouldn't want the polymorphic VIs to be public and > make the specific instances private, main reason is that > Real-time cannot cope with variants, and you couldn't bypass > the public polymorphic VI by calling directly into the specific > instance you need. Um, yes, that's the whole point. You couldn't bypass the poly VI. Under what conditions is that undesirable?

Hey all, As you may know in order to have a toolkit placed on the LabVIEW Tools Network it has to pass Compatible With LabVIEW certification. One of the requirements for the Compatible With LabVIEW program is that tools may not be located on the top palette, but should exist within one of the existing top-level categories such as Programming, Measurement I/O, Data Communication, etc. The reason behind this requirement is that the LabVIEW Palette can get quite bloated when you have many toolkits/modules installed. With just the full Developer Suite installed, there are over 20 top level palettes. Adding third party tools to this list will very easily bring the functions palette to grow off of the screen for a standard 1024x768 monitor. The secondary reason behind this is that this layout will help users find the functions more easy that will help them. For example if the user is looking for some data communication protocol, they are more likely to look in the "Data Communication" palette then in a sub-palette called "My Data Protocol" under a top level "DavidSoft Inc". I wanted to point this out so as you all start creating their toolkit for submission to Team LAVA or the LabVIEW Tools Network, you can take this into consideration ahead of time. However, with many things in our program, nothing is black and white. If there are special cases in which a toolkit especially should be on the top level, we will consider letting it go as such. One of these cases is OpenG. Since OpenG has a long-standing reputation and is known to be found on the Top level, it would be more hurtful than beneficial to require it moved to the Programming palette. If anyone has suggestions or ideas of other corner cases that would benefit from this top level location, or have comments or opinions for or against this policy, please feel free to bring them up here for debate/discussion. --David Out

AlexA: You are reinventing the wheel. No, actually, not the wheel. Messaging frameworks are fairly complex and way outstrip the wheel. But the jet engine... yes, you're reinventing the jet engine. And the problem is, when reinventing the wheel, most people get it right. No so much on the jet engine. This is NOT meant to insult your skills. It's just that I've spent years reviewing many people's messaging frameworks, and all of the ones rolled by individuals had some serious lurking timing issues. The frameworks that were built, shared with the community and refined are solid. I don't know what you're building, but I pretty much guarantee that LapDog, JAMA or Actor Framework can handle it. AF maintains simplicity relative to the other frameworks. LapDog is more powerful and JAMA is more powerful than that. Each power jump comes with additional complexity. Collectively, we give you enough thrust to reach the heights you aim for... or enough rope to hang yourself, depending upon your point of view. :-) Since AF is my baby, let me lay out how you'd use it for this case: Prime actor is Mediator. You send "Launch Producer" or "Launch Consumer" messages to Mediator. When sending "Launch Producer", you include in the message some ID of the type of data this producer produces. Producers generate data. They collect that data in their local state unless/until they receive a "Here's A Consumer" message, at which point they send all their pent up messages into the consumer's queue. This is important -- and is a bug that I'm guessing exists in what you proposed -- because the lifetime of the queue is tied to the consumer, not the producer, so you don't have vanishing queue problems when a producer disconnects before the consumer is done processing all the values. Consumers consume data. When Mediator spins one up, he gives the consumers the list of producer types and the producer send queues (does this directly during spin up... no need to pass a message to the consumer). The consumer picks the one she wants and sends "Here's a Consumer" message -- no need to go back to the Mediator. Thereafter, consumer just sits in the loop and eats data until she gets a Stop message. If you give me a couple days, version 3 of the AF all polished up will be posted at the site I linked earlier. If you decide to use one of the others, great. Just don't build a custom system unless you just cannot make the others work. Please. We lose too many programmer heroes when they get sucked into jet engines.

Is there a list of Pros/Cons anywhere? Perhaps a list could be maintained in the original post of this thread?

I recently took the CLA (on the 2nd of this month). My proctor did tell me they changed the format for the CLD in giving the front panel. That could have saved me a good 10-15 minutes back when I took it. For the CLA, I was given the sheet of requirements and a blank USB drive for submission. I thought the CLA was one of the hardest tests I've ever taken, mostly due to the 4 hour requirement. And for what it's worth, I got my results yesterday and I passed!

I am confident that the OpenG team will be able to solve this problem technically, without causing re-linking issues (with the help of a tool etc...). If not, that would be a reason not to migrating IMHO. It is my understanding that VIs are not loaded into memory, only the Library (.lvlib) is and any child Libraries. If that child Library is a Class Library than yes, those Class method VIs will be loaded into memory as per the how Classes work.

One of the flags (mods) of the Mouse Down event is 'Double Click': Ton