Aristos Queue

*grin* I should clarify... the biggest *software* time sink is being worked on. I think I'm having a hard time finding enough time to get my NI Week presentation written. I would like to do a book sort of thing, but I suspect that the design patterns and the "decisions behind the design" docs are about as large as I'll ever bite off in a single chunk.

You need LV 4.0 or 5.0 to be able to read the 3.1 VI. LV 6 and later cannot read anything before 4. Someone on NI.com can probably load the VI in 4.0 and save it for you if you can share the VI with them.

Once a queue grabs space, it does not deallocate it. That is intended, designed behavior.

When I said in my previous post that I'd comment more about it in a couple weeks, this is what I meant.

I just got my grades for the Certified LV Developer exam. Passed! Woot! But even more exciting: I turned in a pure OO solution to the problem. No naked VIs -- meaning every VI in the hierarchy was a member of a class, every ounce of functionality in my application was delegated to one particular object to manage. All objects were passed using dataflow -- the queues of objects that I had were mono-directional, for communication, not for data storage. I obviously cannot discuss what the exam question was, but the heart of the application was a message passing interface like the one described by Yair recently on LAVA. I am very pleased with how the OO features of LV responded. Under standardized conditions, such that we can directly compare against a traditional solution, in the same time, I was able to generate an application with better than traditional flexibility (able to plug in new messages into the system without modifying the framework) and with accepted run-time performance. And the single biggest time sink that I had is being worked on by an intern even as we speak. ;-) I am fairly certain this is the first pure OO solution submitted for the CLD, and I was a bit worried about the solution being accepted given that part of the CLD is to grade knowledge of the accepted standards of LabVIEW programming methodology. Apparently, three years since its release in LV8.2, OO passes that test. The clock now begins, counting down until the day when a non-OO solution is not accepted. Not everyone is as much a believer in OO as I am, but OO has slowly consumed every other programming language it has been introduced into. It will definitely be years away from today, but I believe it will happen. For those who have not joined the faith, I'll be serving Koolaid at NI Week. ;-)

Tab controls have a fixed number of pages compiled into them. If you're not working in the development environment, you cannot add more pages. And even if you are in the dev environment, you cannot add more pages while the VI in question is reserved for run. The only workaround I can think of might not be too appealing: You could drop a picture control and draw your own tabs. (Note that Norm's alternative is a better solution generally... I was just trying to workaround the "you need tabs" problem, not solve the wider UI issue...)

Ok. I have figured out how the "View New Content" page works... and I like it. It is very good. But I would like a way to wipe it. When I visit a particular forum, I can click the "Mark as read" link that will flag every topic in that forum as read by me. That removes those topics from my View New Content page. What I would like is to have that same link on the View New Content page so that I can look at a list of topics, respond to the ones I'm interested in, and then mark the others as read so they stop showing up in my View New Content list. This isn't a bug, but it is a feature I'd like to see added.

After running --- by this I assume you mean that the VI has come to a complete stop and yet lots of memory is still being used. If the VI is still running, there are lots of things that could be taking up memory that we could talk about. But after a VI finishes, here's the list: You could simply have a very large VI hierarchy. When you load the VIs into memory for the first time, look at how much memory is being used. It could be that it is already using lots of memory. That probably isn't your problem -- it takes a lot of VIs to make an impact like that, but I have seen some apps get big enough that their raw code size is huge. When the VI finishes running, what front panels are open? Every open front panel will store data in its controls/indicators. If you have lots of panels open and a giant array or a long long long string gets passed through those VIs while the VI is running, every single control/indicator that shows the array/string will have stored a copy of that array/string as part of its display. The dataspaces of VIs expand to contain the data that passes through them (large arrays, large strings), just like the front panel, and LV does not deallocate that space on the assumption that if you're leaving the VI open, you are probably going to run the VI again and the second execution will be faster because memory is already allocated for data of that size. You can use Tools>>Profile to see which subVIs are getting to be the largest. Consider dynamically loading and unloading those subVIs --- open the VI that calls the subVI and then pop up on the subVI node call and select "Call Setup...". In the dialog that appears, click "Reload for each call". Hope that helps.

The topic came up here that LabVIEW should have a way to open VIs from disk without bringing up file dialogs for every missing subVI. The idea on the Idea Exchange is still a good idea, so go give it kudos. But, in the meantime, here's my gift to you for today... The attached "Open VI Without File Dialogs For Missing VIs.vi" will, given a path to a VI, open the FP of that VI. If there are any missing subVIs, those subVIs will be searched for on disk (unless you disable search in Tools>>Options), but if they are not found, no file dialog will appear to prompt you for where to find them. The diagram of this VI is password protected -- even though Scripting is now released, I put this together using features that are private. The VI is saved in LV 8.0... I tested it in LV 8.5 and 8.6, but I think it works all the way back. Open VI Without File Dialogs For Missing VIs.vi

I just posted a reply in the ni.com thread.

Thanks for the explanation, Yair. I hadn't clued into that change.

It appears that when I click "View New Content", the list that gets displayed is all the posts that have been made to LAVA NOT including my own posts. Although I can imagine someone thinking this is a good feature, for me it means I have to know where in the "new content" list to stop reading. My posts being in that list are a good indication that everything prior to that point is stuff I have already read/skimmed.

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.

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 also, yes, even at 100 classes. In fact... I'll probably say something more about it in about two weeks. 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

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?

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. 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) You got all the help files that exist. Yep, all of 'em.

QUOTE (crelf @ Jun 2 2009, 05:01 PM) As I said previously, yes, it's the largest of the presentation rooms.