Daklu

I only know them from Java and only enough to use them in not to complicated ways.

After my last post I tried to find the information I had originally read. Searching for "software engineering futures" or any of the many variations I tried returns long lists of articles on the future of the industry or stock market trading. The one small piece of information I could find about Futures as a software construct was in Java documentation. That described blocking as an integral part of Futures.

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.

To me, not wanting the results from the Future defeats the point of using the Future in the first place.

All that said I do think there are problems to implement Futures in such a way in LabVIEW.

I agree implementing the Java model in Labview is problematic, but by stepping back and looking at the intent of Futures instead of their behavior in Java I think we can come up with reasonably good alternatives. Their intent appears to be to avoid blocking the current thread while waiting for information not currently available by creating a token that will contain the information later. What I did is apply the concept of Futures to messaging between existing threads. The implementation is very different from Java's but the intent is the same--avoid blocking the current thread by waiting for information.

I don't do Java programming, but my feeble understanding of the normal programming model is the app has a main thread and the developer creates new threads for specific asynchronous tasks. From that point of view it makes sense for Futures to automatically spawn new threads--the asynchronous code requires it. As near as I can tell the Java implementation closely follows the Asynchronous Call and Collect model made available in LV2011. In Labview we can write asynchronous code without dynamically creating a new thread (or Start Asynch Call in LV) so I don't think it is a necessary feature in a LV implementation.

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.

I know you have a much better understanding of the low level interactions between LV and the OS than I do, so this is a request for clarification, not an attempt to correct you.

Even though there is a theoretically unbounded pool of operating system threads, the hardware still limits the number of parallel activities that can take place. Java may allow a unbounded number of operating system threads while LV transparently manages a fixed number, but a program written in G can have an unbounded number of "Labview threads." I don't see how there is much difference between Java's OS thread pool and LV's technique of dynamically mapping parallel execution paths to a fixed thread pool. They are both constrained by the same resource--CPU threads. Can you elaborate?

So I don't see how one could implement Futures in LabVIEW in the same way and still stay generic

I agree achieving the same level of genericism isn't possible in Labview. Given NI's focus on providing a safe environment for novice programmers it may never be possible. I don't agree the concept of Futures is useless for LV developers simply because we can't implement it in the same way.

and one of the reason I'm not convinced diving into LVOOP is really worth the hassle

My car isn't a Audi, but it still beats using a tricycle for transportation.

Hi, im looking for opinions/advice on best way to create a re-useable code for e.g test program, Automated machine programs. That can be modified for different projects, would you say using a standard State machine template would be best?? Any opinions would be greatly appreciated.

Stu

Your question is far too broad. It's a bit like asking, "I need flexible transportation. Should I get a skateboard?" There are dozens of additional details we need to know before we can help you decide if a skateboard is a good solution for you. It could be a great solution for a teenager living in suburbia. It's a much less desirable solution if you need to do grocery shopping or had a leg amputated.

In the same way there are dozens of additional details about your specific application we'd need to know about before we can suggest an architecture. 0_o listed some of them. You say you want "reusable code that can be modified for different projects." How different will the projects be? What elements will stay the same and what elements will change? Are you working in a lab environment where each project is a temporary setup and tweaking code is part of the discovery process, or a production environment where code needs to be extremely stable and software releases are significant events?

The nature of your question leads me to believe you don't have a lot of experience designing software. (I see you've used Labview off and on since 98, but writing code is not the same as designing software.) I suggest your first step to creating modular (and reusable) software is to learn how to separate the user interface from the business logic. Write your application so you could replace the entire UI without breaking any of the business logic. You can use the lessons learned from that exercise to modularize the rest of your application.

To answer your question more directly (but less usefully,) I would say using a standard state machine template is best if it's the best solution for your requirements. Perhaps slightly more useful advice is this: use the state machine template only if you are designing your application (or that part of your application) as a state machine.

As an aside, I wouldn't consider any of the bundled templates an "architecture." They are implementation templates, not architectural templates. An architectural template would be a LV Project prepopulated with tens or hundreds of vis implementing the architecture of choice.

1) Isn’t the point of futures to block (not poll), just like synchronous operations, but to delay the block until the information is needed, rather than when it is requested? It’s “lazy blocking”. And very similar to standard LabVIEW data flow (blocking till all inputs available).

The information I read about them described them like an IOU in a "I don't have the data now so I'll give you this instead, and later on you can turn it in to get the data" kind of way. The point was to avoid blocking, not just postpone it. That said, I've not used them in any other language nor seen how they are implemented, so what do I know? For all I know what I implemented aren't really futures.

So, in my opinion, this concept of futures is a good concept to have in one's mental toolbox, but one that should be deployed cautiously.

Agreed. I haven't needed futures again in the 7 months since the original post.

• Needy creates a message to send to Supplier that includes a description of the data needed and a block of data we'll call "Why" for now.
  
• Supplier receives the message. It creates a new message to send to Needy. That message includes the requested data and a copy of the Why block.
  
• Needy receives the message. The "Why" block's purpose now becomes clear: it is all the information that Needy had at the moment it made the request about why it was making the request and what it needed to do next. It now takes that block in combination with the information received from Supplier and does whatever it was wanting to do originally.
  

Conceptually I understand what you're saying, but I'm having a hard time figuring out if it would have been a simpler solution in my particular case. (In fact, my actual implementation does use something similar to what you describe, though in my case it is simply a data identifier and is more of a "what" block than a "why" block.) Probably not, but let me think out loud for a bit. Anyone can jump in with alternatives or to point out flaws in my reasoning.

The most obvious difference between query/response messaging and futures messaging is the number and sequence of messages transmitted between the two actors. Here are sequence diagrams for synchronous messages, asynchronous query/response messages, and asynchronous futures messages.

One of the issues I've struggled with in actor based programming is message sequences. Understanding an individual actor's behavior in response to a message is fairly straightforward, but combining actors to create higher level behaviors often requires coordinating actors' actions using specific message sequences. It can be quite difficult to figure out a higher level behavior by reading source code when you're having to trace messages all over the place.

With the query/response messages, the behavioral code is split between the MouseBtnClick event and the ResolvedPosition message handler. Not only do I have to mentally combine the behaviors from those two locations, but I also have to figure out if there are conditions where MotionController will not send ResolvedPosition messages and what happens in the UI if it doesn't receive all the ResolvedPosition messages. This is not insurmountable, but it does require a fair bit of work and I'm not entirely happy with the solutions I've used.

The "fire and forget" nature of futures allows me to write the behavior's implementation largely within the code handling the button click event. There is no ResolvedPosition message handler, so I can look at that one block diagram and see the entire sequence of actions that occur in the UI component as a result of the mouse click. In this particular case the code is much easier to read and reason about. (At least it is for me, but I wrote it so I'm hardly an unbiased observer.)

There are other difficulties with using query/response messages here. My UI's display and behavior change when going through this process, so it is implemented as a separate "Alignment" state in UI code. From the user's perspective the process is complete as soon as the fourth mouse click is done. From the programmer's perspective the process is complete when the DoCalc message is sent. The mismatch makes defining an Alignment state exit condition problematic.

In my state machine implementations data that is specific to one state is not available to other states. The ResolvedPosition data will be discarded when the UI switches from the Alignment state to another state. On the one hand I can't leave this state until all four ResolvedPosition messages have been received and the DoCalc message is sent. On the other hand, the user expects the application's UI to revert back to normal after the fourth button click. How do I satisfy both requirements?

Potential options include:

- After the fourth button click, wait an arbitrary amount of time for the remaining ResolvedPosition messages.

- Move the ResolvedPosition data from state specific data to state machine data, so the following state can continue the Alignment process.

- Refactor the UI layer's state machine so UI Display and UI Behavior are separate state machines.

None of the options were particularly appealling at the time. The first two seemed like bad ideas (still do) and third was too time consuming and adds a level of complexity that wasn't needed, since this is the only place where changes to UI behavior and UI display aren't simultaneous.

Personally I'm not a big fan of query/response message sequences. I'm not opposed to them on principle, but they don't seem to fit very well with how I do event-based programming. In general I try to push data out to where it will be needed rather than pull it in by querying for it. Like I said earlier I haven't used futures again since my original post, and to be honest I'm not entirely sure what combination of conditions makes it seem like the right solution in this case.

It could be that the UI doesn't actually use (or even see) the data in the future--it just holds on to them until the user has clicked the button four times and sends them to the Motion Controller for processing. It could be that I wanted to keep the transformed data type out of the UI code to help maintain encapsulation. It could be that the UI already had some inherent statefulness I wanted to leverage. It could be that subconciously I had a solution looking for a problem and I've become attached to it. It could be all of the above or none of the above. I dunno...

Do futures really avoid saving state when compared to asynch messages. I will agree that the *type* of the state information that must be stored is different, but not necessarily the quantity or complexity.

I think we're talking about slightly different ideas of "state." An application's or component's "state" can be said to have changed any time a piece of its data in memory has changed. I'll give that concept the adjective-noun description, "data state."

In this thread when I'm referring to state I mean "behavioral state," where an application or subsystem responds differently to a given input. I usually implement that by changing the set of message handlers processing incoming messages using techniques I've described elsewhere (though when faced with time constraints or very simple behavior changes I might grit my teeth and use a flag instead of implementing an entirely new state.) My remark about implementing a new state being "too heavy" refers to adding a new behavioral state to a state machine, not simply adding a flag to change the way a specific message handler works.

I agree the total amount of memory used by the application to store the application's data state isn't reduced by an appreciable amount, if at all. Run-time decision making has to be based on a value somewhere in memory regardless of the implementation. I'm leaning towards disagreement on the question of complexity, but source code complexity is mostly subjective anyway, so I'll not belabor the point.

If you have to introduce a new state to check the notifier, you're on a dark dark path. And I've seen this happen in code. In fact, it happens easily.

I assume the "new state" you are referring to is being implemented as a flag of some sort, such as a "waiting for message" boolean. I've seen code go down that path (and written some myself) and agree it leads to a tangled mess if one does not keep the larger architecture in mind.

In my terminology, a chunk of code is only a state machine if it can be described by a state diagram. (Note to readers: A flow chart is not a state diagram.) Systems whose behavior is controlled by a flag parade often cannot be represented by a state diagram. Adding a "new state" to code that is not implemented as a state machine first requires a state machine be implemented. And then the new state must fit in with the rest of the state diagram, with clearly defined entry conditions, exit conditions, and behaviors while in that state.

The whole point of futures is that Needy *knows* it will need this data shortly. So it sends the request, then it does as much work as it can, but eventually it comes around to the point where it needs that data. What happens when Needy gets to the Wait For Notifier primitive and the data isn't ready yet? It waits. And right then you have defeated much of the purpose of the rest of your asynchronous system.

Actually, I set the timeout to zero on the WFN function specifically because I didn't want to bind them together in time. The notifier was just a convenient way to to make the future a by-ref object. In retrospect it would have made more sense to make my future using a DVR instead of a notifier, since the option of waiting until the notifier is sent is unnecessary in my case.

If the application logic made it possible to use the future before it was filled, I'd probably try to do some sort of data validation at the point where the future was redeemed. The Future.GetValue method could return an error if the notifier has not been set. MotionController would detect that and send out an "AlignmentCalculationFailed" message. The error would be forwarded to the UI, which would then alert the user that the alignment needs to be redone. (That's just off the top of my head though... no idea if it would work well in practice.)

Cool video. Too bad it stops just when it was getting interesting.

I don't quite understand your comment though. Game theory is just a way to predict behavior of beings who behave according to their own self interest. It doesn't cause people to act in their own self interest.

(And to clarify, by "self interest" I mean whatever gives a person the most utility, satisfaction, etc., not what is in best long term interests.)

I would much rather have slow steady growth... then this crazy roller-coaster economy...

I suspect most people--including me--would agree with you. I just don't think it's a realistic goal. How do you propose we do that? The economy is perhaps one of the most complex systems we deal with. It has so many inputs and interactions it is impossible to fully understand. We don't have the ability to manage it, much less control it. Heck, we don't even know how measure it adequately.

and increasing ignorance of scientific facts that point to a worse future for everyone.

It's not ignorance of scientific facts. It's distrust of scientists who have become political advocates. It's recognition that science is not, and never has been, the arbiter of truth. Beating people over the head with "facts" and "scientific consensus" is useless because it entirely misses the point. (Not that you have been doing that, but it seems to be the tactic most frequently employed by those espousing stronger environmental policy.)

I think we need better laws to govern them...

Disagree. The laws are--for the most part--adequate. Laws didn't prevent Enron or Bernie Madoff from happening.

More laws and more regulations isn't the answer. It doesn't work. Throughout history people have shown remarkable ingenuity in finding loopholes in the laws (or ignoring them altogether) to advance their own self-interest. The idea that we can create a legal system to force people to behave morally is a fallacy.

...and limit their ability to influence those laws.

Strongly disagree. How do you propose to accomplish this? A corporation is simply a group of people united in a common interest. You cannot legally limit a corporation's ability to influence government without also limiting the individual's ability to influence government. Public participation in government via voting, contacting their representative, political discussion, etc. is what democracy is all about. Corporate influence over legislation is not inherently bad. Can it be misused? Yes. Is it sometimes abused? You bet. Is that sufficient reason to trample all over the first amendment? Nope, not in my opinion.

(By the way, corporations already are more limited than citizens in their ability to affect the political process.)

But I know there are external costs (like pollution) that corporations are not forced to incorporate into their profit/loss calculations. This should be changed so corporations make better choices.

Several objections:

1. Corporations *do* pay for things like pollution and they directly affect their profit/loss calculations. They have to purchase, implement, and maintain pollution control system. They pay hazardous waste disposal fees. They are subject to penalties when systems fail or illegal emissions are discovered. They may not pay enough to induce them to behave how you think they should behave, but they do pay.

2. Before you can implement a "change so corporations make better choices," you have to define what a "better choice" is. That's far too vague to be actionable. "Better" is entirely subjective, so you'll have to be specific. You may think it is better to impose stricter environmental controls on industry, but the 400 people down at the paper plant might disagree when the plant closes because it cannot afford the costs associated with compliance.

Too many people think corporations will do what is in the public's best interest if you leave them unfettered by regulations. That is pure fantasy.

I don't personally know anyone who thinks that, though I can understand how the ideas can be interpreted that way. Corporations will act in their own self interest; that is patently obvious. But you know what? Everyone acts in their own self-interest. The only difference is a corporation's self-interest is measured in dollars and an individual's self-interest can't be measured.

There is an interesting story (http://www.thisameri..._Transcript.pdf) about how McCain and Feingold sat in the court the day that was decided and commented to each other how it was clear the justices had very little understanding about how campaign financing worked.

Interesting article. Thanks for the link.

I knew McCain and Feingold were disappointed with the decision, but the conversation just reaffirms what I said earlier. They are disappointed (perhaps rightfully so) because of the immediate impact the decision has on campaign financing. Not once do they talk about the potential consequences of allowing the government to restrict political speech, which at the core is what Citizens United was about. I don't like the effect of the decision any more than you, but the effect of the opposite decision is much more frightening to me. Restricting speech is not the correct way to clean up politics.

Best way to prevent that is to audit the regulators...

Who is going to audit the auditors?

like allowing corporations to choose who regulated then

Agree that seems silly and a huge conflict of interest.

I understand how you feel corporations should have some say in what regulations are imposed on them, but in the real world, that just does not work. Giving them the power they have now has guaranteed failure of regulatory agencies.

It may be they currently have too much control over the regulations, but that doesn't mean they shouldn't be allowed input into the process. Does a judge lose objectivity because he listens to a defendant's argument? The only way a judge can act fairly is to hear arguments from both sides. Why should regulatory agencies be any different when making decisions on regulations? Regulatory agencies are in a position of power, and any form of power is subject to abuse by those who hold it. We can put checks in place to try and prevent abuse, but they are all imperfect and corrupt people find ways around them. Taking away a corporation's voice isn't the answer to corruption.

It is just way to profitable for them to invest in lobbiest than to deal with the costs of a regulation. Go Read this: (http://www.npr.org/b...t-in-a-lobbyist)

Read the article--unimpressed. Listened to the podcast--still unimpressed. Downloaded the study and read it. Now it makes more sense but I'm still unimpressed by it, and even less by the NPR article because it appears to willingly overlook the realities of the situation. (And I usually enjoy NPR.)

The article's tone strongly suggests that corporate lobbying is used to exert unethical control over legislation, broadly painting corporations, lobbiests, and congress as immoral for participating in the activity. In reality, congress' real choice was to either pass the bill allowing them to bring in the money at a 5% tax rate or not pass the bill and let the money sit offshore. The study even points out evidence that businesses often leave their offshore earnings in foreign accounts rather than pay the 35% tax rate to bring them back to the US. NPR doesn't mention that at all. Furthermore, the intent of the bill was to allow the businesses to repatriate the funds for the purposes of creating jobs. (It did not achieve that goal for a variety of reasons outlined in the study.)

The NPR article is a classic example of a false dilemma. It presents the businesses as having the option between 'being selfish' and lobbying congress for the 5% tax rate at the expense of Joe Q Public or 'being good corporate citizens' and paying the full 35% tax rate. That is inaccurate, misleading, and irresponsible. It also feeds the public perception that corporations have undue influence over the legislature, when the study doesn't claim or support that idea in any way. Who is the real immoral entity in this scenario?

I assume you're referring to class members like "Message Constant.vi" and "Message Control.ctl?"

Message Constant.vi allows me to put the class constant on the block diagram palette. It doesn't have any terminals and is not intended to be used directly on block diagrams. Message Control.ctl allows me to put a class control on the front panel palette.

My point was the people who run the corporations hide behind the construct to justify immoral or more correctly amoral behavior. Even CEOs will say not to blame them for what their company does to the environment, citizens, other entities as long as they follow the law and do these things in the name of 'increasing shareholder value'.

I'm getting a decidedly anti-corporate tone from your posts. Forgive me if I'm reading too much into them.

If I understand correctly, you are essentially criticizing corporations because they are inherently amoral and you believe they should be held to a moral code outside of the law. I believe expecting a corporation to behave morally outside of a legal framework is irrational and impractical. Just as well to criticize a tiger for eating meat.

First, there is no universally accepted moral code. What I think is moral may be different from what you think is moral. Whose moral code should businesses adhere to? I agree sometimes corporations act in ways that upset me. Consumers have a couple ways of influencing the legal but morally questionably actions done by businesses--we can choose not to purchase their products and services (unless the business is a monopoly over a necessary service) or we can lobby our legislature to create a law making the action illegal. When enough people agree their actions are immoral, the business is prompted to change their actions.

Second, there are likely to be undesirable side effects to self-imposed moral restrictions. For example, suppose a significant fraction of the population believes organ transplants are immoral. Should transportation businesses refuse to transport the organ because it is enabling immoral behavior? How do you justify that decision to a grieving mother whose child died because a suitable heart in Miami couldn't be flown to Chicago?

Third, like it or not our society is built on competition. The competition forces businesses to seek ways to do things faster and cheaper. There's very little room in the business environment for a business to voluntarily adopt purely moral policies that increase costs. That puts the business at a competitive disadvantage, possibly to the point of causing the business to shut down. Who suffers most when that happens? The employee who find themselves without a job and the shareholders now holding worthless stocks. In the case of public companies the executives and board of directors are caretakers of the public's money. Unnecessarily decreasing profits is irresponsible use of the shareholder's money.

"You can't legislate morality" is a phrase I remember hearing from many abortion rights activists. I tend to agree with that, though to be more accurate I'd say, "you shouldn't legislate undecided moral issues." I believe it is a valid general principle that helps preserve our freedom when it is applied to legislative ideas. At the end of the day the highly publicized failings aren't caused by inherent flaws in corporations or governments--they are caused by human nature. Any system preventing everyone from acting on those less desirable traits (greed, envy, etc.) will necessarily restrict our freedom to act on our more desirable traits (compassion, honor, etc.) At that point we are no longer human, we are robots.

Typically the public reaction to Something Bad Happened™ is to demand the government to do something to prevent it from ever happening again. I get the impression people believe it is their right to not have bad things happen to them. We expect to create a system which prevents imperfect beings from behaving imperfectly. The long term consequences of that mentality frightens me. Freedom means that people are free to choose actions that advance their own interests at the expense of everyone else. That's not to say there should not be consequences for those actions, just that we cannot reasonably expect to prevent everyone from participating in the action. Like I tell my kids, "Life isn't fair. Get used to it."

So, since corporations are amoral, we need to take away these 'human rights' that were incorrectly granted them.

I assume you're talking about the recent supreme court decision regarding corporate political donations? That a whole 'nother rat hole to explore. For the record I think the decision was correct even though I don't like the consequences of it. Most of the objections to the decision I've seen center around the impact of the ruling. I'm not particularly fond of having the supreme court issuing rulings based on expected side effects. Their job is to interpret the law as it was written and intended. We have a mechanism in place for changing laws and the constitution. Hoping the supreme court will short circuit the process is asking for trouble.

That is one reason I get upset at people who deride government regulations. "We the government" are the only thing keeping corporations in check.

Agreed, though regulations and regulation agencies are not the solution they are often made out to be. Often regulation agencies are captured by the industries they are designed to oversee. (See Regulatory Capture.) That can be worse than no regulation at all.

What's the solution? The agency cannot operate in a vacuum; it has to have close connections with the industry it oversees. It would be irresponsible for an agency to unilaterally impose restrictions without understanding how the businesses in the industry will be affected. It is necessary and proper for any entity--individual or corporation--to have the ability to present their point of view to those who govern them. How do you stop a business from having "improper" influence over the agency that regulates it without eliminating its ability to be heard? For that matter, how do you define what is "improper?"

If you try that, you may find yourself in a can of Daklu soda...

Not likely. There's little market for a soda that blathers on endlessly when you open it.

While the majority of people may have good intentions, our society has built a construct (the corporation) to allow a group of people to shed all their morals.

You're an employee of a corporation. Have you shed all your morals? Contrary to popular belief, I certainly didn't check my morals at the door when I was part of Microsoft. I've run across people who seem to have few moral guidelines, but they didn't become that way because they were part of a corporation.

...there is a strong incentive (profit, maximizing shareholder value) to take actions without considering consequence that do not effect profit.

I agree with this. I disagree the fault lies with corporations--I lay the blame squarely at our own feet. Corporations chase profits because that's what the public has told them to do, as evidenced by where we invest our retirement money and stick our children's college tuition. I'm also unconvinced corporations should consider morals outside of laws and tacit agreements made with their customers.

If it was legal and Exxon could make more money grinding up baby seals and selling them to you as Seal Soda, then they would. Morals don't come into pay, only profits.

If there was demand for Seal Soda and it was legal, then yes, I expect some company would step in and provide it. Morals are nothing more than one's idea of what's right and what's wrong. When enough people agree a particular behavior is immoral, the moral code is made into law and imposed on the entire society. However repulsive I find it personally, I'd argue the legality and demand for Seal Soda is sufficient to show grinding up baby seals isn't universally immoral.

So, what are we (the government) to do? Force the corporations to pay? Pay the tab out of taxpayer money? Or declare eminent domain over the internet and take it away from the corporations?

Why do any of those things? Why do anything at all? I don't think it's the government's responsibility to protect us from All The Bad Things in the World That Might Happen . (I'm not real popular with either of the major political parties.)

Democracy and the free market are pretty good at giving us what we want. They are not good at giving us what we need but don't want. We'd have to toss out the constitution and create a benevolent dictatorship (how's that for an oxymoron) with broad enough power to implement things against our will. Frankly I don't see that happening any time soon.

[Corporations] are all amoral (as an entity). There is no conscience. No guilt. No compassion. No moral obligation to "do the right thing" or indeed any sort of social contract toward community outside those imposed by law. Whilst the beings that constitute the corporate entity may have all these...

I agree with this part...

in itself, it has only one objective - to increase it's market share towards a monopoly via the vehicle of profit.

...but not this. A corporation in itself is nothing more than a legal construct. It has no will, no morals, and no objectives independent of the people who make up the corporation.

I'm just suggesting that the unstated intended consequence (wealth transfer, power grab) is enough to get our rulers to not care.

I see. When I'm feeling cynical I would agree with you. Usually I prefer to believe people are generally good and, for the most part, those in government are trying to do the right thing. I may disagree that what they are doing is the right thing, but I believe they think it is the right thing.

If we don't, someday the planet will do it for us. (famine, disease, etc...)

Yeah, I agree. It may be 5 years, 50 years, or 500 years, but at some point the problems will outpace our ability to develop technology to overcome them. Personally I don't think humanity will be willing to make the necessary changes until after some worldwide catastrophe. Society as a whole operates reactively rather than proactively. The story of Easter Island is an interesting microcosm of what the future may hold for us.

(As an aside, I smile inside every time I hear someone say "earth first" or some other eco-friendly catch phrase. I'm pretty sure earth will survive no matter how badly we abuse it. What possibly won't survive is people. Shouldn't they be saying "people first?")

In fact it is the fossil technology that is subsidised in US and that the green solution would have greater economy

Green solutions are subsidized too so I have a hard time accepting that as a valid argument. All large industries are subsidized to some extent, either through tax breaks, grant money, favorable contract terms, or whatever. I'm not disagreeing with what you said, just pointing out why I don't find the argument particularly convincing.

In fact, economic viability and ecological impact aren't really related to my point--well meaning actions taken today will have some negative impact not discovered or understood until many years in the future. Often the impact is due to changes in our behavior. Recycling gives us the feeling we are "doing our part" to help the environment. What is the logical result of that? I suggest one likely outcome is less aversion to purchasing packaged products, which ironically leads to more packaging being in the system.

Does the savings from recycling offset the impact recycling has on our overall behavior? I don't know... studies suggest people tend to modify their behaviors in a way that cancels out the benefits of the change. Change to flurescent light bulb? People leave lights on. Switch to a high mileage car? People drive more. Give NFL players a helmet to prevent head injuries? They become less concerned for their own safety and head injuries increase. The pattern is there. I'd be surprised if it didn't extend into our environmental behaviors.

The noxious gases that the catalytic converter works on are only a very small fraction of the gases produced, so it doesn’t make a meaningful difference.

I don't know enough about chemistry or the processes involved to speak about this knowledgably, but apparently the EPA disagrees with you.

"But researchers have suspected for years that the converters sometimes rearrange the nitrogen-oxygen compounds to form nitrous oxide, known as laughing gas. And nitrous oxide is more than 300 times more potent than carbon dioxide, the most common of the gases that trap heat and warm the atmosphere like in a greenhouse, experts say..."

"In contrast, an older car without a catalytic converter produces much larger amounts of nitrogen oxides, but only about a tenth as much nitrous oxide, the greenhouse gas."

Perhaps adding another layer on top of LabVIEW to define the flow of messages between actors? Something along the lines of the state-chart add-on?

Yeah, any sort of message routing framework would probably best be presented as a different development environment. I hadn't considered something similar to the state-chart add-on. That's a good idea.

VPL runs on top of the Decentralized Software Services (DSS) framework, which in turn runs on top of the Concurrency Coordination Runtime (CCR.) I suspect the Labview runtime engine can fill the role of the CCR, but NI would have to develop an equivalent for DSS. As far as I can tell, when I run a VPL application the DSS framework is responsible for starting all the services needed by the app. Something similar would have to be implemented for the Labview environment. Also, any actors used by the messaging toolkit would need to have some sort of reflection capabilities so the toolkit knows what methods the actor exports. Not trivial, but not impossible either.

Since there is a push to mainstream the actor framework, this might be on the long term roadmap.

Emilie liked your comment so maybe it is.

Just right click the subVI and select Help. If the VI has a help page, it will be opened directly.

I didn't know that. Thanks for the tip.

Minor point: catalytic converters don’t increase the amount of greenhouse gases, so this can’t be an example of “unintended consequences”.

Can you clarify? Are you saying carbon dioxide and nitrous oxide aren't greenhouse gases, or catalytic converters don't cause more of those gases to be released into the atmosphere?

I suspect that, often, the unintended consequences are anticipated but ignored because of these.

Maybe sometimes... but often? That would require a level of foresight and understanding of complex systems we just don't have. My favorite podcast of all time, Freakonomics, frequently talks about unintended consequences. Here's an article talking about the unintended consequences of three well-meaning laws and how they may do more harm than good.

I wish the US would catch on to more environmentally-friend waste handling. When I lived in Europe for a few months, *everywhere* had segmented trash bins with sections for recyclables, bio-degradable waste, and whatever else.

That's fairly common in the pacific northwest area. I assumed it was a nation-wide trend. I take it your neck of the woods is different?

Anyhoo, the one immutable and unrevokable law regarding any public policy is the law of unintended consequences. What sounds like a good idea today will be identified as the root cause of some crisis 20 years from now. When I was a kid catalytic converters were going to save the world from the terrible evil of automobile pollution. All the bad stuff coming out of the exhaust pipe will be replaced by natural and harmless elements: oxygen, water, and carbon dioxide. 35 years later we're told automobiles are one of the primary sources of greenhouse gases. So much for harmless...

Don't get me wrong, I think it's good to be concerned about the environment and do our best to avoid negatively impacting it. At the same time, I think green technologies and promises of environmental friendliness are oversold to the public. Human civilization requires more resources every year. There's no way to extract those resources from the planetary system and deliver them to where they are needed without impacting the environment. *shrug*

What can be bad about separating trash, biodegradables, and recyclables? I don't really know. I suppose having 3 trucks pick up the waste instead of 1 adds a certain amount of pollution to the air. Purchasing and maintaining extra trucks and employing additional drivers adds cost to the collection service, which in turn is passed on to consumer. Maybe the extra disposal trucks add to traffic congestion, keeping everyone on the road longer and multiplying the pollution effect. Maybe these are real effects, maybe they aren't. But I'll lay dollars to donuts there is some crisis lurking in the shadows waiting to attack our collective conscience in a couple decades.

(Somehow I missed this response earlier. I also don't know what happened to the original message... maybe AQ deleted it?)

I appreciate the reply. Figuring out the terminology is often one of the biggest hurdles to learning different approaches. I have written C# programs and understand the certain parts of the .Net framework, but I'm not nearly as fluent in it as I wish I was. (In particular the whole UI / delegate / event system still puzzles me.) Your explanation helps.

Using Tasks for concurrent programming is still a little confusing. I'll use your example of a button event handler that creates a task to do the 5 second calculation, launches it, and await on it. As I understand it, the state of the local variables in the event handler are remembered and execution "jumps" out of that method to continue processing UI code. When the task finishes the UI execution jumps back into the event handler at the await call, restores the values of the local variables, and continues processing the method from that point. Is that mostly correct?

What happens if, immediately after awaiting on the 5 second task, I press another button that starts a 10 second calculation in the UI thread? Is my UI calculation interrupted to finish the remaining statements in the the first event handler? I guess I'm wondering how the remaining code in a method following an await is scheduled relative to code currently executing in the UI thread. Does the Task response interrupt the UI thread or is the response just added to the event queue to be processed in order?

In Labview I primarily use queues and messages to transfer data between concurrent code. The points at which my parent loop will actually process the response are clearly shown by the dequeue node. I may not know exactly when the response message will be processed relative to other messages, but I can easily see it won't interrupt any other messages being handled. I don't see that clarity in the .Net model. Maybe it's a inherent rule experienced C# developers know about?

In some respects this still isn't as smooth as what MS has done with async/await, but it is a little different for a dataflow language.

Yeah, I can see how the automatic jumping out and jumping in to a method would make it easier to write certain kinds of methods. At the same time, jumping out of an event frame before it has finished and jumping back in to continue from where it left off is a huge dataflow violation and we'd all freak out the first time we saw it happen.

I have admit, the more I think about it the more I kind of like it. Suppose I want to execute lengthy calculations A, B, and C in series when a button is pressed. In really bad pseudocode, using await the event handler would look something like this:

MyMethod handles btn.OnClick

...

start TaskA;

await TaskA;

msg.text = "TaskA finished";

start TaskB;

await TaskB;

msg.text = "TaskB finished";

start TaskC;

await TaskC;

msg.text = "TaskC finished";

...

[/CODE]

It's very clear from looking at the code that each of the tasks will be executed in sequence from this one button click. In G I can't do that. I need to create separate message handlers for when each of the tasks is finished and chain them together in code. The bad pseudocode textual equivalent would be...

This is clearly not as easy to understand as the implementation using await. Furthermore, this code permanently establishes the sequential nature of the tasks. I can't start task B and get a response without also invoking task C. There are way to work around that within the restrictions imposed by data flow (like using UI states to implement different responses to the same message,) but I haven't found anything as simple, clear, and robust as what the task based await approach appears to give C# developers. In some respects await is like an abstracted, [s]generic[/s] anonymous event handler temporarily bound to the Task. You get the same behavior without all the messy delegates and event handling code.

Are there other presentations that you think would work well for async event handling in LabVIEW?

None I can think of off the top of my head, but now that I understand the task-based approach better (assuming my descriptions above are correct) I'll certainly be thinking about it. Message sequences in Labview are difficult to infer simply by looking at code and I've struggled with how to overcome that for a while.

Here's a link to changing the read/write attributes in Windows 7.

Is this an accurate representation of your system? The camera may be taking images at any speed and you want to save all those images, but to avoid choking the connection you're only sending images up to the UI at a maximum of 30 Hz regardless of the image capture rate.

If that's what you're intending, I don't think a priority queue would help you out. The priority queue as I implemented it has the same size for all priority levels. You can't set the internal priority 1 queue to a length of 100 and the internal priority 5 queue to a length of 1. You'd either have to set the length to a low number and risk losing high priority messages, or set it to a high number have the UI show the image the camera took 100 frames ago. (Since the most recent image will be put at the rear of the queue.)

I have no internal knowledge on this...

I do. I actually worked on the Zune team from the time the Zune 30 was released up through the Zune HD. (I was responsible for testing the capacitive touch technologies.) I can't say what the army of MS vice presidents were talking about behind closed doors, but I can share my thoughts as a rank and file employee.

My gut feel is that a lot of what they learned during Zune has gone into the Windows phone, and part of me beleives that the Zune was, at least in part, a precursor to the phone by design.

Yes, Windows Phone 7 does include a lot of what was learned during Zune. No, it was not a precursor to phone by design. Zune was conceived and launched before the iPhone revolution. Windows phone had been fairly successful sticking with the interface it had and there was no reason to change it.

The Zune hardware and Zune Market were designed to compete with the iPods and iTunes that existed at the time. In that respect I think they were successful. In my admittedly biased opinion, Zune was better than iPods and iTunes in almost every way. The hardware was cheaper, offered more storage space, had bigger and better screens, and (imo) was more intuitive to use. It could play video, supported wifi, and had an fm radio. Zune software was way more visually interesting than iTunes, even if it had a smaller music library at the start. The Zune market also offered subscriptions long before iTunes did. (I'm not even sure if iTunes offers them yet.)

Why did Zune fail as a hardware platform? I believe unfortunate timing and poor marketing are primarily at fault. Marketing tried to attract the edgy/alternative crowd and used non-standard channels for getting the message out. That's not a bad thing; targeting early adopters is a good strategy. But the message they presented was, to be blunt, absolutely incomprehensible. (At the time I wondered if the advertisements made more sense with a healthy dose of THC.) I don't remember a single advertisement that highlighted any of Zune's advantages. Looking back, it seems like marketing was trying to "out cool" Apple at a time when the iPod defined coolness.

The iPhone and iPod touch were released a year after the Zune 30, and shortly before the first Zunes with capacitive touchpads. The buzz and excitement generated by the Cult of Apple is always hard to overcome. iOS changed the way things are presented to the user, but it wasn't exactly revolutionary. (Icons on a screen... wheee!) There were still holes in the iOS devices Microsoft could, and did, exploit. The one thing that was revolutionary was its multitouch support. Other devices have supported multitouch (like Microsoft Surface) but it had never been implemented so well on a platform that small.

I was given a couple early iPhones to test and characterize their multitouch capabilities. I'll be honest--it was damn impressive. During Zune HD development we tried lots of different ic vendors looking for a comparable solution. None of them even came close. Their algorithms were either too slow or not robust enough to prevent potential gesture confusion. We went through a lot of iterative development with ic vendors to get their multitouch capabilities up to expectations for the Zune HD. I think the first touchscreen Zunes were released 2 years after first gen iDevices.

(Just to poke a stick in the ribs of Apple fanbois who blast MS for never doing anything original, Apple purchased Fingerworks in 2005 to acquire the touch technology used in the iPhone.)

I don't think Zune hardware sales ever met expectation. During development of the Zune HD there was talk that it was going to be the last retail version and we'd start developing reference hardware platforms manufacturers could use to create their own devices. There were also rumors of providing the Zune software as a stand alone product to third party developers. I suspect around that time Zune executives started shopping it around to other divisions in Microsoft to see if it would stick somewhere.

I think Zune's influence on Windows Phone 7 is simply a matter of WP7 designers finding elements they liked in it. I haven't seen anything to suggest a grand scheme to use Zune as a development platform for the WP7 user interface.

------

In case anyone is wondering why I mentioned those two products, I also worked in MS's mouse/keyboard group when the gaming device group--a sister to our group--switched to home networking. Our devices offered real ease-of-use advantages over other offerings at the time, but the profit margins plummeted and MS bailed out.

You guys know there's a free LabVIEW toolkit for NXT, right?

Yeah, and I've even downloaded and installed it a few times. Never got around to trying it out though...

I've bombed you with a series of messages, sorry about that! Anyway, in case you're more a forum guy than a PM guy, I'll repeat my questions here, along with another question I have.

No worries about the PMs. I just didn't happen to be online when you sent them. Thanks for reposting your questions publicly. I prefer to make questions and answers available for searching.

I'm trying to deploy the messaging system to a real-time system. When I started placing the various VI's, it is asking to save (recompile) the NAtive Arrays and Native Types libraries, but when I tell it to accept and save, it says the library exists and I do not have permission to modify it, can you help me out with this?

I often make my reuse libraries read only. It helps prevent me from accidentally editing them and breaking other apps that depend on them. Labview automatically recompiles code when it is loaded (if it is necessary) so usually it is safe to discard recompiles. If you do want to save the recompiles, just go to the directory in vi.lib and change the file attributes to read/write.

Note: I've only worked on a few real-time systems and I've never used LapDog on one. It's not designed with RT efficiency or determinism in mind. I think it will work fine on a RT system, but it may introduce jitter or other timing issues.

1.) Is it ok to use the deprecated version of Priority queue? (I already know you have to manually create messages, which isn't a big deal).

Yeah, there's no problem using the deprecated version if you want. It will be included in all v2.x packages. I do plan on removing it from the v3 package, but it will not cause any problems with apps you have developed using v2.

Changes that break backwards compatibility (like removing the priority queue) are released as a new package with a new namespace and a new install location. Breaking changes are indicated by incrementing the major version number. That means classes from LDM.v2 cannot be directly used with classes from LDM.v3. This is intentional. It does make it inconvenient to upgrade an application to a new major version, but it also allows users to have incompatible versions of the libraries to be installed and loaded simultaneously. Users can be reasonably confident they can install a updated version of a package without breaking any existing code. (Guaranteed compatibility is nearly impossible to achieve.)

2.) Are there plans to reinstate Priority Queue in future releases? If so, do you have an ETA on that?

I'm undecided. My current thinking is a priority message queue is unnecessary because messages should be processed instantly. If messages are getting backed up to the extent a priority queue becomes desirable then the message receiver should be refactored to eliminate the bottleneck. That's my current line of thought anyway.

There are valid use cases for a work queue, which programmers would intentionally keep backed up so the worker is always running. Message queues and work queues are different concepts and I'm not sure how to separate the ideas in the LDM api. A priority queue blurs the line between the two and--if my current thinking is correct--encourages tighter coupling between components.

Regardless, I don't have any concrete plans for releasing v3. Major releases occur when I have to make a change breaking compatibility, and for the time being I don't see anything on the horizon requiring that. I might have to make some breaking changes if I submit LDM to the NI Tools network, but even then it would likely be a straight repackaging of v2 with a new namespace and install point.

Does that answer your questions?

We had first encountered this way back in 2007. It's good to see that MS did not abandon this project.

Yeah, MS has a habit of jumping into a market for a couple years then abruptly jumping out. (Home networking products and Zune come to mind.) From a business perspective cutting deadwood is good, but as a consumer it can be frustrating.

I've installed Robotic Studio several times over the years, but this is the first time I've actually been able to dig into enough to understand it. I don't believe MS intends to position it as a direct competitor to Labview, but I do think it has long term implications on Labview's future. I'm thinking MS developed Robotics Studio as a platform designed to help flesh out the underlying frameworks, DSS and CRR.

I wonder how this compares to NI Mindstorms environment which uses and MDI interface.

I don't like developing in the Mindstorms environment. It's kind of buggy and I find it hard to do anything moderately complex using the Mindstorms language. My Mindstorms kit sits around doing nothing because I dislike the environment so much and I haven't got around to setting up a better one.

I don't think Mindstorms and VPL are directly comparable. Mindstorms does use an MDI IDE, by it's really limited in what you can do with it. Given that it's designed for kids that's perfectly understandable. More importantly, Mindstorms is a code editor and compiler. If I remember correctly there is almost no debugging capabilities. Code execution occurs on the brick, not the pc. With VPL the code executes on the PC. The set of requirements is entirely different.

Also, look at their web builder IDE for another view at dataflow language IDEs.

It's been on my to do list for... 3 years or so?

I will always <heart> robots.

Robotics is a huge playground for anyone who likes to tinker. How can anyone not <heart> robots?

VPL started as a tool for roboticists, but I'm actually looking at it as more of a general programming tool. I've seen posts indicating people are using it to address concurrent programming issues in other domains. The more I learn about VPL the more... interesting... it becomes.

I'm openly trolling for participants in an api development "contest." The contest objective is to create an api that can adapt to new requirements without affecting backwards compatibility. The purpose of the contest is to gather information about api development and deployment strategies and compile all the caveats and warnings into a document of best practices.

The original thread is here. To keep information centralized please post all questions and comments there.

It doesn't matter if it is one digram that fits on a whole roomfull of screens. I am proffering that more than one screen is shoddy programming. Why? Because I have to run the whole screen in debug to see one bit of it (and assume I don't know which bit I want to see yet).

Perhaps it is your debugging technique that is shoddy? (Just kidding... I couldn't resist. )

I have experienced the same frustration with the block diagram jumping all over the place while I step through a vi. As my programming skills have evolved I've switched back and forth between allowing multiple loops and not allowing multiple loops. With actor-oriented programming I find I rarely need to step through the code looking for an error. Usually it's pretty clear where the error is coming from so I can set a probe and a breakpoint and get the info I need to take the next step. And since most of my loops sit around waiting for a message, in those cases where I do need to step through the code the block diagram doesn't jump around.

Admittedly, sometimes I do create sub vis purely for the sake of saving space because it better establishes readability*. When I do I'll mark it private and put it in a virtual folder named "Space Savers" or something like that to indicate it falls outside of the abstraction levels (both public and private) I've established for that component.

(*When I say readability, I'm not referring to just the readability of a block diagram. Usually I'm more concerned with clarity of the app as a whole rather than readability of any single block diagram. In other words, I favor decisions that help the developer understand how components interact over decisions that help the developer understand any single block diagram.)

Contingent on the architecture being able to keep up with my data update rates!

Sometimes for high throughput data streams I'll create a direct data pipe from the source to the destination to avoid loading down the messaging system. The pipe is just a native queue (or notifier depending on your needs) typed for the kind of data that is being sent. You can send the queue refnum to the data source and/or destination actors as a message. The data pipe is *only* for streaming data; all control messages (StartCapture, FlushToDisk, etc.) are still sent through the regular messaging system.

Maybe by CLADs, but not where I work. I often get berrated for using too much abstraction and too many subVIs.

I'd be willing to bet the total number CLADs >> the total number of crelfs. Ergo, your "excessive" use of sub vis is insufficient to counteract the collective impact of CLADs (and uncertified users) who do not use enough sub vis.

Seriously though, subVIs are great, and, just like everything else, should be used when appropriate. Just to get a little BD space is not one of them IMHO