Jim Kring

Congratulations! You're going to be a great dad!

My advice: While it's tempting to try to get some work done while the baby is asleep, that's actually a great time to get in a nap for yourself -- good luck

Great work, jgcode! Thanks for sharing this.

My only complaint (I'm only joking, really) is that you're not using VI Tester

Cheers,

EDIT: Forgot to mention, here the packages I used:

nirsc_html_help_common 2.0-1

oglib_array 2.7-1

oglib_error 2.3-2

oglib_lvdata 2.9-1

oglib_string 2.6-1

oglib_time 2.3-2

oglib_variantconfig 2.7-2

ogrsc_dynamicpalette 0.18-1

Very cool! Also, I suggest that you provide a VI Package Configuration (*.vipc) with your sources, to make it easy for people to install all the required dependencies.

I looked at the LabPython page on the OpenG website, and I saw very little as far as documentation, updates, examples, etc. Is anyone still using this? Has the project been abandoned? I have some coding experience using NumPy, so I would rather use that then have to learn Matlab.

The project isn't abandoned, but it's not very active. Give it a try and if you have questions or need help, just ask. There are lots of people here and at OpenG who are happy to help.

My (now 20+ something) daughter who had no interest whatsoever in anything electronic discovered my protoboard in my lab one day and wanted to play with it. She proceded to draw "pictures" with the protowire. Have you ever seen a stick man drawn on a protoboard with protowire?

That's cute. It made me think of a twist on the expression: "When all you have is a hammer, everything looks like a nail."

When all you've got is a paintbrush, everything looks like a canvas.

You should see how shocking it is when it is the same child. My 13 year old really shot up this past year. He grew close to 6 inches in less than a year. Last week I saw some pictures of him from February and he looks like a completely different kid. He went from looking like a kid to looking like a young man virtually over night.

I've been pretty busy with work for the past couple days, and it's amazing how much Lilah (now three weeks old) changes every time I look at her. She's starting to get a little chubby from eating well (just like her dad, I guess).

Congratulations Jim! She is very lovely.

Thanks!

Cheers,

The project window should have a bright yellow triangle next to the missing file name.

I agree with Omar's response. I expect the error window to show me each specific error (specific method VI missing from class) and a double-click should take me to the specific error (project item that's missing, showing the yellow triangle). Having to find these missing project items manually is a bit of a treasure hunt and slows down development.

Thanks,

No, it's not on the Exchange, but kudosing it there won't accelerate its development. We've already bought into needing it, it's just a question of getting it done. It's on the priority list already.

OK, then I guess there's nothing left to do but wait and hope

Any specific reason behind applying DVRs to LVOOP why automatic type casting of wires originating from class type output terminals is not applied to data value references of class types.

Has this been added to the LabVIEW Idea Exchange?

I agree that this is a must-have feature.

Enjoy them while they are young. They grow up VERY fast.

I just realized this, again, when we brought Lilah (newborn) home and saw how big Sydney (our 20 month-old) is compared to her. It seems like just yesterday Sydney was a little baby

Congrats and best wishes!!! Best advice I ever got was that it takes 3 months to get out of the "fog." Wish my Bay Area trip did not get cancelled. Would love to come babysit and give you and Beth a few hours off!!!

Thanks. Living in San Francisco, we're used to living in the fog I'm looking forward to when this new "fog" burns off.

Just last night I was kicking myself for ignoring some great advice I just got over the weekend: "never try to make a baby happier". In my case, Lilah was asleep at about 12:15am and I was moving her to her crib for the night. I decided to put her in a different blanket and wrap her up tighter (since she likes to be swaddled tightly). She woke up in the process and didn't go back to sleep until 1:15am That was very frustrating, especially as the irony sunk in.

She has very bright eyes! Congratulations!

Thanks! Here eyes are closed most of the time (except for around 1-3am when she likes to keep me awake), so we're lucky to get a good photo like that

I'm sure she will love playing with wires in a few month. Enjoy the time. And enjoy the time before they know to switch your PC on and off.

Yes. Fortunately our 20 month old is over her fascination with wires and buttons. She went through a phase where she had to press any button she could see. The funniest was at our friends house who have a big TV with only one big button (power) in the bottom-middle of the TV. It is the perfect height for her and she spent all night turning the TV on and off

Thanks and Cheers!

LabVIEW In Life Assures Happiness?

That's great! But, I don't think I tell my wife about that one -- she already thinks I'm super geeky

That's just how our family got started...we adopted a baby boy, then 25 months later gave birth to another baby boy, then 22 months after that we adopted another baby boy and gave birth to a little girl about 6 weeks apart. We ended up with 4 under 4 yrs old for about a month The "twins" are 15 & 16 months old now...Good times!

Wow, that's quite a wave of children. We had two children in less than a year, which has been a huge change in lifestyle for us. Adopting has been an amazing experience, so far

There are few folks on this planet I envy and respect more than married couples who adopt a child or two. Having one or two of your own is icing.

"Live long and prosper" to all of you and your beautiful families.

Thanks. That's very kind of you to say.

-Jim

Thanks for the kind sentiments

So is she the first of many instantiations, last of the child classes, or somewhere in between?

Beth and I have an adopted daughter who is 20 months old. This is our first child who inherited genes from me and Beth

I sometimes wonder if you should get out a little more

I thought that everyone uses LabVIEW because it's fun

Thanks for all the feedback. It sounds like NI's UTF is geared more towards regulated industries where traceability is required. I'll recommend we adopt JKI's UTF and spend the money elsewhere.

Saving your money to spend elsewhere is a great idea (BTW, VIPM Enterprise is going to be released very soon )

Cheers,

Here's my heavily-biased weigh-in (disclaimer: I'm on the team that created VI Tester):

I haven't used NI's UTF (but I've seen it demo'ed). It seems to have great features for knowing whether you are testing 100% of your code and need reports to prove it.

Of course, I have used JKI's framework, which is great if you're interested in using a proven software engineering architecture (xUnit) for software testing that's implemented in LabVIEW, for LabVIEW developers, by LabVIEW experts who use it themselves to write and test commercial software products written in LabVIEW. With VI Tester, writing unit tests is fun, since all your tests are written in LabVIEW. This also means that you can reuse code within your tests, and employ object-oriented techniques in the design and implementation of your tests.

JKI uses VI Tester for testing all the software it writes and we're going to keep making improvements over time, including possibly integrating it with other products like VIPM's package builder (JKI currently uses VI Tester to automatically run unit tests on all our VI Packages [software reuse libraries] during the build process).

Update: I'll also add that there is a wealth of information (book, websites, etc.) on xUnit, including: test architectures, design patterns, best practices, tutorials, etc. This means that there's a wealth of training materials that apply almost directly to how to use VI Tester.

Thanks,

-Jim

So you would always, when using DVRs, place a semaphore to the class on the top of the hierarchy and when ever accessing any data in the hierarchy you would lock the whole hierarchy using semaphore?

I would only do this in cases where I know that specific data inside the parent needs to remain locked while child methods are being called. This is, of course, very tricky and one would need to watch out for other deadlock possibilities.

Why you would not rely on the IPE structures when ensuring transaction atomicity?

Maybe this would work, but it would require putting a parent method inside an IPE structure on the child method's block diagram. This could result in a deadlock, so you'd have to be very careful (similar to if you create a special Semaphore for the first case, above).

Sometimes we just need to place class methods inside the locking mechanism. If semaphores are used for locking and not IPE, then we can place class methods outside IPEs. Otherwise there are situations where we simply need to place the inside the structure.

Yes, I agree with you. It's all about trade-offs. Personally, I find the DVR-inside-LVOOP solution to have the least development overhead in the widest number of use cases (I especially like that dynamic dispatch can work on any method, unlike with DVRs of LVOOP objects). In those cases where we need locking at all levels of the inheritance hierarchy, we can either put class methods inside IPE Structures and be careful not to deadlock or use an external locking mechanism and be careful not to deadlock.

Hi Tomi,

Thanks for the detailed analysis. Here are my thoughts:

In cases where a child wants to:

1. lock,
2. read parent private data,
3. perform calculations/work,
4. write to parent private data, and then
5. unlock,

I would set up a Semaphore/lock specifically for that transaction - i.e. I would not rely on the IPE structures or DVRs for ensuring that the transaction is atomic.

Regarding deadlock, I'm pretty sure that you can avoid this altogether by ensuring that class methods do not ever put methods of their own class inheritance hierarchy inside of IPE structures used to operate on class data.

Did I miss anything?

Thanks,

What am I missing?

You're not missing anything - LabVIEW is.

Your tool makes me both happy and sad, both motivated and depressed.

It is nice to see people using classes and using them so much that they write tools to extend them and make them more useful. It's just this particular tool... you see, this used to be in LabVIEW, but it never shipped. First I was told -- by multiple sources -- that using a text display was bad, that it needed to be the icon display or whatever the user had configured in their Tools>>Options for palette displays. Ok, so I made LV build an on-the-fly graphical palette. But then it was shot down because the layout was inconsistent: things in the palette shouldn't move when a new VI is added to the class, but adding new VIs at the end means nothing is ever findable. Can't you make it alphabetical but read my mind and not be alphabetical when I don't want them to be? Shouldn't virtual folders have something to do with it? Why aren't the parent methods folded in? Why are they in sub folders? Shouldn't they be in superfolders? What the heck is a superfolder? Perhaps the palettes should be named in iambic pentameter. Can you make all the icons rhyme?

Eventually I went crazy, had a nervous breakdown, and killed the feature. Clearly, anything we did automatically was undesirable. Another member of my team made it so that a .mnu file could be associated with a class so that users could define their own layout for the VIs. I've never felt like revisiting the issue.

I commend your work on this feature. I am surprised this thread is not full of people complaining about how useless it is.

Thanks for sharing this story. On my side of things, I've been frustrated by the lack of usability features in LabVIEW related to LVOOP. It makes me happy to know that you've been fighting the good fight. Please let us know how we can help.

One thing that I've started doing with the DVR-inside-LVOOP scheme is using an IPE Structure to (un)bundle the DVR reference outside of the IPE that (de)references the private data. I like this a lot because it keeps the object/reference/data wire in straight line without any branching -- it seems to have the best "style". Note that I named the DVR "ref" to keep the (un)bundle nodes small in width.

What do you think?

I thought that this JKI RCF plugin was so cool that everyone needed to see it. Thanks, Jeffrey for this cool tool!

I've been having another play with the concept of datamember DVR inside object ref and it’s appearing to be solid.

The only thing you need to watch is that you don't perform a method call inside an In Place Structure DVR R/W that acts on the same data. So placing a method of the same class or a parent method with dynamic dispatch will cause it to lock. Placing a parent only method inside a child method's InPlace Structure DVR R/W is OK since it only acts on the parent data which has its own DVR. But in the end it’s the same kind of rules you would use as before when you had lock and unlock primitives in previous architectures.

I haven’t been able to create a race condition as a result of implementing parent and child data member DVR’s. Since parent data is accessed in a child by parent methods the data is protected, the data locking protection mechanism exists at all levels of the object hierarchy.

Hi Kurt,

I'm happy to hear you say this, since I've come to the same conclusion while talking it over with other members of my team. IMO, the value of being able to Dyamic Dispatch any method, regardless of whether it's a by value or by reference method, without having to create special, duplicate by reference wrapper methods around dynamic by value methods is huge.

The only downsides (that I can see) of using the DVR inside an LVOOP object are:

1) You can't tell just by looking an an object that it's by reference (as you can when you see a DVR with an LVOOP object inside)

2) You have to unbundle the DVR before you can pass it into a IPE Structure

Oh, and there's one situation that you also have to be very careful for:

If you're inside a child method and you call a parent method inside an IPE structure, you might deadlock if the the parent method is itself, or calls inside of it, a dynamic dispatch method that results in child method being called.

With this in mind, one feature that I'd love to see in LabVIEW is for IPE structures to be smart at run-time and output an error (rather than deadlock) if an IPE is called inside another IPE and tries to dereference data that has already been dereferenced by the outer IPE.

Cheers!

Thanks for the update. I too have seen the lockup. It can be not-so-obvious too. That is, you could call what appears to be a parent method that then calls a dynamic dispatch method that ends up attempting to access the same DVR you started in. Hope that was clear .

All in all, I am finding this a very sweet way to implement objects as references yet still allow me to have dynamic dispatch work. I am still expecting to find a 'gotcha', but for now I am enjoying the feature.

I have modified daklu's DVR Composition project such that it implements the member vars as a DVR of a cluster. The original DVR Composition project primarily showed an approach to facilitate Interfaces and Implementations by using DVR's of objects. The addition of DVR member variables eliminated the IPE structures from the general application code seen in Main.vi and reduced the casting that was used inside the IPE of the Multiply By Two Implementation. I hope to post this soon with some screen shots. My biggest problem is that my development machine is not on the network and my network machine is restricted to have only certain applications. So the transfer is just one more hurdle.

Between your scheme of DVR'd member variables and daklu's Interface/Implementation work, this solved a huge problem I was having in my project. I also plan on posting some of this too. I am a bit restricted on what my employer will allow me to publish .

I see that you posted similar thoughts, just as I was typing up my reply to Kurt, above

Cool! It seems that we're all starting to converge on the preferred methodology (pun appreciated but not intended) for by ref OOP in LV2009.

I guess that I would add that if NI were to implement either the ability to dynamic dispatch on methods with DVRs of objects OR the ability to wire a DVR of an object into a by value method (dereferencing/referencing behind the scenes) then I would probably migrate over to DVRs containing objects, rather than vice versa. But, until then...

So I thought that if the class just holds the DVR of the datamembers then I get dynamic dispatch without any fuss and I have a reference to my datamembers giving in effect a object that has by ref characteristics.

Hi Kurt,

I've been looking at your example reference classes (Bike+Racer) and I'm starting to second-guess my decision about wanting to put the DVR outside the object (rather than put the DVR inside the object).

I how your example (DVR inside the object) allows dynamic dispatch at the public method level (instead of having a static, by reference method that wraps a protected, dynamic, by value method -- this creates a lot of extra methods).

However, one thing that makes me uneasy about putting the DVR inside the object (as your example does) is that each level of the inheritance hierarchy has it's own DVR and is locked/unlocked separately. I worry that this could cause some nasty race conditions or deadlock -- have you thought about this? And, an attempt to remedy this issue takes us back to where we have a lot of framework/support VIs for each class.

Cheers,

Replies to this topic should be made in the Idea Exchange where this was cross-posted. That way the evaluation of the idea can all be in one location.

Agreed. I posted this to LAVA so that I could edit my idea yep, I'm gaming the system

I've closed this topic. Please discuss in the Idea Exchange thread for this request.

I looked at your example. My understanding of Object References is different. See Images.

One issue to resolve with this method is dynamic dispatching. It seems that you can't do dynamic dispatching using Data Value reference terminals. Hopefully this will be added in a future LabVIEW release. In the meantime you will probably have to do dynamic dispatching inside the In Place Element Structure.

I agree that the class should wrap a DVR to a cluster, but rather the DVR should wrap the class.

However, I'm not sure that I agree that we need dynamic dispatching of reference terminals. I think that I would prefer to be able to pass an object reference into a by value method and have LabVIEW automagically dereference and re-reference the object behind the scenes -- almost list wrapping the by value method in a IPE Structure on the block diagram of the caller that is using an object reference.

I believe that the default value of the class Inheritance setting "Restrict references of this class type to member VIs of this class" (which is new to LV2009) should be FALSE. The default value is currently TRUE.

I feel that the default value of TRUE adds an unnecessary constraint on users of value objects, which limits their ability to program applications.

Here is my argument:

There are two use cases for DVR's to LVOOP objects:

Use Case #1: DVR of a Value Object

A DVR of a value object (VO) is simply a DVR to a VO instance that is created by a user of the class in order to facilitate synchronous access to a VO from multiple locations of their application. In any case, a VO class designer does not care whether users of the VO create a DVR to facilitate memory management or parallel access to the VO and the the "Restrict references of this class type to member VIs of this class" setting should be set (and ideally default) to FALSE.

Use Case #2: Reference Object

A reference object (RO), by my own definition, is an instance of a class that was designed/intended to be used only in a by reference fashion. Such objects usually have setup and teardown (create/initialize and destroy/uninitialize) requirements that should be under the control of the class designer. In such cases, the "Restrict references of this class type to member VIs of this class" is very useful and should (IMO) be explicitly set to TRUE by the class designer. However, by assuming that all classes should have this value set to TRUE, it assumes that all classes are intended to be used by reference. This restricts use case #1 by default, even though it has no requirement on how the VO is created or destroyed.

Thanks for listening