Daklu

@Val Brown Just curious... what do you mean by "duplex language translators?"

Huh. That's interesting--the dark side link I posted has a solution that shows how to do just that. There certainly isn't a way to do it if NI continues its history of giving developers prepackaged solutions, but it is possible. Instead of trying to deliver solutions that meet everyone's use case (which leads to flexibility/complexity paradox), provide the developers with a framework of the elements so they can build their own solutions. You can still deliver prepackaged solutions that meet the needs of 80% of the users, but the solution is built on the framework and devs have some way to customize the behavior (via source code edits or object composition) so devs can modify or extend the functionality as needed. Yes, in principle it probably is possible for someone to create their own graph x-control from scratch, so one could argue NI has already provided the framework. In the same way I can dump a pile of logs on your property and claim you have enough to build a house. Technically it may be true, but for practical matters it doesn't help much. With graphs and charts (and other aspects of LV programming) NI offers us the choice between their pre-built home and a pile of logs. It would be a lot easier to build the house I need if I could get NI to deliver bundles of 2x4s.

I strongly suspect a semi-competant 8th grader could out-argue me in any discussion of grammatical construction. My knowledge is exhausted just beyond noun, verb, and adverb. The debate is kind of interesting though so I'll give it another shot. It won't surprise me in the least if you find my counter-counter-counter-counter argument unsatisfying. I disagree they are similar. The concept of a word is fundamentally different from the concept of punctuation. Words have concrete representations in both written and spoken english. In writing, a word requires some combination of letters. In speech, it requires some combination of sounds. In neither case does the word require other grammatical structures around it for it to be recognized as a word. Punctuation does not share this property. It has a concrete representation in writing but it does not have one in speech. If I show you a card with "car" printed on it, you will recognize it as a word. If I say "car" to you, you will recognize it as a word. If I show you a card with a semicolon on it, you will recognize it as a semicolon. What is the verbal equivalent of a semicolon? A slight pause? If I walk up to you, pause briefly, then turn around and leave are you going to think, "oh, that was a semicolon?" (Emphasis mine.) There isn't a verbal equivalent of a semicolon. Spoken english doesn't have "punctuation." It only has speech patterns. When reading aloud written punctuation is communicated to listeners by modifying speech patterns in the form of pauses, tonal inflection, and volume changes rather than saying "semicolon," "exclamation point," or "question mark." However, having punctuation and speech patterns serve the same purpose (to help communicate meaning) in their respective mediums is not sufficient to claim equivalence between the two concepts. Therefore, likening the statement "punctuation does not exist in verbal communication" to the statement "spoken conversation doesn't have any words" is invalid. I'm going to extrapolate a bit here, because the definition doesn't support what I think you're trying to say it supports. Please correct my misconceptions of your argument. If I understand correctly, you're saying tonal inflections are part of the unique identity of a sentence. In other words, changing the inflections produces a sentence that is uniquely different from the original sentence, so when I used a rising inflection on the final word of "this sentence is ^false" I have created a new sentence instead of restating the original one and lose the bet. Is that accurate? The definition you supplied simply defines what a sentence is. It does not (nor does it attempt to) explain what properties of a sentence define its unique identity. There are no rules for evaluating sentence equivalency in that definition. I claim intonation changes are insufficient to establish the uniqueness of a sentence. Consider hearing the following sentences: (I use the carot '^' to indicate rising pitch while speaking.) "Did you get money from the bank" (spoken monotonically) "Did you get money from the ^bank" (spoken as a question) Both sentences have the same words and the same meaning--I want to know if you got money from the bank. Is the difference in intonation sufficient reason to consider them unique sentences? I don't think it is. If I read the Gettysburg Address at a public gathering using different tonal inflections than Lincoln did, is it reasonable to claim my speech is unique? Again, I don't think so. Most people would correctly say the sentences I spoke were the same that Lincoln did. I won't argue against it as the question is irrelevant unless you can convince me punctuation marks exist in spoken language. Like I said, grammar isn't my strong point, so you'll have explain how the predicate changed. It looks to me like the predicate is "is false" in both cases.

Interesting counter-argument. I'll counter-counter with... Punctuation is an artifact of written communication. It does not exist in verbal communication. As our conversation was verbal and not written, there is no punctuation to be included as part of the sentence. Nothing. He never asked for anything. I noted it at the time, but didn't really think about it until now. It was actually pretty clever on his part to not make me stake something. I had information he wanted. Though we ostensibly had a wager, he figured out how to get the information at no cost to himself by virture of the 13th amendment. Had he required that I stake something on the wager there's always the chance I'll think the risk is too great and not enter the wager, thus eliminating the opportunity for him to get the information. Pretty astute for a 14 year old boy. ...or maybe he just forgot.

Wow, your experience with high school algebra must have been way different than mine. I read through part of the book (the preview on Amazon must contain 80% of the book's pages) and I think it would be a rare 14 year old that would understand or enjoy that book. At $13 it's cheap enough for me to get it with my next Amazon order, but it's scope seems to be beyond a little paradoxical thinking. Why is this your favorite variant? What do you find appealling about it? In some ways it is the opposite of a paradox. The paradoxical equivalent would be to write a book containing a list of all books that do not have their names in their titles. No answer is correct. With your variant both answers are correct. Hmm... it could be used as a way to introduce them to the concept of how a "right answer" often depends on the context in which it's applied. I hadn't considered explicitly separating syntax from semantics, but now that you mention it I can see that's what I did. By altering my tonal inflection I changed the semantics without changing the syntax. I suppose any "disproof" of the paradox would have to separate syntax and semantics to some extent, since the semantics of the original statement is indeed a paradox. (I imagine it's possible to harden the original statement against these kinds of attacks, but "This abstract concept I have in mind that represents an asserted truth value in a system of mutually exclusive truth values is in fact the opposite of the asserted truth value" doesn't roll off the tongue as easily.)

After 5+ hours of fighting this stupid issue, I found the solution in the Legend:Plot Minimum property. Though the property does do what the documentation and property name imply, what it doesn't tell you is the Plot Minimum property is automatically updated at edit time when you fiddle around with the legend. What they also don't tell you is the edit-time update only *increases* the Plot Minimum value, it never appears to *decrease* it. <rant> Grrr... I *know* my irritation level is pretty high right now and I'm likely not thinking this through, but this reeks of a poorly designed api. Why in the world would I expect the "Plot Minimum" property to behave like that during edit-time? Asymmetrical behaviors should be avoided if at all possible, and if it's not possible to avoid them they need to be documented. </rant>

Yes, the chart display will do that, but the legend seems to "remember" all the plots regardless of whether or not there is any data for that particular plot. So for instance, in the fp example above, once I "accidentally" added Plot 4 by dragging the bottom edge of the legend there is no way to remove it. It will continue to be visible to users by scrolling down to it even though I never used it and don't need it. I did find a 4 year old post on the darkside that explains the same problem I'm having. That specific solution doesn't work in my case but I'm trying to adapt it.

Nope, that was my first guess too. It's really a resize function and changes the height of the legend to show n plots. It doesn't actually remove any plots from the legend. (Though it will add them if you set n to be more than the number of currently available plots.)

In one of my apps I have a pop up window users can use to easily see temperature changes over time. There are roughly 30 different temperatures they would like to track, so I'm using the waveform graph legend's built-in 'vertical scrollbar' and 'plot visibility checkbox' features. The problem I've run into is that while plots are automatically added to the waveform when users increase the size of the legend, there does not appear to be any way to remove plots from the waveform/legend. I've dug through the waveform graph's properties dialog box, properties nodes, and invoke nodes and for the life of me I cannot find any way to remove a plot from the legend. Anyone have ideas?

Last year I posted an exchange I had with my teenage nephew, B, regarding the concept of "fairness." He spent the night with us last night and somehow the topic of paradoxes came up. He claimed the sentence, "This sentence is false" is a paradox. I replied that isn't necessarily true. Naturally, he disagreed and wanted me to tell him how it can not be a paradox. I declined and instead challenged him to a wager of his choosing. He agreed to be my "indentured servant" if I could show how that sentence is not a paradox. He of course threw in as many lawyerly clauses as he could think of. I had to use the exact same words in the exact same order with no additional words in the sentence. The kitchen was kind of messy, so I agreed. Then I said, "This sentence is false?" and explained because the sentence is not asserting a truth value it is no longer a paradox. To his credit, he didn't argue the point and agreed it was not a paradox. Turns out he deftly left himself a backdoor with the 13th amendment which, in his words, "prohibits indentured servatude." (I believe it only prohibits involuntary indentured servatude, but I let that pass.) In response I invoked the universal invariant "might is right" and gave him a noogie instead. I really have to say I enjoy watching teenagers develop their thinking and reasoning skills.

Fair enough. It's easy to forget that much of the literature about low level computer behavior is based on unspoken assumptions about what development environments and programming paradigms are used. I certainly don't understand the details of OS memory management, compiler technology, or under-the-hood Labview implementations well enough to speak with any kind of authority and I appreciate the explanation.

Congratulations Jon! I see you took advantage of the hospital's "buy one get one free" sale. I'll buy you a beer at NI Week. I've never heard of the name "Digby." Is it unique to Australia, a nickname, or did you make it up? ----- @Mikial - I have no idea why--maybe it's some combination of the colors and cropping--but when I saw your new profile pic the very first thing that popped into my head was, "he's sitting in a bathtub." That's a mental picture I could happily live without thankyouverymuch.

Umm... to be honest I'd rather not. You seem to be genuinely interested in the benefits of LVOOP as I perceive them, so I'll set aside my reluctance and take another stab at explaining my thinking. However, the answer is not simple and it will take me several days to compose a reply. (I've already written 1500 words and I've only gotten through the background information.) In the end anything I write will, in my opinion, inadequately encompass the entirety of the reason I prefer the OO implementation. I'll create a new thread and post a link here.

I have absolutely no problem with it being your preferred solution, and I'm not disputing the possibility that it can be written faster and execute quicker than an equavalent OOP implementation. I'm not even claiming a FG is an inappropriate solution. I'm specifically challenging the notion that it is "the preferred" or "more correct" implementation. There are lots of things about them that make them less desireable to people than alternatives. I haven't used a FG in years primarily because of the dependency tree effect and lack of extensibility I mentioned. Both of those things are vitally important to keeping code sustainable. Preserving sustainability is easily worth the extra 3 minutes to write a LVOOP solution and a couple microseconds of execution time in my applications.

Well, it was really useful for me 7 months ago. Beyond that it hasn't been particular useful... yet. I agree, but you're focusing on how they are implemented and used in other languages, not on the conceptual idea they represent. The whole idea of blocking while waiting for a Future to be filled implies manipulating data in space. In other words, data in this thread needs to be given to that thread. We already have lots of ways of moving data in space: queues, notifiers, network streams, etc. We don't need more of them. Conceptually the purpose of Futures is to manipulate data in time. I can grab a piece of data and do things with it. I can copy it. I can send it somewhere else. I can even "perform calculations" on it--using decorators--if I want to. I can do all of this before I know what the value of the data is, or even before the value has been assigned. The idea's applicability isn't restricted to asynchronous applications. It can be used any time you know what you want to do with the data before you know what the data actually is, even in single threaded applications. Manipulating data in space and manipulating data in time are separate (but not completely independent) issues. In my example I'm combining Futures with messaging to manipulate data in both time and space. The simplest way to implement what I needed was by using a by-ref data object, but it's not the only way to implement them, nor is it a requirement for something to be a Future. The implementation details depend on how you need to manipulate the data through space and time. For me, learning about Futures opened me up to thinking about problems in a different way. That's why I said the real value is in the concept as opposed to any specific way the concept is used. This is where the potential problem lies. It's API is too simple and loses robustness. I assume Redeem Future Tokens.vi blocks execution waiting until the Future is filled. What happens if a Future is never filled? Maybe an actor has an error and shuts down after the message is sent but before it has a chance to fill the Future. How do you tell the async subvi to quit waiting so your application has a chance to recover? Granted the example is simple enough the correct behavior can be verified visually, but in a larger application that won't necessarily be true. Off the top of my head I can think of two options if you don't want to poll the Future: 1. Use a "fail and notify" system like I mentioned earlier. The async subvi waits for a finite amount of time for the data, and if the data isn't ready it automatically fails and alerts the Requestor of the failure. 2. Promote the async subvi to an actor by implementing a message handler. Add an "Exit" message so it can accept an external shutdown message. Implement code tracking the progress of the Futures through the application so someone can figure out whether or not they need to send an Exit message to the helper actor. Both options require adding more overhead code to manage the process. I think overall Option 1 requires roughly the same amount of code as having the Requestor receive by-value reponses from the actors, while at the same time obscuring the code's intent and execution flow a bit more. Option 2 seems to require a lot more code for little benefit. I'd have to have really good reason for choosing that option.

Doh! That's a Preview Queue function in the False case, not a Dequeue function. My mistake. (I didn't realize that until I was coding up a more detailed explanation of why you were wrong. ) In any case, the strategy probably will work but imo it obfuscates the code's intent. In addition to the confusion over what the code is doing (preview vs dequeue), once that is figured out the natural follow up question is why is a copy of the reference being put back on the queue? You can insert comments to explain all that, but there are simpler implementations that are much easier to understand. Your original code snippet much more clearly implements a singleton. This solution strikes me as cleverness trumping clarity. More cookie poking? I agree a FG is one way to prevent race conditions. I disagree it is "the preferred" or "more correct" implementation. Semaphores exist for the purpose of preventing code blocks from executing simultaneously. Using one explictly acknowledges the possibility of race condition and prevents it from occurring. There is a lot of value in using software constructs for their intended purpose. Future developers will look at the code, see the semaphore, and instantly think "race condition prevention." The ability to protect code blocks using a FG is (imo) a side effect of a setting a vi to be non-reentrant, but it isn't the primary purpose of a FG--else it would be called a Functional Semaphore. Besides, FG's have other nasty habits, like playing havoc on your dependency tree and not extending as cleanly as other implementations.

I don't think this code will work the way you expect. As written, if you have four active modules then the first module that shuts down empties the queue and releases the .Net reference. In the cleanup code you're dequeuing the (one) element and immediately checking the queue status. It's going to return a count of zero. That doesn't fix the problem; you're just substituting one test for another test. The race conditions have nothing to do with the quality or specificity of the test being done. There is still a time delay between when Module A conducts the test and when it takes action based on the result of the test. During that time delay Module B can perform an action that makes the results of Module A's test incorrect, but A is already committed to a response so you'll end up with a bug. Look back at the race conditions in the snippets here. Those are the best example I have right now that illustrate how parallel code executing between the test and the response invalidates the test results. You need to protect the test & response code block and make sure no parallel code can invalidate the test result before the response code executes. Then look at how the semaphores in this snippet only allow one complete test & create/destroy code block at a time.

I guess the two of us together almost makes one knowledable developer...

Russinovich's articles are always good. I wish I had 6 months to just sit down and read his stuff. Of interest was this comment, "Any process that has more than a ten thousand handles open at any given point in time is likely either poorly designed or has a handle leak..." So I checked...

I knew you could do that to change projects, but I didn't know that also applied to different targets in the same project.

I can find it in vi.lib, but it's gone from the palettes in 2011, as is the Application Directory constant. Has the functionality been replaced by something else? [Edit] Well, kick me in the teeth and call me Charlie. It was an ID: 10t error. LV thought the vi was on the RT target and Get System Directory isn't supported on RT, so it wasn't showing up in the palette. A quick LV restart and all is good. (I hope some day I'll wrap my head around all the twists and turns that make up RT programming with LV.)

Ahh, I see. Good question, I'll have to try that if I encounter the problem with a live system handy.

You don't happen to have a screenshot do you? I don't recall perfmon having a "memory handle count." Maybe I'm using a different version... Anyhoo, 7 M "memory handles" over 6.5 hours is roughly 300 memory handles per second. I assume you don't have any loops going at 300 Hz or some fundamental frequency of 300 Hz?

Can't say, as I already repaired the broken code and am not too inclined to rebreak it to check. Doubtful. The variables in question are to give users direct control over digital output lines. Since the UI code is broken due to the error, the UI can't run and the values aren't updated.

There is in the sample code you posted because you're creating the .Net reference before obtaining the queue. It's easily fixed by creating the .Net reference in a case statement after obtaining the queue if the queue was newly created, along with the code to enqueue the refnum the first time. The returned .Net object is a singleton? If you don't mind...