Aristos Queue

Staab: I thought of a second solution for you... you could build a Variant attribute database where the key is the name of the class and the value is the default value of the object. That does away with requirements to put the classes in a particular location in the EXE.

mje: If the class is already in memory, there's no need to go back to disk on subsequent calls. The rules are the same as opening a VI reference for a VI already in memory.

Yeah... I misunderstood. And I've run into the same problem. I've already been working on LV 2013 to add these functions. In the meantime, I gave Staab a workaround. If it works for him, I'll let him repost it here.

(an unfortunate but workable workaround for limited use cases).

This post has the VI you're looking for:

Why I won't be pushing the G envelope in code I share with the community in the future:

https://decibel.ni.com/content/thread/13544

Load time is most definitely NOT consistent time over time. We have an entire bank of machines to judge LabVIEW launch time every night. 30 identical Windows machines. They do not have consistent launch times between the machines. Launch times change radically on the same machine between the first launch after reboot and the second. Over several nights, they change depending upon how Windows has decided to optimize the caching behind the scenes (there's some sort of most recently used algorithm). Running a disk optimizer can radically change launch time. We take the average of these launch times for judging whether we have made any changes that impact launch time.

I don't believe your solution is viable based on LV's empiric experience. This applies not just to LV and things written in LV but to all EXEs on a modern non-deterministic operating system.

If he's gotten through a first year of high school algebra, it's time to put "Godel, Escher, Bach" into his hands.

Give him my favorite variant of this quest. "Some books have their own titles somewhere in their text. For example, Frank Herbert's Dune has the word "Dune" actually in the story. Now, suppose I write a new book... this book is an index. It lists all the books in the world that have their titles in their text. I want this book to be a complete list. Should the book include its own title or not?"

As for the "This sentence is false" paradox, there are other ways to handle this. Here's one that I like which differentiates syntax from semantics:

"Let 'false' be a variable equal to the constant true. This sentence is 'false'."

It's no different than calling any other DLL. It calls into labview.exe in the dev environment and into lvrt.dll in the runtime engine. We could have made it always call lvrt.dll, but that would effectively make two copies of the DLL in memory. For the record, the reason that we export functions is so that we can expose VIs that call those functions, so pretty much all of those functions are exposed as VIs already in the palettes. Those that are not exposed as single VIs are part of other VIs. Calling things like MoveBlock directly are particularly dangerous since they arbitrarily overwrite memory.

"Easily?" Really? I'm going to have to hire you for my next debugging session. I've been using terms like "frustrating", "maddening" and "the sort of exercise that drives programmers to contemplate text."

Neat... both the boys and their outfits. ;-) Now get off LAVA and get some sleep. You'll need it! Congratulations.

Maite: You don't get to jump to this conclusion without looking up the backstory. :-) The key phrase in Normandin's post is "because of class mutation history". LabVIEW has help files that talk about the mutation history and there are multiple posts on LAVA about it. Check it out and see if it affects you. It's not that you can't use typedefs of clusters in your private data. It's just that if you do, one useful functionality becomes less useful.

The attached PDF file describes the operation of gperf, a tool for text programmers to generate perfect hash functions.

We all know what a hash is: you have some data, like a string, and you calculate a number from the string (say, add up the ascii values of the characters) and then you store lookup info about that string at an index. But multiple strings might have the same hash index, so you have to do a linear search through the data at the index to find the exact string you are interested it. Hash functions can get you very close to constant time look up, but only if the hash function is very good.

A perfect hash guarantees that every source value maps to a unique index. These are generally impossible to achive, but they can be done for special circumstances. One of those special circumstances is a finite list of strings. If you know that only this 1000 strings will ever be part of your input, you can generate a perfect hash function. The function would pick, say, the first bit of the first character, add the third bit of the second character, xor the fourth character and multiply by the sixth character and guarantee that the result was always a value 0 to 999, which you could then use to index an array.

The trick is knowing which bits are unique between the 1000 strings and figuring out a high-speed way to generate the values.

gperf is a tool that does this analysis and generates the perfect hash function for a set of strings, making for extremely fast data lookup for a constant set of strings.

Such a tool could be useful for some G programmers doing parsing or translation. I figured I would mention it in case someone is looking for a project. Even if no one picks up this idea, just knowing about the possibility of a perfect hash function is a useful tool in any programmer's mental toolbox.

The article goes into deep detail about the algorithms used in C++ to generate perfect hash functions for data structures, which should be sufficient to actually translate this into LabVIEW code and scripting.

gperf.pdf

No, you would not have the same problem. The refnum is the prime type.

In fact, the only problem that arises with typedefs is specifically typedefs of clusters at the top level. If you have an array of typedef of clusters, you're fine. If you have a typedef of array of clusters, fine. If you have a refnum of typedef of clusters, fine. If you have a typedef of refnum of typedef of clusters, fine. If you have a typedef of an enum or anything else, fine.

Only poor top-level typedefs of clusters cause problems.

mje: The short answer is "no". Not programmatically, and not through the UI. Cloning was never designed to support that use case.

Congrats, crossrulz.

Could be any number of things. Is it not giving you any results or is it giving you different results?

"Any process that has more than a ten thousand handles open at any given point in time is likely either poorly designed or has a handle leak..."

Or the process is a dataflow execution environment that uses the heap instead of the stack for much of its program execution, thus many function calls are handles that would be stack entries in other programming languages.

Or the execution environment is being tricky. I am not a C# expert, but the bit I know about their execution under the hood, they have hundreds of "handles", but they ask for a single block of memory from the operating system, which shows up as 1 handle, and then manage that very large block themselves through the garbage collector.

I would suggest it is a decent rule of thumb for applications written in C/C++, but probably doesn't apply to other execution environments/compilation patterns.

Rammer: I already posted the description of what I did earlier -- there's really nothing more to it than that. Because load time is completely unknowable, I went with a "I'm still alive" animation instead of a progress bar.

Rolfk is spot on when he describes the problem with your proposed approach.

Asbo: Go ahead and give the extensible session framework a glance. It's pretty lightweight and I think it solves your problem.

https://decibel.ni.com/content/docs/DOC-15385

There's a new version of PageSpeed available.

http://googledevelopers.blogspot.com/2012/06/make-your-website-faster-with-pagespeed.html

Do you make any DLL calls in your code? The execution trace tool cannot generally track allocations made in DLLs.

For the record, when you get a chance to look at LV 2012, there's a big shipping example that I wrote included with it that is every trick I know for putting together "a full LV application", with the exception of hooking a custom Tools >> Options dialog and a custom runtime menu (gotta give you some reason for upgrading to 2013, right?). Included in that is a splash screen that loads and starts running instantly regardless of how large the VI hierarchy gets. In that, I use an animation (it's pretty simple -- just a sequence of boolean LEDs that cycle repeatedly, meant as a placeholder for more splashy graphics you might design for your app) on the splash screen that just repeats over and over while the rest of the app loads in the background. That loading is done just by setting one of the subVIs to be "Load On First Call". For most LV developers, there aren't any surprises, but I figured it was high time there was a single reference implementation that put all the interesting tricks in one place for a "generic application X".

Once everyone gets a look at it, I expect a substantial amount of feedback (positive and negative, I hope) that can feedback into it for future development. I'll post more about it when LV 2012 is public.

I am NOT particularly knowledgeable about AppBuilder. For the purposes of this post, treat me as a user, not as part of R&D. :-)

After you make the scripting changes, do you call the Save Instrument method on the VI? If you do, then I've got no idea. If you don't, then I believe I know the answer: LabVIEW loads a fresh copy of your VIs into a new application instance to do the build. I do not know if this happens before or after the PreBuild VI runs. If it happens after, then I would expect your in memory changes to be loaded into the new app instance, but it could be that we load from disk... I'm honestly not sure. If it happens before, I do know that we will not update from your developer app instance after that copy is made unless the changes are saved to disk (actually, the saving-to-disk rule is the usual rule for forcing an update of the other app instances, but the AppBuilder app instance is special and it might not update even on save, but I *think* that it does).

AQ, most people will be making their splash screen for their own application, where the idea is to put the waiting time to the beginning rather than during the application running (loading a dynamic VI for instance).

You seem to be implying that I said otherwise. One of us misunderstood something.

As long as the end user can see that something is happening, they are usually satisfied. We do not need to make this problem more complicated than it is.

For that, all you need is a pulsing bar that never moves, and you can build that on your own. What we're talking about is a progress bar that moves forward, and that *does* need to reflect a percent to some degree. Here is what I have heard from various user experience (UX) researchers:

1) If you have a progress bar, it must move along with some reflection of the process underneath. It doesn't have to move in time, but it should strive to and it should avoid the 99%-and-hang problem, as that invalidates the whole reason for having a progress bar.

2) Progress bars only move forward. They never backup unless it is clear to the user that something is being undone (i.e. an error occurred during installation and we're backing out the previous part of the install).

3) If you cannot provide a percent progress, you should not have a progress bar. Something like the pulsing bar is better to avoid creating more frustration among users.

4) If the activity is more than a couple seconds, provide a Cancel button and make that Cancel snappy (i.e. don't take forever to cancel the operation).

LabVIEW does not follow these guidelines in many areas, but we're trying to fix some of that. If you're writing a new application, those are the guidelines I'd suggest you follow.

Ano Ano:

These sorts of questions always work best if you can post your best attempt so far and let us help you fix it. If nothing else, go ahead and build the front panel that you want so that everyone is clear what data types you're trying to build up.

This sounds like a homework question, and the community will help, but it won't write it for you. Give us something to start with and then we can point you the right way.