Jim Kring

QUOTE (rkanders @ Apr 18 2008, 07:51 PM)

There is a bug in Delete Elements from 2D Array __ogtk.vi where rows are deleted when colums are selected and vice versa.

Hi Reinis,

Thanks for the feedback.

Regarding the issue you mentioned, I cannot reproduce it. As crelf mentioned, it would be very helpful to include an example that demonstrates the bug and tests the actual results against your expected results. This will help us determine whether we can reproduce what you are seeing and whether what you are seeing is actually a bug.

Also, for future reference, the best place to report OpenG bugs is on the OpenG forums, here:

http://www.openg.org >> Report a Bug

Thanks,

-Jim

QUOTE (orko @ Apr 18 2008, 10:50 AM)

"Gee Jim, what are we going to do tonight?"

"The same thing we do every night, Michael... Try and take over the WORLD!"

Real funny, Joe. Is that some kind of bald joke?

hehe :laugh:

QUOTE (jpdrolet @ Apr 18 2008, 10:20 AM)

Now what you have to do is to insert another To Variant node to wrap the variant into a variant so the VI handles the input content as a variant and keep its attributes. Be careful that the name of the embedded variant is set correctly or use that name input.

I tried this and it doesn't seem to keep the variant attributes. Attributes don't survive the flatten-unflatten process:

Download File:post-17-1208546218.vi

QUOTE (Bonagel @ Apr 18 2008, 02:15 AM)

Thanks Jim for your suggestion - but it leads to my next question: how can I programmaticly get access to a clusterelement without using any flatten-to-string-operation?

Unfortunately, I don't know of any way to do it without flattening to string.

Dan,

Glad that works for you.

Thanks for spreading the OpenG love

Cheers :beer:

-Jim

QUOTE (Bonagel @ Apr 18 2008, 12:02 AM)

okay you are right... but in my application I got also variants in my cluster. I changed my example program and it still doesn't work. Like I wrote in my first post I suggest that the flattened data string inside the VI does not contain the attribute information...

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)

1 Beer :beer: as ordered. Don't drink it to fast.

Hmmmm. This complicates things. The string array I am actually using has text and numbers, but the first column will always be numeric. Is there an easy way to do this? Right now I am playing around with the pointer array that is coming out of the Sort 2D VI.

Dan

This is what I came up with quick and dirty

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)

QUOTE

At the end of the day, I don't know why NI won't prioritize adding a nice associative array function to the Queue and Notifier palette.

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)

What are your impressions of it?

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.

QUOTE (alfa @ Apr 2 2008, 11:32 PM)

I started a new book: String theory

About strings, black holes, quantum information, quantum computers…and a lot of math.

If you know some links with conferences, lectures on these topics 'let us know'...

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)

That looks like it might make for a good OpenG candidate

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)

Several of them are subroutine. In general we do NOT make anything be subroutine because of the inability of users to debug in such VIs. If you have a need for subroutine priority for something in vi.lib, clone it and make it subroutine. This has been a point of debate in the past, but the explorability of LV has always been given precedence over performance as far as that setting is concerned.

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 created major problems for LabVIEW when I made the "Trim Whitespace.vi" be reentrant a few versions ago. Just launching LabVIEW's Getting Started Window spawned 150+ copies of that subVI. It was a major memory hog. In LV8.5, that subVI is no longer reentrant. The tradeoffs between the thread synchronization and the memory usage were such that not being reentrant is better.

Now, in LV8.5 we also introduced pooled reentrancy. The LabVIEW R&D team has been seriously debating a recommendation that the vast majority of non-state-maintaining-pure-function VIs should be changed to pooled reentrancy. In the long-term, this may be something we encourage. The "Trim Whitespace.vi" is a prime candidate for this status... we didn't do that in 8.5 because the feature was brand new --- since that subVI could be used in tons of user VIs around the world already, we didn't want any potential bugs in the new feature to impact existing VIs.

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)

So the thumb of rule would be:

Use subroutine only for very small subVIs whose execution speed is rather short and that gets called very very often. Because for a VI that takes 1s to execute shaving of a microsecond in calling overhead is simply useless, but if that subVI itself only consists of a few LabVIEW primitives taking up anything in the order of 1 microsecond to execute, adding another microsecond for the calling overhead will be significant. But even then if you do not call that VI millions of times inside a loop it is not likely to buy you much.

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

Since we like to view the OpenG VIs as primitive like functions they need to behave like primitives.

One of my 'OpenG VIs I couldn't live without' is Filter Array. A lot of times I use it on several data-sets inside one VI. Since the VI is not reentrant it is called subsequently, this can be overcome by making the VIs reentrant, and allow the clones to be shared to limit the food-print of the VI.

Are there any problems with this view?

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 never use subroutine priority. I would like to see some benchmarking. Like many things in LabVIEW, such as thread priorities, the benefits of playing with them are highly overrated.

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)

In deterministic applications (i.e time critical or timed structures) I use subroutine priority for the "skip subroutine call if busy" option.

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