Aristos Queue

I know. Lots of things in the "load progress bar" project seemed like a simple, obvious solution. After six months of brainstorming and prototypes from members of the LV team, I'm now in the "there is no good solution so stop trying to force one" camp. :-)

I told someone to come to this page. "Just search for barbecue on LAVA," said I. They typed in "BBQ". Turns out that no where on the entire site do we use the keyword "BBQ" the search engine doesn't return any results for that term. I was amazed... I would've thought that would have worked. So, I am now posting this comment so that, at least for 2012, "BBQ" will get a hit when you search. :-) If you found this comment by searching, the post you're actually looking for to buy tickets is this one: http://lavag.org/top...niweek-bar-b-q/ [EDIT] Um... hold that thought. A) I just searched for "BBQ" and this comment did not get found. B) I just noticed that Justin's original post uses "BBQ" in the body text. Something is not right with the searching.

I meant that I didn't think that any of those features were even compiled into the core LV and were installed by the modules, but I may be wrong.

Oops. I hadn't read the rest of the thread... I was posting from my phone so I didn't forget to tell Staab that idea.

I think the WebSockets is going to be the thing to use in a couple years. As for Web UI Builder using SilverLight, you gotta remember, when we started creating that, HTML5 not only wasn't a standard, it looked like it would never *be* a standard. SilverLight was the only game in town for cross-browser multimedia of any scale (Flash just didn't scale up enough when we tested it). We got caught on the cusp of a change of tech... and will now have to spend some effort retooling.

I don't think that does anything unless you have the RT or FPGA modules installed.

Where did you hear that? It's not true.

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.

HEY!!! I have a perfect example for everyone of stuff to not go poking around in! The "Get LV Class Default Value.vi" ... if you pop it open with your favorite password cracker, you'll find a Call Library Node. You pass into that Call Library Node a path and an app instance refnum and out comes the LV class. And now you're thinking, "HEY! Aristos Queue didn't put that app instance refnum on the conpane of the VI! He's hiding functionality from me! I can use this to get the value of a class in another application instance!" And so you wire up a different application instance. And you run your VI. Now, sometimes you crash right away. Other times, you don't crash until you try to close the project. Other times you just get a crash on exiting of LabVIEW. In any case, you've thrown off the reference count for LV class data because -- ha -- it is an ILLEGAL OPERATION TO PUT CLASS DATA FROM A CLASS INTO THE WRONG APPLICATION INSTANCE. You have to marshall the data from one app instance into the other app instance, because the *class itself* might not exist in the other instance, or might exist with a different definition (i.e., in one app instance you loaded c:\x.lvclass and in the other you loaded d:\x.lvlclass). And, hey, if you want to go indexing off the end of a pointer into undefined memory, this is a great way to do it. I swear, by all the nodes and wires in Heaven, none of this stuff has any business being on any block diagram except for the one that it is on and that we password protected. It is either useless to you or subject to change in a future version of LV because we're still refining it and have no intention of supporting the current version (unless it passes testing and we decide to make it official, but we might not have time to do that in a given release, so it may take a while, so just because it has been there and private for a few releases doesn't mean it will be there forever).

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?

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.