08-30-2010 02:04 PM
Maybe simply change their name so that people not confuse them with text-based "Local" variables.
Ray, I very, very agree with this. When you come from a text based language and you look for the variables (which is really clever, look in some manual for variables when you are faced with LabVIEW the first time), you get presented locals and globals AND NOT THE WIRE! It's not the poor guys that write such bad code we should blame, it's that 'we' name these 'control update nodes' wrongly after a basic programming concept.
Someone should get a rename for them on the IE. Ray?
Felix
08-30-2010 02:38 PM
@Ray.R wrote:
I was thinking about that this morning.
Then you would have people not wiring the error-in/out...
Maybe simply change their name so that people not confuse them with text-based "Local" variables.
Humm..... in essence, they are similar, in that it is local to the VI or function... But it is more of a copied instance of the data than the variable itself..
If it wasn't for the dataflow and the parallelism in which LabVIEW executes, then they would be fine...
I don't know what the solution is... And I hate seeing the communitu divided by a Local Variable.. 😞
I second the rename option, it would cut most of the problems in the bud.
Just thought I'd expand on a point mentioned which I'd never actually considered.
Shane
08-30-2010 02:39 PM
@Ben wrote:You would have to re-invent the local such that it was protected by a semaphore so we could do a "Locked-Read" proprty taht would return the value along with a semaphore locking reads of the local until that thread wrote back to the local and released the semaphore.
So whole idea;
Only one local write allowed.
All others must be a protected write.
Seems silly,
Ben
I meant only to be able to determine the time of readint / writing the local. I can't comment on the rest. I have too little experience with Locals....
08-30-2010 02:40 PM
Totally agree with you both.
We could look at tbob's idea of a WORM Global..
We could adopt the same WORM for Locals. And then, no more problems.. Heck, I'd probably end up using Locals (or whatever they are named).
It probably upsets the newbies to LabVIEW that we're telling them that Local Variables are not what they think they are when comparing to a text-based language.
They probably think we are completely insane when we mention that the wire is the variable.. Wouldn't you? 😉 "we're insane, but that besides the point"
But what name could we replace "Local Variables" with?
08-30-2010 02:45 PM
@Intaris wrote:
@Ben wrote:You would have to re-invent the local such that it was protected by a semaphore so we could do a "Locked-Read" proprty taht would return the value along with a semaphore locking reads of the local until that thread wrote back to the local and released the semaphore.
So whole idea;
Only one local write allowed.
All others must be a protected write.
Seems silly,
Ben
I meant only to be able to determine the time of readint / writing the local. I can't comment on the rest. I have too little experience with Locals....
I like the idea of setting or having to set a write permission before being able to write again, kind of like a semaphore, but not 100% a semaphore.. It would be a lock triggered by a write and would require a property node or special function to allow writing to it again.. However, that would not prevent someone from always resetting the write operation all over the block diagram...
We have to think about this one so that it is either fool-proof or crazy enough that someone would not want to abuse the use of the Local.
I kinda see the code in my mind... Maybe I should post an idea of what's brewing..
09-16-2010 11:09 PM
Unfortunately, sometimes people inherit really bad code. Attached is just a small sample. And I DO mean small sample.
09-17-2010 07:25 AM
@Ray.R wrote:
[...]
But what name could we replace "Local Variables" with?
I think of Locals as mirrors, which can lie. How about "Value Mirror", or "Local Mirror"?
09-20-2010 08:52 AM - edited 09-20-2010 08:53 AM
Original source: The worst LabVIEW documentation of all time: this article shows two uninhibited loops (100% CPU) and a race condition, but does not warn against the practices. Below is a sample from the documentation:
09-20-2010 11:52 AM
Wow!
09-20-2010 02:41 PM