Aristos Queue

I am particularly fond of this front:

Let's try the real stages of LV user development... icons are in parentheses...

"Experiencing Blank Diagram Syndrome." (white square, black border)

"Closed the pinned palettes. Now what?" (the palette pin)

"Tired of just using Express VIs." (LV icon with thick blue border)

"Wondering how to stop parallel loops." (Tiny while loop)

"Burned by Global VIs." (The globe glyph)

"Wishing I knew about Create SubVI From Selection." (white square, black border but dotted line like selection)

"Burned by Cross-Linked VIs" (the directory folder glyph)

"Lost in LabVOOP." (the class cube)

"Inventing my own state machine technique." (two circles with arrows pointing between them)

"Burned by refnum race condition." (the document with folded corner glyph)

"Searching for design patterns." (online help question mark glyph)

"Rewriting my VIs for determinism." (timed loop glyph)

"Remote debugging a Built Application." (stethascope glyph used for probes)

"Waiting for FPGA compile process." (FPGA glyph)

"Digging LV's rusty nail out from left foot." (a nail, rusty)

"Needing unreleased LV version to finish project." (LV icon with a +1 beside it)

To report a bug about LabVIEW or any other NI product, visit here.

If you have ideas you'd like to see for future LV versions, please add them to the LabVIEW Idea Exchange. This is where you can post ideas and vote up ideas from others that you think are good. NI has committed to implementing at least a few of the top-rated ideas for each LV release.

We do exactly what you suggest (essentially an implementation of the Command Pattern), even over a network (flattening the object to strings, which means both senders and receivers must share the same class definitions, of course, so version control is crucial), and it works quite well. I haven't counted the class definitions in our hierarchy but a quick survey shows there are about 100.

Just a note: The receiver can have a later version of the class than the sender... LV classes include in their flat representation the info for mutating the flat data into future formats. We don't have support for flattening to older versions, so the communication is one-way. For some applications, that's acceptable. But if you need two-way communication, Paul is correct.

I like the last option, but I was wondering about its performance and usability. What happens if you want to have 100 message types? Do you want to have 100 classes in your project? Do you want to load the classes at run-time?

I like the last option also, yes, even at 100 classes. In fact... I'll probably say something more about it in about two weeks.

I guess this question is mainly for you and also has to do with the general performance of having many classes. What's the largest number of classes (dynamic and non-dynamic loading) you know of?

Let me see...

• Most classes in one app that I've seen: 116. This is an NI product... I think about 25% are dynamically loaded. I have to work with this hierarchy on a near daily basis.
• Most classes in one app that I've seen from a user: 109 in the Endevo GOOP Toolkit (but come to think of it, you might not consider all the things installed by the installer to be all one app)
• Most classes in one app that I've seen from a user definitely all one app: 66
• App Builder: 34
• Getting Started Window: 19

1. The "View New Content" link is a bit hard to find.

Too small, in my opinion. I'd like it to be the same font and weight as "Recently Added Topics". But other than that change, I'm extremely happy with the new front page.

I was typing a list of items. I did

A) blah

and then I tried to do the second item:

more blah.

You can see the result. If you type B ) without the space between those two, it turns into the sunglasses smilie. Is there any way that we can disable that particular typing shortcut?

But I don't want to have to SVN the userlib particularly as this is project specific...

A ) Don't put the entire user.lib dir under source code control. Most SCC tools allow you to put a single file under control. That single file could be your *-errors.txt files.

As far as I know there is no way to specify a specific error file for a specific project unless you write your own code to make it happen. This would be a good feature suggestion though.

B ) There is only a single error code database in LV's memory. Because the error code cluster is not application instance specific, we cannot know which app instance originated a given error, so all error codes are looked up in the same database. Thus having separate *-errors.txt files per project is kind of misleading because even after a project leaves memory, its error codes would have to stay in memory. So all the error codes from users are expected to be in user.lib. Going further, if you open a VI outside of a project, LV's general goal is that its functionality on the desktop should be the same as if you open it inside a project (some shared variable functionality is the glaring exception here). If the error codes became undefined when you opened the VI directly, I would see that as a problem.

Weird... If you edit your profile, you can set the year you started using LabVIEW. The years 2000 and 2001 are not options in the list. Instead, the year 2002 is repeated three times.

Try this:

Go into VI Properties and on the Execution tab, set your VI's preferred thread to be the UI thread. This will avoid the thread swapping. Now that also means that all your calculations are holding up the UI thread, so you may have a less responsive UI in other aspects, but it should help your flicker problem.

QUOTE (martin@aerodynamics @ Jun 3 2009, 10:08 AM)

Thanks a lot- But why you didn't included your help files? :question:

You got all the help files that exist. Yep, all of 'em.

QUOTE (crelf @ Jun 2 2009, 05:01 PM)

Looks like NI was listening - the preliminary schedule has this presentation on Tuesday the 4th at 4:45pm in room 16B (that's a pretty big room as I recall... anyone else remember? I always get room 14 and 16 mixed up).

As I said previously, yes, it's the largest of the presentation rooms.

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)

My assumption is: even with the newly released scripting there is no way because scripting will not work at runtime, just at development time.

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)

a big "Thank You" to NI and AQ! ... this makes me really happy

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)

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)

Let's not forget XNodes and project environment integration.

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)

OK AQ the guidelines of LAVA clearly state that 'CAPS ONLY' is forbidden, for once we let it pass through.

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)

Do you have a link to AQ's error handler? I thought I remembered seeing it, but Google was no help just now, nor did a search on ni.com yield anything useful.

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)

Anyway, I'm surprised that this is forbidden, provided that you still need to have the development version installed.

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)

Would it not be possible append a totally new errornum series to the end of the source field, introduce new error cluster definition side by side with old one and new error table?

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)

And something very much like that is what I prototyped and posted to LAVA last year.

QUOTE (crelf @ May 22 2009, 02:57 PM)

I think everyone should move over to the new range and use it exculsively I hereby claim the old ranges for VIE!

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.