Aristos Queue

RFC == Request For Comments. I got a number of requests at NI Week for some standard iconography for LabVIEW classes. So, I've asked the iconographers internal to NI to produce some glyphs that could be used to annotate icons for classes that have particular functionality. Those glyphs will probably be available later this year. But one in particular is difficult to get right. An "abstract" class is one that you never intend to actually use for real data. It is an ancestor class that is defining a bunch of methods, but all the real work is done on child classes. So, what is a good glyph for "abstract"? I suggested a Campbell's soup can and Andy Warhol's signature, but that's a bit hard to fit in 16x16 (remember that this is a glyph to be applied to other icons, so we don't have 32x32 to play with). Iconographer Laura Hayden hit upon an interesting idea, and I'd like to get some feedback on it. Drawing on the idea that the abstract class is the ancestor of the real class, and is the prototype for the descendant, she came up with this glyph: The double-helix of DNA. I kinda like it. I had resigned myself to "abstract" getting an arbitrary symbol, the way that "create" has the yellow star glyph -- there's no natural association between a yellow star and create, but by repeated usage, the association has been built up in our collective minds. This almost has the right feel -- the genotype that will be shaped by the environment to create the phenotype of the descendant classes. Maybe that's carrying the metaphor too far, but it works for me. I'm curious how others feel.

Wasn't trying to be helpful this time. :-) I don't have a helpful suggestion on this topic. Jim is right -- go ahead and use this trick. Perhaps someday it'll stop working. Or, perhaps, we've gotten along this long without someone filing a CAR, maybe it'll just be enshrined. I haven't filed it after reading this conversation. There is some error checking, but it isn't comprehensive. And you wonder why we have never released scripting... :-)

Rolf is correct. LVClasses are not refnums, but internally I borrowed some of their syntax and it was easiest to make them a (get this) "by value form of refnum." That's not as much of a hack as it sounds -- refnum is sort of a misnomer at this point, and internally refnums would be better named as "any data type with a hierarchy". I wasn't even the first to use a by-value hierarchy -- credit for that goes to one of the DAQ groups. Bytes 8 thru 11 are a hex value that indicates which application instance this LV class is loaded in. It will be different every time the class loads into memory (and is ignored when flattening/unflattening to disk). Notice that I could have Alpha.lvclass loaded into one application instance which has as its private data two ints. In another application instance I could have a different Alpha.lvclass that has a string. The name of the class is not enough to distinguish the datatype -- we need to know which context to look at. The FFFFFFFF for LabVIEW Object is a special code for "union of all app instances" -- I only have a single instance of LabVIEW Object class that is used by all app instances. Occassionally you will see values other that FFFFFFFF in a LV Object type descriptor when data from a specific class has been upcast onto an LVClass wire. There's also 4 bytes for flags. This is pretty much left as room for future expansion of the data type. It's a reflex of mine -- when building something that will be very hard to mutate and where the penalty for bad design could have effects lingering for generations, leave yourself some extra bits to encode mutation. ;-)

Exactly. And that's why this is such a terrible bug for LV!!! I'll wager at least one of those casts creates a crash situation. This should *soooooo* be illegal. At the very least the property/invoke node should be type testing the refnum value and returning an error if it is an invalid type.

It's hard to imagine this implementation aspect of XNodes changing. The XNode developers assure me this is a key aspect of XNodes -- I'm not privvy to all the details of why and wherefore. And since LVClasses would be the only feature really putting any pressure to change this, it would surprise me if anything changed. I think it is up to LVClass R&D and LVClass users to find all the workarounds we can. I know that the LVClass should be able to be used in the writing of an XNode so long as that same class is not part of the code that actually gets scripted into the XNode. The problem with wiring an LVClass to an XNode is that the scripting has to be done very gently to avoid loading the LVClass into the XNode context and then copied back into the original context (which occurs when the XNode is done with scripting in what I think of as the scratch pad context). I don't play with XNodes at all myself yet. It's an interesting tech, but not my primary focus, so most of what I know comes from others -- both internal and external -- who tell me about the problems they've encountered.

I just assumed that Jimi was a strict typedef of Tomi Malia for backward compatibility. I had no idea that we had actually changed wire type. I'll be sure to cast in the future. At least Tomi didn't inherit from Jimi and override the Name method -- although that would make wiring convenient, it would make his his own parent, and the recursive allocations would rapidly cause problems. ;-)

Oh dear lord. You're kidding right? That is soooooooo a crash waiting to happen in some case where we (LV R&D) add an data field to the record of a FP control that we don't add to the constant... I can imagine a function where we assume we have a control in our hands, so we access a field (which isn't there because it is really a constant) and booom.... down goes LV.I can see why you want this functionality to work -- I mean, having access to the text field and all -- but WOW, that is so bad it makes my teeth hurt. And we can't even fix this improper cast in any way that I can think of without breaking your code. Even if we were to add a Text property to the StringConstant, how could we find all the improper type casts and change the code to leave out the type cast and just call the StringConstant's new Text property directly. Wow. It's bugs like this that had me so paranoid when we released OO in LV8.2 -- what did I put in that is a bug, a dangerous hole, that will have to haunt us for the rest of time because there's no way to mutate away from it? Haven't found such a bug yet, but the possibility continues to plague me every time Jimi starts a new thread... :!: PS -- for those of you who are now building object hierarchies in LabVIEW, the correct way to handle an object hierarchy like this, where you don't have multiple inheritance but you want something to unify two branches, is for one inheritance to own an instance of the other branch as a data member. For example, the Constant class would have a Property of "Control" which would have all the control behavior that underlies the constant. The other possibility is for StringConstant and StringControl to be the same class, with a boolean property "Is Constant?" (or maybe a trinary "style" which returns Indicator, Control or Constant). Type casting your types in this abusive manner is, as I said, a problem waiting to happen.

XNodes do not exist. But if I pretend that they do, I might also pretend that there was a great sigh of despair the day I realized that they used a separate app instance. Good thing they don't exist so that I can go on being cheerful.

The TCP/IP primitives and the VI Server prims already provide ways to do asynchronous signaling from one app context to another, whether on the same machine or a remote machine. Depending upon what you're doing, you can use those comm methods to spawn user-defined events for a local event structure. I suspect that writing a decent library for remote events is possible using the G available today. The possibility of remote events -- and other remote communications channels like remote queues -- does exist in the future of LV. Not in its immediate future, but the preparation for a more distributed LV is one of the big reasons for isolating the queues and events that exist today to a single app instance. Basic principle: An app instance should always be treated as a separate machine. If the code works in separate app instances, then it should work on separate machines. Behind the scenes, LV might cheat for two app instances on the same computer, but the same VIs must still work if the app instances aren't co-machine.

The new behavior is the behavior 8.0 should have had. It was a bug that the queues, notifiers and events worked across contexts. In fact, they didn't always work, only most of the time, and they will work even less in the future as we go forward with intended features. The way to communicate data from Application Instance A to Application Instance B is using network protocols such as VI Server, the TCP/IP prims, data socket, etc. Basic rule of thumb: If a given communication method could be used to communicate between two different computers over the network then they can be used for communicating between App Instances. Any feature of LV that allows data to be passed between App Instances on the same machine that does not work when the App Instances are on different machines should be reported as a bug.

Here's the link to an XControl I wrote that defaults to indicator, among other interesting properties. http://community.ni.com/examples/scrolling-led-xcontrol

We do have the introspection, but only on development clients. In the runtime engine, there is no support for looking at the source code. Indeed, when you deploy to a runtime engine, we strip out the diagrams from the save file and all that remains is the compiled assembly instructions, the front panel, and the dataspace. You can take images of your block diagrams (there are methods in the development system for getting PNG or other graph file formats of the diagram) and send them along with your VIs if you want people to be able to look at the block diagram.

What is an error code analyzer? You use this term as if it is something I should already be familiar with, but I don't recognize it. Do you mean an error logging system of some sort? What sort of specifications do you want for this analyzer?

If you can't reduce the size of the application, AND you don't mind sharing the app with NI, please go ahead and file a bug report with NI tech support using all 2000+ VIs. We will investigate a crash like this even on a giant hierarchy. Somehow a rumor got started that we won't do investigations of deep VI hierarchies, so folks have been avoiding submitting them unless they can get the bug to reproduce under a smaller hierarchy. While we certainly appreciate the leg work of you doing the reduction, we have been lately encouraging people to go ahead and submit the bug. Sometimes -- particularly for a bug like a typedef update -- it is a matter of moments to identify the problem VI when a debugger is connected to LV at the time of the crash.

VERSION 1.3 of the document is now available here: http://jabberwocky.outriangle.org/LabVOOP_...gn_Patterns.pdf From now on this link will work... I'll simply overwrite the existing document with any new versions, rather than having a link for each revision. That was a silly idea that just lead to a lot of dead links in various posts.

I'll take care of it. Thanks for mentioning it. That's one of the dangers of this "backdoor" mechanism of bug reporting. ;-)

I asked Greg about this... The aforementioned gH8BIT table isn't just a static table in the code. It's built on launch, so I can't just cut/paste it out. Maybe if I get ambitious.

Yep, that's a bug. Someone must've forgotten to clear the output when the input is unwired. I'll file the bug report for you. This was reported to R&D (# 45PCAHGF) for further investigation. (This post was edited to use the CAR number provided to Ned. I closed the duplicate.)

I am posting this from my new laptop. A MacIntosh. I bought my last new computer in 1998. Well, not technically true -- I bought an HP desktop about 1 year ago and returned it to the store two days later because the thing bluescreened so much. So 1998 is the last time I actually bought and kept a new machine. Since I didn't want to repeat the HP experience, I spent a year looking at machines. I was in no particular rush -- my 1998 Pentium running Win98 still checks e-mail and runs Alpha Centauri just fine, and as long as those two apps work I'm happy. But the lack of a USB 2.0 jack was starting to become a bother with peripherals. And I was reluctant to add a card to the machine because I have a prejudice against opening the case of any computer -- I can make software dance to any tune, but hardware and I have a less than happy relationship (my software prowess is demonstrated by the fact that the hacked and patched Win98 OS on my machine hasn't bluescreened in two years; my hardware failure is exemplified in that I somehow smoked the first SCXI chasis when I took the SCXI customer training course when I started at NI). In short: Apple won. I spent decades opposing Apple -- I hated the locked down OS that kept me from understanding how a computer worked, where as MS-DOS would happily let me peek and poke any address I chose to abuse. I was very fond of the comment, "MacIntosh: An etch-a-sketch you don't have to shake!" But with the release of OS X, well, the world changed. I bought the new laptop online from the apple.com store. I spent three days kicking myself, thinking, sure, I've used friends' Macs, but it can't really be worth the extra cost, and I can't believe I'm supporting Apple, and "God, I hope I don't turn into one of THOSE kind of Apple users... I can do a snooty French accent, but do you buy the black beret or will they ship one with the laptop?" It arrived yesterday. The plug litterally lept from my hand and connected itself to the laptop (yes, it has a magnetic binding... no scews or pins). Then the laptop greeted me, said I had a nice home, asked if I minded if it got comfortable, and asked if I wanted anything from the fridge while it was getting a drink for itself. It appologized for having a Safari browser and offered to help me install Firefox since that's what I'm used to (as opposed to my Windows machines that tend to look askance and ask "Do you really want to do that? Open source software is known to cause radiation burns...") It accepted my iPod as a friend, and the two of them played music for me while they shared playlists, like war veterans sharing stories. On Saturday I'm going shopping for a laptop backpack (the ones from Swiss -- the same guys who make the Swiss Army Knives -- is really nice). It's sort of a "welcome to Austin" present for my laptop friend. And I'm thinking of buying something for myself as well... because the black beret wasn't packed with the laptop after all.

You're going to be the second bastard to file a bug report about the 16k wire aren't you? Yes, that's right, I have a CAR that says: "If any segment of my wire (no bends) is greater than 32767 pixels then if I right click on it and select "Clean Up Wire" then the wire gets deleted." This CAR was closed as "Not a bug." The general consensus was that LV had responded correctly to such a wire.

The bug looks like a side effect of the speed optimization for Variants that went into LV8.0. "If types are same, just preserve data." I think that only the types were compared, not the name of the type. I had no idea that was important to anyone, and so it doesn't surprise me that whoever wrote the code in the Variants was the same way. Data type name is something that we tend to play pretty fast and loose with within the LV code -- up to now, in my mind, it's pretty much there so that "Create Control" gets a decent label. Didn't know it was useful for something. Someone should file the bug... I'm focused on other things today.

And they're a type propagation nightmare that is prone to crashing and produces bizzare errors unless you hold your CPU at just the right angle so the instructions go down the pipeline juuuuuust right. And, of course, they're dead code in the future. Not that I'm implying they exist today or anything. Nope. Definitely not implying that. If you want licensing free, use a Mac. Or Linux.

The case structure suggestion sounded perfect to me. Remind me to add to Zen of LabVIEW that "Odd is fine if the case is rare." I'll wager that no one who is not a LAVA reader raises this question in the next two years. If anyone does, I'll reconsider the issue. You're not going through the same interface if you're using the Call By Reference node. The CBR node does not preserve inplaceness -- it would be odd to return an error that something you cannot see doesn't match. Similarly, the CBR does not preserve coincidental auto downcasting. The interface you're going through could invoke any VI with that type signature. There are really two options here, equally valid under the rules: If the CBR node were to demand that all VI refs that come to it must have the same coincidental terminal mapping, then it could return an error if one didn't. If the CBR allows any VI as long as the types match, then it can run any of them as long as it never does coincidental auto downcasting. The question is whether you consider the CBR to be defining the interface to any VI of a given type signature or any VI of a given call signature. Given that the call signature is invisible to users -- and I've seen no feedback generally to change this -- then, like inplaceness, it should not be part of the CBR behavior. Now, we already have "strict VI references". We could establish "super strict VI references." Maybe instead of one orange star we could put two orange stars. These references would preserve inplaceness, coincidental auto downcasting and any other call interface features that LV invents as time goes forward. Only the most advanced users would ever be interested in them, but it is something we could do. PS: In case anyone else is wondering, Jimi asked me for a name for the feature, and I suggested explicit automatic downcasting for what happens between the dynamic input and dynamic output FPTerminals, where the VI actually breaks if the runtime type is not preserved and coincidental automatic downcasting when LV discovers that a static VI happens to preserve runtime type and so we enable automatic downcasting on callers of the VI.

Jimi, please... you gotta stop posting to both NI and here. Or repost my reply along with your crosspost. I can't keep up with all the forums. ----------later---------- Ok, here's my cross post from the ni.com forum... The code disable structure (and conditional disable structure) bug is fixed in the next version of LV, not 8.2.1. With regard to the interface change... I don't consider it a design flaw. I've had this conversation a few times with various customers/internal developers. Effectively you *have* changed the interface -- you've made it so that the output type is no longer guaranteed to be the same as the type that was passed in. All callers of this method now have to worry about the possibility of a downcast that might fail. It is a hard-to-notice change in the interface, but a change nonetheless. Perhaps something might be done to call attention to the fact that the type used to propagate through but doesn't any longer, but whether such a call out is someday added or not doesn't change the fact that the interface no longer guarantees type safety. I think this is the same category as a parameter passed by pointer in C++ changing from "const type *" to "type *". Going so far as to provide a way to mark terminals to enforce runtime type propagation would be nice. It would help with those dynamic dispatch cases where you'd like mutliple terminals to propagate type, something that can't currently be done because we can't tell which implementation will be invoked and any new child might not preserve the type on its own diagram. But we wouldn't turn off the automatic detection -- the ease-of-use factor is way too high. As you said, you expected it to work this way when you started, and requiring everyone to mark terminals on all VIs -- not just members of the class, but any VI that uses the class -- raises an extreme usability barrier.

Point taken. In that vein I offer a koan... At dawn, a student asked of the master, "Master, what must I do to achieve enlightenment?" The master answered, "Walk around this pole all day. Each time you reach north, smack yourself in the head." The student did so. The next day, the student asked the master, "Master, what must I do to achieve enlightenment?" The master answered, "Do as you did yesterday, but skip the walking." Upon hearing the answer, the student was enlightened.