Aristos Queue

That's my hometown. Spent 18 years there before going to university. Good place -- couldn't find a job there when I graduated, and my parents moved away, so I haven't been back in years. I'm glad to hear that someone's able to make a living in software there nowadays. Thanks for the critique. I mean that -- the AF was designed to go after real world code, so hearing that there are real world scenarios it cannot handle is useful feedback. Your point has had some discussion, both on the forums and elsewhere. My position at this point is that there's a difference between "for the newbie" and "for new projects". We've had a couple of newbie LV users pick up the AF just fine -- I'm not worried about its usability in that respect. The existing projects aspect is a different story. Plopping the AF into existing code frameworks was not a goal we had in mind when building it. I'm not adverse to adding features to it to make such adaptations easier, but not if they come at the cost of the provable correctness for apps built with AF from the ground up. Powell had a useful suggestion the other day for a new asynch reply class that might help... I don't think I'll put it in in time for LV 2012 (we're already *way* late in the dev cycle, what with the beta releasing already, and although there's still some window for feature adjustment based on that feedback, I try to reserve that coding window for "it really is unusable" sorts of adjustments), but I like the idea going forward. Also, being in vi.lib does not prevent us from making adjustments, it just means those adjustments have more overhead if it requires mutating existing user code.

Hold off on finalizing this until the end of the week, please. I'm asking compiler folks to investigate the performance gain of adding the output terminal to see if there's another way to get that gain OR if it could at least be made unnecessary in LV 2012. Since this affects the conpane of the VIs, and that would be hard to remove in the future, it would be better to publish without it. If you don't hear from me by the end of this week, ping me, please.

Catapult or walking. The carbon footprint of being fired out of a cannon was too high. :-)Seriously, though, the only answers I know of are rent a car, phone a friend or call a taxi.

My interest in OpenG is mostly as a "what is LV missing" point of view. For example, I have long coveted the OpenG array palette, wished that LV had those functions in vi.lib directly. Most of the OpenG palettes are better as add-on libraries, IMHO, but that one feels like core functionality, and I've certainly cobbled my own version of several of those functions. Some of the other OpenG tools/palettes I've seen over the years have highlighted places where you guys could have done an even better job if we had tweaked things a bit inside LV. If nothing else, they highlight the parts of LV that you guys are using the most, which are the areas we should probably be focusing on. In the future, I may be more interested in OpenG as a user of the tools... I'm doing more G programming these days, and even a little bit on the side that isn't for NI projects. Just a smidge, but it's more than has been over the last decade. Ah, that rules out the OpenG palettes, Darren, but not the OpenG tools, like some of their scripting accelerators.

I will be at both summits. I am interested in OpenG.

There's a request on the Idea Exchange to make the index terminals on array index accessors Required instead of Recommended. It's an easy change for me to make, one I could even drop into LV 2012 (I still have access to the source code for that branch). But I don't know whether it's a good idea or not. There's comments in the page. Since IE only allows Kudos up, if you don't like the idea, post a comment explaining why. If you do, just kudos the idea. I'll make a call at the end of this week whether to make the change or not. It won't be in the first beta for 2012, but I can still hit release, I think (assuming I get permission to make the change... late game changes like this are iffy because they miss a round of user beta testing that might get some user to say "hey, that causes me problems"). http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Set-index-inputs-on-LVOOP-array-element-accessors-to-Required/idc-p/1857257#M16481

Nope. There are other languages -- I have worked with both Haskell and Lisp, but there are others -- that are reference-free on existing operating systems.

You wont get 1403 from a class not in memory problem. 1403 only occurs when you flatten an object of class XYZ to a string, then try to unflatten that string using a completely unrelated XYZ class -- like flattening an XYZ that contains an integer and then unflattening with an XYZ that contains a string, and not a different version of the class, but one where we try to interpret that integer as the length bytes of the string and realize we don't have enough bytes in the flattened string to represent a string of that size. I don't know exactly what you're doing, but my first bet would be cross-linking of some sort. In other words, the class that you're using during development is *not* the same class that you're loading in your built application.

Only because our hardware APIs are so poorly designed as to require references. The world doesn't have to work that way, but by historical precedent it does.

Debugging enabled? Front panels closed and unloaded? Inlining?

No, there are no such plans. They've never been identified as an API in need of high performance.

Hey, I can kibitz. You'd do that too if you sat next to them. :-)

That performance optimization makes sense to me given what I know of the compiler. It's a bit weird, but I know why it is being done. I'll talk to the compiler guys and see if they can clean things up without the need for that oputput (LV2013 or later, so keep your optimization for now). To me, they're all the same palettes unless there's a palette with an explicitly different palette with a "for debugging" name. That helps. I'd also like the CH to point people toward more info on the topic, perhaps somewhere in the LAVA Wiki.[Later] Perhaps make it "Class Display File Name" or "Class Display Qualified Name". [Later again] There actually is a Display Name property on the class itself (see the properties page for classes). This isn't that display name, so there could be a problem calling it "display". I keep coming back to "debug file name" and "debug qualified name", but maybe you've got something better?

Ah, the int16 array. How... quaint.There are many types created since LV 8.0 that cannot be represented in the int16 array, and even some older types aren't guaranteed to be represented correctly under various conditions (enum, for example, if there are too many characters in the total concatenated list of strings). The variant type library in vi.lib is the type library of LabVIEW. The Int16 array is no longer maintained for new types, and hasn't been for years. Yes, it still works on many, even most, types, but it isn't what I would suggest you use, certainly not in the long run.

Misunderstanding between you and I: when I say "name of class", I *always* mean the qualified name unless I specify otherwise.In any case, the VI that I wrote for jgcode gets the qualified name. And it is an inefficient way to do so that I would not recommend using for most lookup type applications. It works fine for probes/scripting/reflection type utilities, but not production code, which is what anything in the palettes should be intended for. That's why I asked if there were any suggestions for addressing my concerns in the name and iconography, to make sure that this is used only for the probes use case. No. That's my point. This is a fine mechanism *for* *probes*. But it doesn't really belong in the palettes where it might be mistaken for other purposes if you give it the nice friendly name that it has at the moment. Yes, we need this in order to make a generic XML parser. Currently (as of LabVIEW 2010) this is only accessible to the NI folks, as I understand it. Isn't the VI up above one that, given an object, returns the default value of that object? And Get LV Class Default Value.vi returns the default value if all you know is the class. What are you looking for?

I would oppose the general disemination of the "Get Name of Class.vi" without a lot of caveats. Specifically, I'd be tempted to name the VI "Get Name of Class in a highly inefficient but generic manner good for probes but inappropriate if you are really writing a by-name-lookup object hierarchy.vi" ;-) Here's the deal: This VI flattens your entire object data to a string. That's not cheap and it gets even more expensive as the object carries more data. If I am really writing a hierarchy where I expect to do name lookups -- like for database storage type systems -- as part of my actual runtime code, I'm going to add a dynamic dispatch method to the root class called "Get Class Name.vi" and override that at every level of the hierarchy to return a string constant. This avoids the memory allocation and performance hit of the flattening to the string (indeed, if all goes as planned, in 2013's compiler, it will avoid any memory alloc entirely as long as the returned strings really are constants). This solution is what is used in C++. Using any sort of reflection API to get this information in C# is less efficient than adding the "get class name" method. As far as I know, nothing beats adding this to your class definition. We don't do it for all classes generally because it extends the dispatch table with a feature that most classes do not need. The class-to-path function that is in the palettes today is mostly to support scripting and debugging type work. Can you find a way to address these concerns in the VI's icon, name and documentation? You must be using an old version of LabVIEW. They started working in RunTime in LV 2010. I would NOT recommend using them -- they are VERY slow, because they aren't meant to be used in production code (they instantiate entire projects behind the scenes because they assume you're getting one of these references in order to do manipulation of VIs into or out of libraries or to query about project layout stuff). They should be used for scripting and tools work, not for the actual work of your application. The only reason that they're in the runtime engine is someone wanted to be able to do reflection of projects from TestStand without needing the full development environment.A couple of renaming suggestions: "Is Default.vi" ---> "Is Default Value.vi" (just seems clearer to me and leaves namespace open for other "Is Default..." type VIs in the future) "Same or descendant class.vi" ---> "Is Same or Descendant Class.vi" (use of Is to be consistent with other VIs that primarily return a Boolean; also fixing capitalization to match others) "Fully Qualified Class Name.vi" ---> "Qualified Class Name.vi" (the Fully is redundant and the shorter name gets more useful info into the palette display) "Class Name.vi" ---> "Class File Name Without Extension.vi" (the class name is defined throughout LV as either the file name or the qualified name. This makes it clear what is being returned. Again, I wouldn't ship this VI myself, but if you do include it...) > Putting these VIs in LabVIEW Data would be fine, though that library is quite large already Can you add them to a subpalette of the "Cluster, Class & Variant" palette? I don't know what ability you have to add to the built-in palettes of LV, but that would seem to me to be the right place for them.

I discussed this issue a bit in the Actor Framework documentation. My personal policy is that "a library should contain intimately connected pieces that are almost always needed together for operations". In other words, your plug-ins and dynamically loaded content should not be in the same library as your core framework. In the case of the Actors, we've been making libraries that contain the actor and all messages that can be sent to that actor on the theory that each message represents a call to one method of the public API, and the public API is always expected to exist on a class. Only classes load all their member VIs. Regular libraries do not. Regular libraries do not care if VIs in them are broken as far as the functionality of other VIs is concerned. They do load all their member libraries, which, by the transitive property of "things that load things", means that a library having a class will load all the member VIs of that class.Classes can relax this rule in the runtime environement, which we do when you deploy a class to RT, but we never found a satisfactory user experience in the dev environement without having all the members in memory. One weirdness was changing the name of a VI causing VIs of child classes to load or unload, and the unload case was especially weird if you got a Save Changes dialog -- no one expected Save As on one VI to cause a Save Changes dialog on a bunch of other VIs. There were multiple other weirdnesses. Eventually we decided that loading everything in a class is mostly ok since classes are generaly bundles of tightly related functionality such that if you need one part of the class, you mostly need the entire class. Mostly. As long as we could strip out unused methods when going to RT where memory is particularly tight, the tradeoffs seemed worth it. Yes. I'd like this too. I hope they make something like this. Ooo... that felt good... hoping something improves and not having to feel guilty that I'm not actively improving it... probably not a habit I should get into since I do expect to go back to direct LV development someday... ;-)

I would just create a VI that returns the paired arrays of strings as a constant... use that all over the place, including to populate the ring in the one place that is actually a user interface. > An X-Control seems like overkill here, though. And an XControl is not a diagram element. I think that's pretty much the whole problem: you're using panel elements for diagram information.

Wikipedia and many other websites are unavailable today to protest and to educate about the dangers of two bills now being considered by the US Congress: PIPA and SOPA. The Stop Online Piracy Act and the PROTECT IP Act both aim to reduce violations of copyright online. The problem is they do this by attacking First Amendment rights, removing judicial safeguards and placing huge amounts of power in the hands of copyright holders. The net effect of this would be to make it nearly impossible to run sites that allow user-posted content, such as LAVA. Under these bills, the volunteers who run LAVA would have to vet every post, check every VI uploaded, and somehow prove to their own satisfaction that the code posted really is clear of any copyright problems *before* they allowed other users to see the post. Why? Because the LAVA site would be legally liable if anyone in the world complained that their IP had been illegally posted, and the whole site, not just the offending post, could be blacklisted, without judicial review. The burden of proof is on LAVA. Even links to other sites would have to be vetted to make sure that they didn't link to a site that did not also have this sort of prior review. So today, I won't be answering any questions on LAVA or ni.com, and I am encouraging others to also not post content online (other than SOPA and PIPA discussions). Let today give the experience of a world as we had it before the World Wide Web made knowledge so easy to share. Let it be a call to action because these bills are not some abstract thing off in Washington DC, but legislation that would have a very real impact on the day-to-day operations of anyone doing tech support or relying on a community for help. The SOPA bill has been, for the moment, withdrawn by its authors, but they promise to bring it up later, presumably when the tech community isn't paying so much attention. PIPA is still being considered in the Senate. And although our current president has said he will not support these bills, there's no telling what the next president might do or whether Congress might override a veto. An excellent write up of these two bills is here, written by the Electronic Freedom Foundation: https://www.eff.org/deeplinks/2012/01/how-pipa-and-sopa-violate-white-house-principles-supporting-free-speech

> AQ, you should add the Actor Framework to one of the courses! Or maybe a separate class on just that. Maybe at least an excellent webcast like the LVOOP webcast... Allen Smith and I just did the AF intro in a web cast a couple weeks ago. http://zone.ni.com/wv/app/doc/p/id/wv-3101

I believe you. Really. I just don't see these crashes myself. I probably develop more classes than most people on this list, whether it be apps on my own, quick demos for people who ask for them, or testing for CARs. I *don't* typically have the problems you're discussing when editing the private data control or renaming classes. Just today, I had a hierarchy four levels deep in which I had classes in one library. I moved some of those classes to another library, renamed them, moved them on disk and then deleted fields from the private data control and had no problems, before, during or after the operations. I do this on both my Windows machine at work and my Mac at home. If you have a situation where this happens, I need you to file CARs. Even though I'm not working on them myself any more (see thread in LAVA Lounge from last week), I still care about the quality. My team has done a huge amount to stabilize LV classes over the years. We will do more if you bring it to our attention. This is especially true for those of you who use source code control and can provide before and after images of the classes if they become corrupted.

I helped write the OO course, so take my comments with a grain of salt... of course I'm going to say it's worth it. :-) The course is 2 days. Day one focuses on design; Day two focuses on implementation. You work your way through designing a single application, working from a customer specification and identifying the classes that will be needed to do the project, and then you turn to implementing it, how that works in LabVIEW and the tools that are available to edit, debug and deploy the app. It's dense -- no question about that. I wish we could have made it three days so we could've added a little bit more breathing room and a few other topics, but at two days, a lot more customers can afford the time away from work, so it's more accessible. As for whether it helps with the CLA... the best prep for the CLA is still 5 years of actually architecting code. You do not need any OO knowledge to pass the CLA, though you are welcome to use OO in your architecture when you do the CLA if that's the architecture you think fits best.

Like this: (VI is saved in LV 2011... should work back to 2009... back to 8.2 if you rewrite the subVI.) Get Name of Class of Object.vi

Use the Flatten To String primitive and take the name off the front. The details of doing this are posted somewhere on LAVA... I forget where. Try searching the OO category for "flat format".

FOR THE NTH TIME: THERE IS NO GARBAGE COLLECTOR IN LABVIEW.