Leaderboard

Dearest LabVIEW, Sometimes there are simply no words that can adequately express the depth of a person's feelings that are plagued by regret, guilt and sadness for a wrong done. I know it can't undo what has been done and it won't ease the pain in your heart. Instead, let me write this to let you know that I regretted my actions, and cheating on you is certainly an unforgivable mistake. I totally deserve any the anger and resentment from you for what I have put you through. I was tempted by text-based programming, and I was weak. Not because the love between us was weak, but because I was coerced by another - let's just call her "the customer". I knew at the time that it was wrong, but she was so purseuasive. She bought me gifts, she told me I was handsome, she laughed at my lame software engineering puns, she made me feel special. I know now that these were all underhanded tricks so that she could have her way with me. She didn't care about me, ahd only cared about herself, and how I could help her. It pains me to see you suffering as a result of my misbehavior. Guilt burns in my heart thinking of all the hurt that you must have felt because of my recklessness. Each time that I think of you, I get angry with myself, my blindness and foolishness, and my indiscretion. I know there is still a strong love for you glowing in my heart. I truly want us to be happy again with me still being a part of your life. I know I don't have the right to ask anything from you when I have foolishly betrayed your trust in me, but I hope you can find it in your heart to forgive me and give me another opportunity to prove to you how much I love you. Give me another chance and I have faith that, one day, we will look back at this and laugh, albeit uncomfortably. Loving you always, crelf

I have written a paper on the Strategy Pattern (with appendices on Interfaces and the Factory Method Pattern) in the hope that this will be a useful guide to others. We have published a PDF version of the paper: StrategyPatternWithLabVIEW and a zip file that also includes the source and model: StrategyPatternWithLabVIEW--WithModelAndSource. You can comment on the paper here, if you like. Paul

Neither is mine. But it goes much faster and is easier to control than an Audi with a caravan on the back

"Top 10 letters Darren is least likely to ever have to write"

Whether it's worth the effort to change over, I can't say, but it would certainly be a more apt solution. I can imagine how frustrating it is to get support requests like that.. it'd be like me swapping some hoses around in the engine bay, bringing it back to the dealership, and saying, "Hey, your thing broke."

You may regret saying that

I only know them from Java and only enough to use them in not to complicated ways. What they actually do as far as I understand it, is running as a separate thread (which can be a dedicated thread or one from a shared thread pool or a few other variants thereof from the java.util.concurrent package) and do whatever they need to do in the background. If they are there to produce something that will eventually be used at some point in the application you can end up with a blocking condition nevertheless. But they are very powerful if the actual consumer of the future result is not time constrained, such as multiple HTTP downloads for instance. If the HTTP client library is supporting Futures you can simply shoot off multiple downloads by issuing downloads in a tight loop, letting the Future handle the actual download in the background. It could for instance save the received data to disk and terminates itself after that freeing the used thread again. If you don't need the actual data in the application itself you could then forget the Future completely once you have issued it. The way I understand it a Future is some sort of callback that is running in its own thread context for the duration of its lifetime and has some extra functions to manage it such as canceling, checking its status (isDone(), isCancelled()) and even waiting for it's result if that need should arise. What the callback itself does is entirely up to the implementer. Depending on the chosen executor model the HTTP client could still block such as when using a bounded thread pool and you issue more downloads than there are threads available in the thread pool. All that said I do think there are problems to implement Futures in such a way in LabVIEW. LabVIEW does automatic multhtreading management in its diagrams with fixed, bounded thread pools. There is no easy way to reconfigure that threading on the fly. So there is no generic way to implement Futures that run off a theoretically unbounded thread pool should that need arise, and if you start to use Futures throughout your application in many other classes you run into a thread pool exhaustion quickly anyhow. So I don't see how one could implement Futures in LabVIEW in the same way and still stay generic, which is the idea of the Future implementation in Java. The Future itself does not even define the datatype it operates on, but leaves that to the implementor of the class using the Future. That are all concepts where LabVIEW can't fully keep up with (and one of the reason I'm not convinced diving into LVOOP is really worth the hassle )

The ladies fitted tee is now available in the LAVAStore! Note: This is the same t-shirt style we used a couple of years ago, and several of our members said the size chart was skewed - make sure you order a size that larger than what you would normally order (not that I'm trying to suggest anything by that! )

I can't go into any details because the product is not yet released, but LabVIEW 2012 will have a significantly better answer to this question than previous versions of LabVIEW. If you're still looking for an answer to this question come August, check out the new release.