Aristos Queue

If the goal is "developer time", then we might need to track keystrokes and mouse clicks used to create the VIs, since the other languages are essentially tracking keystrokes.

A) The thread-ring and chameneos-redux benchmarks would be hard since the rules explicitly call out cooperative multitasking models as "interesting alternate implementations." LV's dataflow implementation is cooperative thread scheduling. B) The rest of the benchmarks seem like they'd be viable to implement, though I have no idea how you'd get a relative measure of "code size".

QUOTE (i2dx @ May 30 2009, 09:28 AM) That is correct. Scripting requires recompilation, and there is no compiler in the runtime engine.Your best option is an array of controls... you can resize the array at runtime to display more or fewer controls.

QUOTE (i2dx @ May 30 2009, 09:06 AM) I had very little to do with it other than saying, "Yes I think its a good idea" when asked. NOTE: Someone else mentioned that it has been made public and we should go further and remove the licensing from it. I would be stunned if that ever happens. We do NOT want this in the regular product. Scripting is a powerful dangerous tool. It has the ability to put your VI into inconsistent states. It is not consistent between LV versions. And it is very rarely the right option for the vast majority of LV users in the world. Requiring interested parties to come to the NI website and download a separate component in order to turn it on keeps it out of the common LV interface. Please remember that serving programmers is a secondary priority for LabVIEW as a language. Our primary goal is serving non-programmers in some key domains. We are trying to balance power vs security, and making it a separate install serves that balance nicely. QUOTE (David Wisti @ May 30 2009, 10:04 AM) Now that scripting is legal, should it be moved out of Rusty Nails? Legal and rusty are very different things. Scripting is no longer in the attic, but that just means that now that it is sitting in sunlight in the backyard, you can see the nails easier.

QUOTE (Michael Aivaliotis @ May 29 2009, 04:28 PM) Opening up the project integration to just two non-NI groups has produced maintenance headaches. There is no interest at all from the NI side in maintaining binary compatibility of project plugins across versions of LV, and many reasons against maintaining such... witness the mess that XNode interfaces have become for those of you who have dug into them. Various conversations are in play around NI about ways to open up the project integration -- the two that have been done thus far are trial runs for opening it up wider, but no one is ready to flip that switch at this time.

QUOTE (Ton @ May 29 2009, 03:36 PM) Believe it or not, I typed the headline and deleted it twice as I considered and reconsidered whether or not this post warranted the all caps. I decided that with this much pent up demand, the requirements for shouting were met.

http://decibel.ni.com/content/docs/DOC-4973#cf After years of lobbying, National Instruments has now released scripting as a tool that our users are allowed to use. The Windows license and support files are now available for download from the above link. Mac and Linux download will be posted next week. For those who are wondering, "What do we need to download on Mac/Linux since there's no licensing required?" ... there's a .zip file of useful information and instructions that will be posted.

For those who are interested: I have confirmed that this NI Week session is going to be in the largest room available. QUOTE (jdunham @ May 28 2009, 04:41 PM) Yes. But http://lmgtfy.com/?q=LAVA+error.llb+Aristos' rel='nofollow' target="_blank">here it is in a slightly snarky way... I hope you are as amused as I was...

Open a TCP/IP session between the two applications and communicate data between them.

QUOTE (Vladimir Drzik @ May 27 2009, 01:35 PM) If I had to guess, I'd suggest the lawyers decided to explicitly forbid it just in case someone figured out a way to do it without the development system. Lawyers are paid to be paranoid like that. :-)

QUOTE (Anders Björk @ May 25 2009, 10:51 AM) Not generally. You have errors that arise from code where the only returned value is a number. No strings, no clusters, no booleans, just a number. They may be C built DLLs like the GPIB drivers. They may be DLLs built with LabVIEW VIs that are then returning just the error code. They could be log files where people just wrote down the number and are now reading it back in. There are tons of places where the only bit of data that is preserved is the integer. Because of the way that error codes get used by many users -- both internal and external to NI -- there's no way to have any migration path. Back in 2001, I spent a year working with CVI and TestStand and driver groups to find a migration path, and we ultimately determined that there couldn't be one, which meant that we needed to strengthen the protections of the NI Error Code Database to make sure that overlaps never occurred. That's when we started reserving error code ranges, so that two products simultaneously in development wouldn't accidentally grab the same number, or something like that.QUOTE (Black Pearl @ May 26 2009, 02:17 PM) Would't be an OOP aproach be best for that? Base class only contains the traditional error cluster, so the object can be casted to that base class to be compatible with the standard error. And something very much like that is what I prototyped and posted to LAVA last year.

QUOTE (crelf @ May 22 2009, 02:57 PM) Ah, but you hit on a very real problem: People cannot move to a new range. If we could do that, we would make the GPIB error codes no longer overlap with the LV error codes. But there's a lot of VIs in the world that check for specific error codes as returned values. Changing the error code for a given error can wreck havoc. Once an error code is allocated, it stays allocated, even if the product is end-of-life, because someone might still be using that product out in the world.

QUOTE (mesmith @ Sep 8 2008, 09:52 AM) Look at the online help for Obtain Queue. Search the help for the phrase "This function might return". Is this the sort of thing you're wanting to see on all functions?

QUOTE (jdunham @ May 20 2009, 11:53 PM) No need for waterboarding. No one had ever asked for a larger range. As of this morning, the range 500000 to 599999 is now reserved for users.

QUOTE (PJM_labview @ May 20 2009, 03:48 PM) Funny you should ask. I've asked the same question of the developer who made this change. If you remind me at NI Week, we can ask him again together. *growl* No, there's no ini key to put it back.

QUOTE (Black Pearl @ May 20 2009, 08:38 PM) Weird... error code 7 is one of the ones I deal with on a daily basis (just today, in fact, I fixed a bug today involving a function returning it and the next function in line not handling it correctly) and I've never had the GPIB error... this could be because except for a week of training 9 years ago, I've never had reason to use GPIB. :-) The common NI Error Code Database came into being in LV 6.1. Prior to that, every group had its own error codes, and of course, every group started counting at 1... except for one group ( I forget which) that actually used error code zero as an error. Ug. Nowadays we have reserved error code ranges for different products, and we offset the errors coming from the operating system into their own region. There's even two ranges reserved for our customers. :-)

We had a bug appear in the development version of LabVIEW this week. It was the kind that makes developers ask questions like, "How did that happen and if we don't fix it can we call it a feature?" Let me stress that this isn't a bug in any shipping version of LabVIEW. The bug: Mass Compile only runs to completion if you keep moving the mouse. If you stop moving the mouse, mass compile hangs. The faster you move the mouse, the faster mass compile runs. I and a couple others spent three days hunting this bug down, but along the way, there were many comments about the introduction of the new "LabVIEW Fit" -- a new product for building arm endurance in LabVIEW users. Imagine all these buff programmers (well, buff in one arm, anyway) showing up at NI Week, where we hand out t-shirts that said "I compiled vi.lib!" on the front. For the less athletic, NI offers new hardware: a mouse that moves back and forth for you. For only $100, you could buy the new NI Metronome Mouse so you can practice piano while you wait for your mass compile to complete. Other suggestions included -- the manual progress bar, where users had to click on each pixel themselves to advance the progress bar, one pixel at a time, thus solving the problem of inaccurate progress bars -- "click the gopher" web ads -- if you click the gopher, you win a million dollars in Viagra and home mortgages! Alas, we did finally find what the issue was -- XControls were waiting for UI events that would never come during a mass compile -- so these fantastic features will never be. But I thought our users would like to know that we never stop thinking about ways to improve your lives. :-)

QUOTE (shoneill @ May 19 2009, 03:12 PM) The depressing news is that this won't be fixed in the next version of LV. There's a deep architectural barrier preventing the circular load from working correctly.

QUOTE (shoneill @ May 19 2009, 05:19 AM) Less a bug and more an incomplete feature. But, yes, it is a known issue. I've discussed it elsewhere.An even bigger known issue: Do not create a circular link from your XControl to your class. In other words, write your class completely and then write your XControl using the class... do not put the XControl or any property/invoke node for the XControl into member VIs of the class. The circular load leads -- sometimes, most commonly in a built app -- to VIs that are permanently broken and no matter what you do the run arrow will not become fixed.

QUOTE (kchc @ May 14 2009, 12:31 PM) It's type is "Function". There is no more specific class for most primitive nodes. How would you know this? The easiest solution is to drop a node on your block diagram, then open a reference to that diagram, get the reference to the nodes on that diagram and then use the "Class Name" property to find out what the most specific class of the node actually is.QUOTE 2) How can I create the appropriate vi object class constant on my block diagram? Use the Create New Object primitive which is not found anywhere in the palettes and is not addable through any ini token magic. You have to find an unpassword protected block diagram somewhere that has that primitive on it and copy it. I think OpenG has some scripting tools that expose this prim.

The answer will be different depending upon the architecture of your XControl. I think you'll need to post a screenshot of your block diagram for your Facade.vi and your caller VI for anyone to be able to help.

Use the private scripting method "Read Link Info" and scan the returned list for the item in question. The link info is all of the dependencies this VI has including subVIs, typedefs, classes, xcontrols, libraries, etc.

QUOTE (Black Pearl @ May 8 2009, 11:18 AM) It would be too advanced for me too, and I'd like to think I'm pretty far beyond "standard user" status. I posted earlier that you should just wire the N terminal out of the loop to know how many times it executed. This was corrected by someone else who said that only applies as long as the conditional stop terminal is not wired. I am stunned that no one pointed out this deficiency before now. We had this big public brainstorming over on ni.com to come up with all the use cases and issues with adding a conditional stop to the For Loop and no one mentioned "there's no longer an easy way to find out how many times it executed." That's an amazing blind spot on the part of all of us. But this works: http://lavag.org/old_files/monthly_05_2009/post-5877-1241809248.png' target="_blank">

QUOTE (Ton @ May 7 2009, 02:38 PM) I am a premium member, but I'm in the NI group, so I don't get the benefits of membership. I see all the ads too.

_