Aristos Queue

That worked well!

So, I've been bothered lately by bit.ly links. These are URLs to http://bit.ly/... that are ubiquitous across the web. How many years have we preached to users, "Do NOT ever click on links that go to websites you do not trust? Avoid websites that redirect you to new servers?" Well, that's exactly what bit.ly does, and it relies upon the security blindness of most of the populace to be a viable system. The advantage of a bit.ly link is all in the market tracking -- it allows a website to hand out different bit.ly masks to different media outlets and then track which URL is the most used for getting back to the site. But how do I know that this funky bit.ly URL, with its garbled characters, is actually going to the reputable URL that it claims to be going to? I can't. So, frustrated, I have avoided clicking on many links. But I've found a workaround. You can do this... tl;dr: Take the bit.ly URL and add a + to the end of it. This brings up the statistics page for that bit.ly link AND it displays the real URL that the link goes to. Then you can copy/paste that real link into your browser or, if you don't mind the tracking, you can go remove the + and let bit.ly do the redirect for you. Annoying, but at least straightforward.

Many people really consider religion for the first time only after they start a family. It can be totally life changing -- a parent starts realizing that promises he has made are going to impact his children, and his interface is no longer his own. It therefore does not surprise me when a parent seeks to be saved in the wake of the creation of the first child. But seriously... No, I haven't seen this behavior in 2012, nor do I find CARs about it. There were CARs about it in 2010 and earlier, but those are fixed (at least theoretically... your empirical evidence suggests otherwise). So if you have a reproducible case and can share your code, please do file the bug report over on ni.com.

Correct. Bundling it into a cluster removes the ability to prove that the class type remains the same, which is the contract you establish when you declare a dynamic dispatch output terminal. If you have a dynamic dispatch input terminal and no dynamic dispatch output terminal, then you don't have to maintain the invariant.

What drjdpowell said.

Wiring from your dynamic dispatch input through to your output would also make it go away. With a dynamic dispatch input, when you wire out of it, you'll see that the background of the wire is gray. You can wire through any number of functions and even structures along the way as long as the gray eventually reaches the dynamic dispatch output.

What I meant by that is this: A VI stores the paths to its subVIs (or to its library or any other dependency). When the VI loads into memory, it loads its dependencies if those dependencies are not already in memory. If they are in memory, we check to see if they were loaded from the same path. If they were NOT loaded from the same path, we update the copy of the VI in memory to point to the location of the dependency in memory and give you the load warning. But although the VI in memory has been modified at that point, we do not check it out from source code control (the way we would if you had started editing it) nor do we mark it as having unsaved changes. If you proactively save the VI or start making other edits and then save it, then the VI will be saved with the new path. Given all of that, if the reason we had posted the warning dialog was because we were *fixing* the paths back to what you expect, that fix would not be saved to disk unless you did something to cause the VI to be saved.

Hooovahh: Part of why that method is still private is that I objected to calling it "Owning Project" since there isn't an owner relationship. "Loading Project" would be better name. I would rename the VI that Darren just uploaded.

Please bear with me... I'm going to ask some questions to try to understand what's going on a bit more. This is an area of LabVIEW that has a pretty long established pattern of behavior that generally makes sense to users. If it sounds like I am looking for you the user to be at fault instead of looking for LabVIEW -- and by extension, us, its developers -- it is because the subsystem that you are having issues with is one that has a pretty long history of working. (Note: I am talking about the choice LV makes about which path to save, NOT the control LV gives you for fixing those paths... lots of us will acknowledge that fixing issues like this could use some improvement.) If it turns out that LV does have a bug, we'll definitely acknowledge it, but I'm not expecting that. I write this preamble because sometimes customers have been upset with me when I go looking for problems in their behavior and/or expectations rather than just immediately accepting that LV must be at fault. Your seven steps, restated, with questions along the way: Save all three files onto the C: drive: X.lvlib X.lvlib:A.vi X.lvlib:B.vi [*]Commit all three files to SVN. Can you check your SVN history and verify that 1. All three files were really checked into the SVN at that time and 2. That X.lvlib contained relative paths at that time. This will help to confirm that we start this story from a known point. My first thought is that you, at this point, had both C: and R: versions and maybe, just maybe, you already had cross-linking at this point, where a VI on the C: drive was linked against a library on the R: drive or vice-versa. [*]Delete the working copy from C: drive and check out on network drive R: So you had mapped the SVN repository in two places originally... that's what made me think there might be a problem at step 2. [*]Open project 1 and work without issues. A library file does not load all of its VIs into memory. If you had cross-linking within X.lvlib already at this point, there might not be any dialog depending upon the exact VIs your project caused to load into memory. [*]Open project 2 and get the warning dialog So we know that something was *already* saved pointing at the wrong location such that when we loaded project 2, it gave you the warning dialog that it was redirecting to the R: copy. [*]Save and commit project 2 Are you committing just the .lvproj file or are you committing all the changes made while editing project 2? Did you actually commit all the files that triggered the dialog warning? I'm still assuming that you were *already* cross-linked back in step 2. My theory is that the dialog was a warning that LV was *correcting* the paths, but us autocorrecting the paths does not check a VI out from the repository. You would have to choose to check it out and then check it in fixed up. I doubt that you did this. [*]Update project 2 on another machine If you go back to step 2 and open on another machine, my current theory is that you would have had trouble back then. My theory may not hold water -- it's easy to check by looking at the SVN history. But it is the thing that feels the most right. That's *especially* true in light of step #6, where the dialog came up saying that files were found at a new path. Since the only path they could be found at is the local R: path, that means they were already wrong by that point. Can you check this and see what you find?

There's no such thing as a reentrant class, so that can't have been the error message. Tell me what the error message actually was and I might be able to explain. Or, better, post a picture of the broken block diagram.

You want to copy the VI into the directory but not have the user see the VI when they list the directory contents? You can set the hidden bit on the file in the operating system, although hiding a file from a user on their own system is a temporary thing ... they can always unhide the files and see what you've hidden.

All references have the same lifetime as the top-level VI that created them. Each actor is a separate top-level VI. You can have the reference inside the FIle IO class as long as the File IO object is initialzied inside the Actor Core.vi or Prelaunch Init.vi. That will give the lifetime of the reference the same lifetime as the launched actor. There's nothing special about semaphores in all of this.

A library *owns* a VI. A VI *is owned* by a library. The two have an indelible link. A VI may be owned by one and only one library. A project merely uses a VI or library. The same VI or library may appear in many projects. A VI is only part of a project when the project is in memory. Any other time, there is no "owning" project.

Another improvement sometimes used is to make your variable a tri-state: unwritten, initialized and failed. If you get downstream and the value is still "unwritten", then you use JamesMc86's solution of looping until it gets set one way or the other.

Flintstone: This does not sound like there is any bug to fix. Your description sounds like you resaved your files such that the two files were on different drives, so LV saved the absolute path between them when you asked it to save. That's correct behavior, not a bug in any way. > Is it possible that other VIs inside an lvlib get affected LV changes a path from relative to absolute? This question is missing some key words for me to be sure I'm parsing it correctly, but I believe the answer is "of course". If any source file is in memory and other source files reference it, when those other source files save, they will save with the path to that referenced file. If you loaded it from another machine, all the referencing files will be updated and will have new paths when saved. This appears to be a case of LabVIEW doing exactly what you asked it to do. What bug are you expecting National Instruments to fix?

A) Private messages that the actor sends only to itself can be done by putting the message class in the same library as the actor and making the message class itself be private scope. B) Protected messages that the actor or its children can send can be done by making the private message as per (A) and then adding a protected method to the actor class that sends the message. C) This is a good question to archive as part of the Actor Framework overall. Would you mind reposting it at http://ni.com/actorframework so I can answer it again there? I don't think it has been asked before.

How about giving the class a method called "Get Editor GUI" that returns a VI refnum, and if it returns Not A Refnum then it has no special GUI and if it returns a refnum then you run that GUI? In other words, instead of overriding the editor VI directly, override the accessor VI for that GUI.

To go a bit further... it wouldn't make any sense for children to have their own copy of the method... objects of a child class *are* objects of the parent class. This is the nature of the "is a" relationship we call inheritance. If you have defined a non-reentrant VI with state, you've said that all objects of the parent class should share that single state. The child class objects do not break that invariant, just as they try to not break any invariant defined by the parent class. If on the other hand you have defined a method as reentrant, then you've said that every individual call gets an independent dataspace for the VI. Because of this, the child, when it overrides a method, must match the reentrancy or non-reentrancy of the parent class in order to match that invariant.

Correct.

There's a reason I try never to promise future functionality. The fix is being backed out of 2013 and will be reattempted for 2014. No promises.

So, I am here in France for the Euro CLA Summit. Took a side trip out to The Palace at Versailles today. I saw a sign that made me smile. In bold letters: "RESPECT THE QUEUE!" :-)

The CAR will be fixed in LabVIEW 2013.

All of which means there is not already a way to implement the "Write" method as defined by for(imstuck) and Jack. And we're back to the original question. And I do not think they're violating SRP. Each of their classes is doing only one thing. They're just looking for a way for the parent class to specify "you have to do *something*". It's defining that "something" that is elusive in this conversation.