Aristos Queue

What's your actual goal? I mean, why do you need the names of the ancestor classes at runtime? What are you trying to achieve? I ask because the reflection stuff works in editor environments, but not runtime environments. We may be able to propose an alternate approach than getting the class name because i doubt you're going to find a satisfactory solution to that exact problem... and we haven't made the reflection API part of the runtime engine because a) it would add to the size of the runtime engine and believe it or not, there is some effort made to keep the thing from becoming ever larger and b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

Post this to the Idea Exchange. I think it is worth tracking as an idea.

Speaking as a judge, I did confer with the other judge on this one, and we decided that it visually looked like a 7 segment display and that was enough. Honestly, we never imagined Robert's solution when we were brainstorming how each of these problems would be solved (we have to verify that they're actually doable in a reasonable amount of time). Once we saw it, we felt it was a reasonable approach to the problem. Consider this... he made a 3x5 grid. Had he made a 9x15 grid, using the same basic idea, you would have seen bars of LEDs, clearly visible as segments. I don't think there'd be any argument then. If the idea is generally valid, then I think we give it to him for having the simplest form of that idea.

I hate to tell you this, but if you're creating a new copy of the conversation that will branch off the old one, that's called a "fork", not a "spoon". :-)

The Actor Framework that I mentioned earlier is now available. Read about it here:

[This message was also posted here on the ni.com forums.] All of the presentations for NI Week 2010 are available in the NIWeek 2010 Community. If you attended NI Week, you should already be a member of the community. If you did not attend NI Week, click on the link and request to join the community (you will have to create a user profile if you have never used the NI Community pages ever before). Approval to join the community may take a day or so. Once you are a member of the community, you can go here to get a full copy of the "LabVIEW Classes: The State of the Art" presentation that Mike Benza and I gave, along with all the VIs used during that presentation. I spent the bulk of that presentation discussing my new Actor Framework.Many users have spent time developing mechanisms for starting up multiple top-level VIs, establishing communications among those VIs and then tearing those VIs down when the app completes. It is easy to make a system that works sometimes. It is very hard to make one that always starts cleanly (so no VI misses early messages), avoids deadlocks during communication, and actually shuts down all running processes. Very hard. Multiple users have posted their attempts to me. At the same time, I've been looking at state machines, that very common design pattern for LV programmers, and lamenting that if I build one state machine for a project and then I need that same machine but with just one more frame of the case structure in another project, I have to copy all the code. How do I build a state machine that I can inherit from and extend? These twin challenges lead to the development of the Actor Framework. It incorporates ideas from several similar frameworks developed by users (both internal and external to NI), and adds a few extras to make it really robust. I found one CLA who lives near NI to test drive the framework in a real-world application. That work is still ongoing, but so far, the framework appears to function well, with good performance and no missing functionality. More importantly, it is easy to pick up and learn -- we decided that was important since so many of the macroscale frameworks that have appeared in the last five years have a steep learning curve. The framework should not be considered "finished". The presentation includes some notes about further refinements that we have planned, and I am open to further suggestions from the community. I would like to see this develop into something that we can share next NI Week as a polished set of VIs and classes that any of our users can pick up and run with. Please post any comments you have about the framework on the community page where the framework can be downloaded. That way any conversation about it is centralized instead of being spread across the forums, LAVA and the NI Community. PS: The Actor Framework is saved in LV 2009. You do not need LV 2010 to view and use the framework.

233951 is a duplicate. It is also fixed in LV2010.

CAR 236169 is fixed in LV 2010.

Daklu is correct -- the behavior was actually a bug in LV 2009. This CAR is fixed in LV 2010.

At the LAVA BBQ last night, I introduced the community to Songs For The LabVIEW Programmer, a little project I started in response to user requests at last year's LAVA BBQ. Admittedly, not all of the users were sober at the time they made the request for "some LabVIEW drinking songs", but I believe it is important for NI to be responsive to our users, even the inebriated ones. :-) The songs are now posted here on the NI Forums. There are some drinking songs and also some teaching songs if you have kids who are learning LabVIEW. I particularly recommend "The Execution Highlight Went Down The Wire Route." Very educational. And it has hand gestures. ;-)

And if Justin tries to share with you any new Australian slang that he has learned recently, run. Don't ask questions, just run. A ticket to the LAVA BBQ isn't worth that kind of trauma.

"The Gravitational Constant is a variable in my equation." Variable does not mean necessarily changeable. It can mean just value. A cluster is a collection of values. Those values might not change. If they don't change, they are constants.

I tried to puzzle it out from your text description, but I couldn't get a good grasp on the situation. If you can post VIs, that would help a lot.

Kudos to someone named Miha who created The Flea's Knees font and posted it in her blog for all the world to use. In this font, all the alphanumeric characters in the plain roman face are no more than 4 pixels wide, yet surprisingly readable. Then she gives us italic, bold and bold italic forms! The font takes advantage of subpixel coloration. There's no font file that you can install to type in this font (because it is a full-color font, the normal type interfaces don't work right), but perhaps someone will want to extend the icon editor to allow typing in this font. Here's the finalized images from Miha:

No go. You need a *constant* value, something that can be set once and only once in the entire run of the app. It cannot take *any* inputs and its only output is the class value. All of this is conception only -- since we started deploying on RT, as I said, I'm not sure that the centralized bottleneck exists that would let us make this work. It's messy even to think about.There is one option that hasn't been discussed in this thread: Suppose my parent class has a field "Color" and a "Get Color.vi" and a "Set Color.vi" both of which are dynamic dispatch. The parent class implementation of Get and Set just returns the color field or sets it (respectively). The child class has a boolean field "Has been set?". It overrides "Set Color.vi" to set the boolean to True and then calls the parent version to set the field. The "Get Color.vi" override checks 'has been set?'... if it is True, it calls the parent to retrieve the value. If the value is false, it returns its own local constant value. This avoids the need for a constructor, it makes block diagram constants and controls behave exactly as requested in the original post. It is more effort than a programmer might wish to deal with.

The feature requested in the original post does not exist in LabVIEW. We've talked about some sort of specially tagged VI that runs once when the class is reserved to set the default value that will be used for the rest of that run (and which every control/constant that is using the default default value would therefore use), but it hasn't ever been implemented. Since there is no central copy of the default value on RT systems, that would be hard to implement there.

There are four "interesting" cases of a class containing itself in its private data cluster. The cluster could contain... ... the class cube directly [this is functionally identical to the class cube inside a nested cluster] ... the parent class cube directly with the default value set to an instance of the child class ... the class cube in an array ... the class cube in a refnum (DVR, Queue, Notifier, Datalog, User Event, User Event Registration) If we're talking about direct inclusion (case #1), Daklu got the answer right in his post above. The same infinite allocation that he describes would happen in use case #2. So cases 1 & 2 are off the table permanently as "logically impossible to ever implement" (unless LV ever introduced a lazy evaluation language syntax which would be a very different programming model than anything that exists today -- I mention the possibility only so that someone doesn't say something like, "If it is impossible, how does Lisp or Haskell do it?") For case #3, if the array is non-empty, you have the same problem as 1 & 2, but if the default value of the array is empty, it would be fine. Case 4 never has to allocate the actual data of the class (it just allocates space for a reference cookie, a cookie whose default value is always Not A Refnum), so it should work. That, I think, is the heart of Mikael's question: Why doesn't this work in LabVIEW? What we found is that we could get some significant performance boosts during load, notably dynamic loading into an already running hierarchy, if a class hierarchy has no circular dependencies (meaning it does not reference itself, including indirectly). There's a lot of work to identify which class can instantiate and reserve first. If all the references are changed out for parent class references, users can still write all the functionality (albeit with a slightly modified syntax than they would generally try first) and LV could simplify the load and reserve algorithm considerably. I looked through various lists of recursive data structures. The most common that I saw were composition patterns, such as is in the Graphics shipping example in LV, where Collection inherits from Graphic and includes an array of Graphic. Those are unchanged because they are already including their parents, not themselves. The other class was the linked lists, trees, and graphs. Honestly, I expected most of these to be written once by someone who was an expert in LVOOP and then most users would just use them as libraries. That expectation was predicated on other features of LabVIEW existing which have not come to fruition. Even so, it appears (based on AE reports and my looking at user code when I get a chance to visit customers) that very few LV users ever attempt to build anything recursive, much less a recursive data structure, so I wager most of those who attempt it are people who are power LV users who generally know about LAVA and will post questions (like Mikael's) and find these answers. Even better, define a parent class that is not recursive with dynamic dispatch methods for anything that would be recursive, then define a child class that overrides all the necessary VIs. That way you avoid the downcast. As of LV 2010, dyn dispatch is faster than downcast (although the compiler team is working on some new optimizations for future LV versions that may change the balance of power here).The <labview>\examples\LVOOP\Graphics\Graphics.lvproj has an example of the composition pattern.

I really do have to put my money together, bite the bullet, and actually buy one of the Austin Utilikilts that I've been eyeing the last couple years.

More of a message passing interface between a server and client, but either one of those parties may essentially implement an events registration mechanism on top of the message passing interface (i.e., I pass you a message that says "next time X happens, let me know." When X happens, you send me a message to that effect.)To give you a clue how similar what I've been assembling is to yours, the name of my project file is "Actor Objects.lvproj". :-) PS: You clearly have a larger monitor than I do. All the VIs are saved just barely on the screen.

I'm afraid a lot of us will have to miss Jim's presentation in order to catch flights at the airport.

This is exactly what we have thus far. The extra complexity is entirely hidden within the subVI that does the launching, so it doesn't have to be repeated each time. In general, we might be ok if Beta misses some signals, but the key signal to Shutdown is one we cannot afford to miss and that's the one most likely to be missed without this set up.

Then let me suggest that the wrong process is creating the event refnum. ;-) This is a problem that I ran into with a listener framework I've been working on lately. Alpha.VI dynamically launches Beta.vi and then gives Beta.vi a queue refnum so Beta can receive messages from Alpha. We had to turn that around -- Alpha launches Beta and then Beta creates the queue and gives the refnum to Alpha. That way the lifetime of the queue is the same as Beta, not Alpha. In your case, it sounds like the correct behavior is for your consumer to create an event refnum and give it to the sender. That way the consumer can dispose the refnum after it handles the event and "destroy what you create" policy is preserved.

Man, I hope Todd (the judge) picks my questions to use for the Challenge this year. I submitted a couple really cool (IMHO) ideas. For those who weren't there last year, the challenge I submitted was to write a VI that failed at least 10 of the VI Analyzer style tests. It was quite amusing watching programmers have to fight their own tendencies to write good code -- one person kept reflexively fixing the style problem and had to keep putting it back as he worked. :-) I don't sleep that week. Hanging out with Norm and attempting to leech some of his infinite energy is sometimes useful strategy. I've also attempted simultaneous physical manifestations in multiple locations... that works, but the reintegration is a real pain. Reading blogs later for the sessions you miss works better.

Ok... you cannot have two VIs in memory of the same name, so the manifest VI cannot have the same name in all the LLBs. Option 1: What if the manifest VI has the same name as the LLB but with the extension swapped out? That gives you a consistent way to find the manifest VI every time and no risk of collision in memory because each LLB in your directory has to be uniquely named. Option 2: Name the manifest VI the same thing every time, but put it in a library that is uniquely named and put the library also in the LLB. I hate this option because it piles hacks upon hacks, generating a second useless file to work around the limitations of the first.

Well... it's a hack, but... You could add a stand-alone .vi file -- one that isn't a member of the class and has a blank panel and diagram -- to the LLB and then put a VI Tag on that VI that has all the info you want to include. Load just that VI and read its tag data to get the info about the class packaged inside the .llb. It's the best idea I've got this morning.