Jim Kring

QUOTE (Bonagel @ Apr 18 2008, 12:02 AM) I see your point. You are correct. Set Data Name (and probably several other of the OpenG VIs) do not preserve the variant's attributes. I don't think the attributes survive the Variant to Flattened String and Flattened String to Variant operations (the attributes aren't in the flattened data or type descriptor). The only way to preserve the attributes would be to read them all on the incoming variant and write them in the outgoing variant. It might be feasible, but would take a bit of work and could have some performance implications.

QUOTE (ASTDan @ Apr 17 2008, 04:13 PM) Hi Dan, Your solution looks OK to me and I'm happy to see that you're using OpenG One suggestion: for the reordering operation, I would use the OpenG "Reorder Array" function, as shown below: Download File:post-17-1208478378.vi Cheers, -Jim

I upgraded early last week and haven't have any problems. I've used it in several projects and found that it fixed a build issue we were having in one of them (related to locked libraries).

There was a bit of an uproar about this, but it seems to have died very quickly. Apple makes good products that are useful to people. So, it's not a big deal for them to make it easy for people to obtain, and those who do get it on accident get a pleasant surprise.

Here's what I want to do... I have a LabVIEW project that I'm building into an EXE w/ Installer using the App Builder in the LabVIEW project environment. We've decidided to use the version number of the EXE (defined in the EXE build specification) as the definitive version of the software and let LabVIEW auto-increment the build number. The installer build specification has its own version number, which I want to be identical to the version number of the EXE (since, it doesn't make sense to have a version number for the installer that is different from the version number of the EXE). And, given that one important goal of software engineering is to have a fully automated build process (The Joel Test >> Test 2), I (passionately) dislike to have to manually sync the installer build spec version number with the executable build spec version number. One feature that would address this need, is to be able to specify (in the installer build spec) that the installer's version number should be the same as the EXE's build number. However, I'm pretty sure that this isn't possible. What I think I might do is create a VI that sits above the entire build process and syncs the two version numbers by reading and modifying the project (*.lvproj) file, before invoking a build on the build specifications, programmatically using <LV>\vi.lib\AppBuilder\BuildTargetBuildSpecification.vi. Can anyone think of a better way to achieve my goal? Thanks, -Jim

QUOTE (Aristos Queue @ Apr 9 2008, 11:40 AM) It might be because I've never heard of this idea before. What exactly would this be? I think that Jason's referring to the possibility of having a new AssociativeArray by-reference sibling to the Queues and Notifiers types+functions that enjoys the same sort of edit-time type propogation (e.g., Queue and Notifier references contain the type of Queue/Notifier element data, which causes the Queue and Notifier functions to adapt to these types). Just as Queue and Notifier element/data types propogate to the primatives, it would be nice if the key and value types of an AssociativeArray could propogate to primitive Get/Set/Delete/etc. functions. Yes, we can do it with OOP and inheritance + dynamic methods, but it would be nice if AssociativeArray could be a LabVIEW primitive type+functions.

QUOTE (Val Brown @ Apr 4 2008, 10:29 AM) Actually, I posted the link to encourage brave souls to upgrade and report back, here. I haven't upgrade, yet, but I'll probably do so, on a virtual machine and run some tests on my existing 8.5 projects. I would assume that since it took so long to get this release out, NI has had a lot of time to test it thoroughly and iron out any kinks.

http://www.ni.com/support/lv8_51.htm

QUOTE (alfa @ Apr 2 2008, 11:32 PM) NIWeek 2008 is coming up. It's not specifically on these topics, but I'm sure you'd find it interesting (not to mention, the night-life on 6th Street).

QUOTE (Jim Kring @ Mar 20 2008, 09:42 AM) Today, Greg Sands proposed something very similar, in the OpenG forums here: http://forums.openg.org/index.php?showtopic=835

QUOTE (Aristos Queue @ Apr 2 2008, 03:20 PM) I'm starting to think that a similar approach might be good for OpenG, too. If a user has a need for extreme performance, they can always optimize by making copies of the OpenG VIs and configuring them with subroutine priority. Going off on a tangent, this makes me wonder if it might be nice to have a SubVI Node Setup option to make a specific subVI call execute as a subroutine. This would allow users to optimize callers without having extra copies (on disk, in thier project) of OpenG VIs. Another possibility would be to add poly instances that are marked as subroutine, but this would double the number of poly instances, so it's not really feasible.

QUOTE (Aristos Queue @ Apr 2 2008, 01:59 PM) I wonder about combining the subroutine and reentrant VI setting. The subroutine setting might greatly limit the memory used by each reentrant instance. Do you have any thoughts on this? Has NI considered making any of it's primitive-like functions subroutines?

QUOTE (rolfk @ Apr 2 2008, 12:33 AM) One thing that I wonder, is whether OpenG primitive-like VIs that meet these criteria should be configured as subroutines. Will this help more people than it hurts? Is it better to... A) leave them as non-subroutine and let people who need the extra performance use local copies that are marked as subroutines or... B) make them subroutines and let people who are negatively affected use local copies that are non-subroutines It would seem that the number of people that would be helped by the subroutine setting is far greater than the number of people that would be hurt by the subroutine setting. Am I off base, here? Thanks, -Jim

[cross-post] At OpenG, we've recently discussed the possibility of setting our small primitive-like utility VIs as subroutine. Now, we're discussing whether we should make these VIs reentrant. Ton Plomp asked; QUOTE Please respond here: http://forums.openg.org/index.php?showtopic=833

I already sent Michael a PM, but I could used another post on my count too (thanks for the great idea, Justin). Happy Birthday, Michael :thumbup:

QUOTE (Michael_Aivaliotis @ Apr 1 2008, 01:20 PM) I know that the subroutine priority can yield huge benefits (N-fold improvements in performance) when used appropriately. What I'm trying to pin down are the guidelines for when you'll see such improvements, as the misuse of this setting could certainly result in performance degradation.

FYI, I found some good comments from Greg McKaskle in this thread on the NI forums.

QUOTE (David Wisti @ Apr 1 2008, 12:08 PM) That's an interesting node setting -- I wasn't familiar with it, but found some info http://zone.ni.com/devzone/cda/tut/p/id/4682' target="_blank">here. From what I gather, it's probably most useful for inter-process communication -- optimizing the calling application rather than optimizing the performance of the subVI/subroutine being called.

There is a VI execution priority setting called subroutine. Explainations of this setting can be found here: LabVIEW Help >> Execution Properties LabVIEW Advanced Programming Techniques >> 9.10 Subroutines in LabVIEW While I understand some of the basic principles of the subroutine setting, I'm not 100% certain about the best practices and rules of thumb for when to apply this setting and when to avoid it. Does anyone have any thoughts on this matter? Note that this questions applies to a design decision in a new OpenG candidate. After this discussion, I'd be happy to consolidate the information into a Subroutine page on the LabVIEW wiki.

Update: After an initial round of comments and discussion, the cadidate contributor (Christopher Relf) and sponsor (Justin Goeres) have revised the functional spec. Here's what the VI currently looks like: This opens up another Public Comment period for you to provide your valuable feedback. We appreciate any thoughts you might have. Please, take a look at the functional spec and let the OpenG developers know what you think, before this VI shows up in your palette

Hankey San

Shouldn't you be finding easter eggs in LabVIEW, today, instead of bugs? (it is Easter Sunday, afterall)

Stephen, Your post gave me an idea.... It might be nice to add an option to the Show Buffer Allocations dialog for Subarrays. Here is an artists rendition of what this might look like: Thanks, -Jim

QUOTE (Justin Goeres @ Mar 20 2008, 09:04 PM) The result I get is Decimated Array = {0,3,6} (It should be {0,3,6,9}). Likewise, when I run it with Array = {0,1,2,3,4,5,6,7,8,9} Decimating Factor = 4 The result I get is Decimated Array = {0,4} (It should be {0,4,8}). It's easy to find plenty of other examples where the last element in Decimated Array is missing. EDIT: A little bit more testing leads me to believe that the Yuri33's code works as long as Decimating Factor divides evenly into the size of Array. If it doesn't (i.e. if R>0 coming out of the Quotient & Remainder), the last element of Decimated Array is chopped off. Justin, I did some testing of LabVIEW's built-in decimation function. It truncates the trailing (remainder) elements. I have no idea which is the preferred behavior. One one hand, it's nice not to lose data (so you wouldn't want the data truncated), and on the other hand if you are going to create several subarrays with the decimated data, it's nice to have them all the same length (so you would want the data truncated). So, I would probably add an optional argument to this VI called truncate remainder. -Jim

Thanks for the nice article, AQ. I learned a few new things