Aristos Queue

QUOTE(Tomi Maila @ Dec 6 2007, 03:27 PM) Ah, wayward traveler! A word I would whisper in thy ear! Know ye the toolkit known as Block Builder? 'Tis a tool of the devil, the one they call "Express." But in yon toolkit ye shall find the secret that you seek -- the magic of hiding one VI within the confines of another. I canna say how such transsubstantiation is accomplished, for I have ne're learned the trick. But a black magician such as yourself should have no trouble ferreting out the diamond in the rough.

QUOTE(MikaelH @ Dec 6 2007, 02:53 PM) I'm still posting regularly to LAVA, so we can't possibly be that late in the release cycle. ;-)

Whoa. This is NOT a known issue. Please report as a bug (ni.com). Essentially, you have written a block diagram for which LabVIEW has no idea how to generate assembly code. Attach as many VIs as you can to the bug report. I noticed that you blocked out the name of your class in the error dialog... if you've got proprietary IP, there is a way to sign NDAs between you and NI if necessary. Mention it in the bug report if that is an issue.

QUOTE(Tomi Maila @ Dec 5 2007, 02:29 AM) I want those 18 months of my life back. You've never lived as a developer until you come into the office on a Monday morning, nine weeks before release, to find a bug report: "File >> Save As" deletes my file from disk filed by the poor sucker who tried to make a backup copy... And all because someone somewhere made "just a small change" to the linker.

QUOTE(Tomi Maila @ Dec 4 2007, 10:05 AM) :!: For the love of LabVIEW -- LEAVE THAT FUNCTION ALONE. :!: Nothing -- and I cannot stress this enough -- NOTHING that you write that uses any of the G linker functions can be considered usable in association with any given set of VIs unless it has been certified by a LV linker expert and tested directly by LV team in the Thousand Monkeys Test Suite for provider robustness. Your *probability* of destabilizing LabVIEW by creating new linker relationships and attempting to manage those relationships is as close to certain as you can get. I don't know why you're getting an error. I can only say I'm grateful that you got an error because it prompted you to ask this question. I'm sure you're trying to do something wonderful and magical with the XNode. Do it using an existing relationship. Have your XNode script a strict static VI Reference to the target subVI-- that'll get you a type prop call any time the other VI changes its conpane. Do something creative. But efforts to use the linker functions are pretty much doomed to failure unless you've got way more linker expertise looking over your shoulder than you do. The worst part is that you might even get it working in the 90% case. That 10% case will never be clearly understood and will simply result in bizzare LV behavior that you may never relate back to having one of these XNodes lingering around on some block diagram somewhere.

I understand the subVI inherits the execution system from its calling VI. Now does it inherit the calling VI's exec system if it's called dynamically, i.e. either by Call by Reference or by Invoke Node? When called using Call By Reference, yes, it has the same as its caller. The CBR node treats the new VI as a subVI. When you start a VI running using the Invoke Node "run" method, no, the execution system is not same as caller because there is no caller. The Run method is the same as running a VI top-level (as if you hit the run arrow on it). Is there any way how to determine the running VI's actual execution system? Don't know and never needed to know. Mark VIs that need to be "user interface" to be "user interface" and let all other VIs follow the lead of their caller. > which moreover seems to me a bit outdated. How so? It's the same threading model used by the OS, and it translates directly to modern FPGAs. What aspect are you seeing that feels stale?

QUOTE(Tomi Maila @ Nov 30 2007, 06:42 PM) There are only two built-in events that can be programmatically triggered. One is the "Value (signaling)" event. The other is App Exit. Anything else that you do programmatically does not trigger the event structure. You'd have to write your own user events for anything else that you want to be reported to the event structure.

QUOTE(Aitor Solar @ Nov 15 2007, 02:24 AM) Send me a private post or something. If you've got a way to do it, I want to know so I can see how the code is doing it SO I CAN BLOODY WELL MAKE IT A SUPPORTED FEATURE.

QUOTE(David Boyd @ Nov 30 2007, 04:10 PM) Looking at the code... the rationale appears to be that LV just copies the default value over the current value for all controls without checking if the current value is the default value. So a value changed event gets fired regardless. We could slow down the process by doing a comparison on each individual control of current versus default before doing the copy, but we don't bother. Would you want this behavior to change?

QUOTE(Justin Goeres @ Nov 29 2007, 04:58 PM) It looks to me like what may have happened with mario64's post is that he kept hitting Add Reply with the same text, and the forum software just appended all the replies together (and removed the linebreaks, which is a known problem). A flaky internet connection could cause that, if he wasn't getting confirmation back that each post went through. :laugh: Careful about wagging the finger, BrokenArrow. Looks like similar thing happened to you... The LAVA site burns all of us occassionally with this feature when we reply to our own posts.

QUOTE(Mike C @ Nov 27 2007, 08:22 AM) Other programs know the progress because they are the program doing the file transfer. They're the ones actively sitting on the port receiving packets, unzipping the headers and handling the packets accordingly. The LV Internet Toolkit VIs are doing this, but they are high level APIs (download this file) not low level APIs (wait for packet on port XYZ). You can write such VIs using the Internet toolkit and create your own implementation of the FTP protocol, which you would call to wait for one packet, update some display, then wait for the next packet. Wouldn't be trivial but it is possible.

QUOTE(Daklu @ Nov 21 2007, 01:59 PM) It took me a while to figure out what you meant here. LV does have an integrated development environment, a very complete integration. When I'm told "there's no IDE for this language", I think of a case where someone edits their code in a text editor and then goes to a command line to do a compile. What you're asking for is a MDI (Multiple Document Interface) for the IDE. That was attempted in LV8.0 and beta users killed it quickly. Very quickly. Since then we've had internal teams continuously researching different environment options. If you look at the LEGO Mindstorms NXT product, you'll see one MDI environment for LabVIEW. The LEGO environment didn't need front panels, which solved one of the major headaches of MDI. Major issues of window management include the context help, the palettes, probes and reentrant VI clones. None of the MDI environments attempted thus far has been as good as the current scenario of individual windows. The handling of VIs moving from a machine with monitor specs XYZ to another machine of monitor specs ABC is a separate issue, one that has also been addressed in the last couple of releases and is continuing to be worked on.

QUOTE(Mike C @ Nov 26 2007, 11:30 AM) I would doubt it unless you've got some way of monitoring the packet transfers directly on the FTP port.

QUOTE(Mike C @ Nov 26 2007, 11:30 AM) I would doubt it unless you've got some way of monitoring the packet transfers directly on the FTP port.

QUOTE(hviewlabs @ Nov 20 2007, 06:30 PM) That would be LV8.5. LV8.5.1 -- if we decide that 8.5 warrants a bug fix release -- has been jokingly called LV Hale-Bopp... because it is a small adjustment to Jupiter.

QUOTE(hviewlabs @ Nov 20 2007, 06:30 PM) That would be LV8.5. LV8.5.1 -- if we decide that 8.5 warrants a bug fix release -- has been jokingly called LV Hale-Bopp... because it is a small adjustment to Jupiter.

Hard to help debug if you don't post VIs that show the problem...

QUOTE(Jim Kring @ Feb 11 2006, 09:43 AM) Yeah, I know the poll was closed back in 2006, but it appeared today on the front page of LAVA, and I thought I'd mention something that may not have been thought of back in 2006, since at that point LV8.0 was fairly new. The LabVIEW project will handle items that have the .vi file extension a lot better than VIs with non-standard file extensions. If you actually load non-standard-extension VIs into memory, then the project will know they're VIs. But until you do that, it judges based solely on the file extension, and it may not be displayed with the right icons or get the right popup menu items.

QUOTE(Val Brown @ Nov 14 2007, 09:04 AM) I followed up on this. There are no plans to extend this feature beyond the small embedded-type platforms. The Call Library node exists for calling C code; that is considered to be both sufficient and more standard than an inline compilation of C code would be. Having support for the inline C would involve shipping a platform specific C compiler with every version of LabVIEW, and we don't have any interest in doing that. The embedded targets already have a C compiler built into them because that's how we get onto those specific targets, and the inline C node was originally conceived as inline assembler for efficient access to I/O registers on tiny platforms.

QUOTE(clynch @ Nov 14 2007, 09:32 PM) Any opinions the author has were pretty much discredited in my book by this statement: (Aside: as I was re-teaching myself how to program in C, I was reminded about the funny logic of computers. -100 is > than -90. Is this true in all languages?) What the...?! No, negative 100 is not greater than negative 90 in C.

This is a question that I would recommend cross-posting to forums.ni.com because the folks best able to comment on this issues are more likely to monitor that forum than this one. If you do cross-post to NI, make sure you post a link to that post here so that people interested can follow the conversation.

QUOTE(Michael_Aivaliotis @ Nov 12 2007, 10:42 PM) If I write text in a word processor, if that text is work for hire then my employer owns it unless we have a contract that states otherwise. There isn't a difference between a word processor and a development environment.QUOTE(jdunham @ Nov 12 2007, 11:38 PM) If a programmer (or her union) can negotiate a direct royalty or retention of the copyright, then bully for her. AQ pointed out that different industries have different norms on getting salaries, advances, royalties, etc. I suspect that NI has convinced its programmers that they are better off taking salary and stock options than royalties. There's nothing specific about NI in this discussion. This is the state of the programming industry. And it generally isn't "convinced" that applies -- most programmers just accept the state of the industry as "the way things work."

QUOTE(jdunham @ Nov 12 2007, 06:26 PM) Now this is something that has become *very* interesting to me lately. It's really bugging me on one recent project that I can't see whether *this* VI is reentrant or not unless I open up the VI Properties. It seems ridiculous to have the entire VI Properties dialog displayed as part of the block diagram itself, but there are some items (UI Thread, Reentrancy) that really should be displayed. Take "Allow Debugging" -- I can tell that based on whether or not the Execution Highlight button appears on the block diagram button bar or not. And the appearance settings ought to be *on* the FP.I'm also not liking that I can't look at an entire list of VIs in some view somewhere and see which ones have a password set and which ones don't.I am on record as opposing decorations in the project tree for these sorts of configuration properties of VIs. The reason I have opposed them is that the set of useful-to-know attributes is basically open ended, and there's only so much space for decorating icons in the project tree (it's 16x16, for goodness sake!). So I've pushed to have the only decorations be things relevant to the item's file status -- missing files, checked in/out of SCC, locked against edits, etc. I might conceed the appropriateness of an asterisk to indicate files with unsaved changes. But not reentrancy or dynamic dispatch or anything else that is an attribute of the file's content and not the file itself. Keeping the project tree focused on file aspects seems correct since the project is fundamentally about organizing files and file relationships.But somewhere there ought to be something for sets of VIs to show other types of attributes as a set. In a user friendly, easy to read manner. I don't have any solutions to suggest in this line of thinking. It's just something that has been bugging me lately.QUOTE(jdunham @ Nov 12 2007, 06:26 PM) I think the block diagram wire for that object has a funny gray 'sleeve' around it but it took me a while to notice that; it's very subtle. It's meant to be subtle. In fact, if there's no dynamic output, the gray sleeve won't even be there. It's meant to help you debug the situations where dynamic input does not propagate to dynamic output. (It disappears or turns red at places where the connecting path is broken or gets merged with other code paths). So that's not a good way of identifying dynamic or not. QUOTE And there is the dotted line around the terminal pane connections (which is very, very helfpul), but I still think there is room for more hinting about the nature of the VI. Maybe something is needed in the project view, or the help window. I still think it would make life easier for class authors (and code reviewers) to see this behavior at a glance rather than digging around for it. I also think some kind of display of reentrancy and recursion would be extremely helpful. The context help window does seem like a good place to display a lot more of this information. I'll take it under consideration. It isn't perfect, but better than nothing.

QUOTE(hooovahh @ Nov 12 2007, 01:47 PM) The writers are, today, equivalent to book authors. Authors are paid royalties based on how well their books sell. Yes, sometimes they get an up-front fee, but that's only for the top writers who are proven talents. The majority get paid in royalties if things go well. In television, you have much the same situation. It is more common to have a basic stipend, but the majority of their income comes from the royalties that get paid if the show reaches a large audience or sells well on DVD. As far as the writers are concerned, if you transmit the show over the Internet, that's no different than a broadcast over airwaves or cable or purchase on DVD. They should get royalties when that event occurs. But the studios don't currently pay anything because the current contract covers broadcast (defined as the studio showing the content at a particular time which viewers tune in for) and sales of physical media (tapes, DVDs). In the Internet transaction, there's no physical media. And users can download it at any point, so there's no broadcast. Thus, there's no royalty. And the studios argue that there shouldn't be any because they contend they don't make any money from the downloads. The studios argue that Internet downloads are loss leader items -- products that are deliberately sold at a loss so that you can attract people to the store. Milk is frequently sold at a loss at grocery stores because they know if you come in for a necessity that you can get cheap, while you're in the store you're likely to buy other stuff. The studios claim that the downloads are just publicity for people who will eventually go buy DVDs. That logic stinks to the writers (and to me) because what person is going to go buy the DVD after they've already downloaded the content, especially if they downloaded legitimate content that they even paid for ($1.99 on iTunes, for example).QUOTE(Michael_Aivaliotis @ Nov 12 2007, 02:07 PM) I wonder if the idea of a LabVIEW programmers union has some traction... My dad has more than once encouraged me and my friends (many of whom are programmers) to form a union. He was hearing a lot of us talk about ridiculously long work hours when a release hits crunch time and not getting any overtime pay because we're white collar. Dad recognizes that some types of work take an ambiguous amount of time and so a union contract that says "we only work this many hours" is ridiculous. But the Writers' Guild is a content generator just like programmers, and certain work rights can be seen as reasonable. Suppose I develop patentable work for NI. Under the terms of my employment, I get a fee when NI files for the patent and a second fee if the patent office approves the patent. And that's it. Is that reasonable? If the technology leads to a massive explosion of NI's income, should I get a share of that? We could have that debate all day. But as a union, a band of developers might demand more ownership of technology that leads to a patent. How about non-compete agreements that keep me from using my programming talents if I leave a company? NI's policy is very reasonable, but I interviewed with a company whose non-compete agreements basically prevented a programmer from programming *anything* for two years after leaving. That's ridiculous. When I was interviewing, it was the height of the dotcom boom, and that company just couldn't attract talent. Anti-union people would rely upon market forces to break such companies -- no one goes to work for them if they're too draconian. But come 2002 any job was a job, and frankly, you could hire a programmer at just about any terms above starvation. A union keeps such abuses from occurring when the economy turns against employees. Honestly, it isn't a bad idea at many companies. I'm actually surprised that a Game Developers Union has never come into existence, given the abuse that those guys suffer. But when I talk to them, they all see it as the price they pay to do something they really love doing, and most of them are just happy that someone is willing to pay them to do it. So the abuse continues. I remember reading, long ago, about problems at Pixar as the programmers interacted with animators. I don't remember how that all worked out -- it may be that programmers at Pixar, Disney, etc, may have a union, or be covered by one of the other Hollywood unions. But I don't recall.

QUOTE(Helmer @ Nov 12 2007, 12:28 PM) It seems like the real solution is to stop LV from crashing. I hope someone is reporting the circumstances for all these crashes so the root can be fixed.