Aristos Queue

QUOTE(ibbuntu @ Jan 17 2008, 05:26 AM) Noooooo! It wasn't the dynamic *inputs* that was the problem. It was the dynamic *outputs*. By making the input not be generic, you're going to lose your ability to override the method for specific network controller classes! Please post the original block diagram that had the error -- I think (from your fixed diagram) I know what the issue was, but I'd like to make sure.

QUOTE(Tomi Maila @ Jan 16 2008, 08:54 AM) Yep. Rule 1: Get it working before you optimize it. Just getting recursion into LV has been a Hurculean effort of many years, bordering on a decade. I found a hole in the barrier that allowed me to get it working for dynamic dispatch VIs, so I exploited that in order to provide a highly requested feature. Anything beyond that was not in my mind. QUOTE Will you support in the (near) future LabVIEW versions? I don't know. The compiler optimization teams (plural) are doing all sorts of upgrades over the next few releases. Whether or not recursion gets any attention from them depends largely upon how much usage of it we see in the field. See, recursion is a highly requested feature, but usually in the "my goodness, you can't even do recursion, what kind of language are you?" sense, and only very rarely in the "I have a real-world need for recursion; could you please add it?" sense. This is one of those cases where the biggest bang-for-buck comes from just having the feature at all, not from having it work well. We may very well have all sorts of optimizations in the pipeline that I don't know about... My slipping recursion into 8.5 was something of a surprise to everyone -- the rest of LV VIs are still a ways away from it, and so optimizations for recursion hadn't really been discussed here-to-fore. It may be that tail recursion is planned to go along with the rest of LV VIs becoming recursion-capable. To take a line from the finance industry: "Past performance is not indicative of future optimizations." :-) QUOTE(Tomi Maila @ Jan 16 2008, 08:54 AM) Will you support in the (near) future LabVIEW versions? I asked Optimizations and got this tidbit back: There are a lot of optimizations for the general case that would be tackled before special gencode for tail recursion. The big ones being further size reductions for reentrant dataspaces and the ability to create stack based dataspaces. Additionally I would say that indirect tail recursion is much harder to detect than direct tail recursion and most direct tail recursion can be fairly easily expressed as a non-recursive loop. So there's your answer.

QUOTE(Justin Goeres @ Jan 16 2008, 03:10 PM) And beleive me when I say: The rest of us want you to get help now, too.

QUOTE(Yen @ Jan 16 2008, 12:12 PM) You're welcome. I paid dearly for that mnemonic, btw. On French keyboards, the short cut is ctrl-*. When I implemented ctrl+#, we discovered that this equates to the altGR key on French keyboards, which meant any time someone tried to type an extended character (say, the Euro symbol for example) they would instead toggle the alignment grid. That took forever to track down, because the only thing the testers could see was their text not appearing, not the toggling of the grid. ;-)

QUOTE(ibbuntu @ Jan 16 2008, 09:05 AM) That error is just a wiring error. Your VI has a dynamic dispatch output terminal. All the wire paths that lead to a dynamic dispatch output must originate from the dynamic dispatch input, passing through various nodes along the way, but never just swapping out for a new object. You have two options: 1) Make the output be just a regular output instead of a dynamic dispatch output. This will lose you one of the nicer functionalities of automatic downcasting, but it does allow you to wire arbitrary sources to the output terminal. 2) Follow the wire coming out of the dynamic dispatch input. You can easily follow it because it has a gray background. If the background disappears or turns red between the input terminal and the output terminal, that's the point that you have a problem. If you post a picture of your block diagram, it'll probably be trivial to identify.

> My concern is that in the dequeue-append-enqueue process, the > Dequeue node has a buffer allocation on the output, I assume > making a copy of what's in the queue. Once again: The "Show Buffer Allocations" do not show copies. They show buffer allocations. That dot on Dequeue indicates a place where a location is allocated to store data. Think of these as buckets. Data enqueued into a queue and dequeued from the queue elsewhere is not copied. It is moved from the bucket of the wire into the bucket in the queue and then moved from the bucket in the queue to the bucket on the new wire. The data is not copied; it is moved. When I say moved, I mean the top level data gets moved. For a double, that's an 8 byte value. For an array, that's a pointer, not the entire array. For a LVClass, it is also a pointer. For a cluster, it is the sum of top level data sizes of the clustered elements.

Take a look at this: http://dontclick.it/ There are some interesting aspects to this UI. Thoughts?

QUOTE(Gavin Burnell @ Jan 8 2008, 06:10 PM) What is the word for "the opposite of interoperable"? I can't think of it right now. But whatever that word is, it applies to XNodes and LVClasses. They don't work well together. They don't play well together. Hell, they won't even go out to a bar and complain about the weather together. What they will do together is pace off 10, turn and shoot each other in the head, generally killing any LabVIEW.exe process that happens to be in the vicinity. Never forget -- XNodes have never been released. They don't officially exist. Specific XNodes have been designed, tested and certified to work in specific situations. The general technology is unstable for a host of reasons. And LabVIEW classes push all of the boundaries of those instabilities. It's being addressed, but given that XNodes are a pure NI-internal feature, it really isn't a priority (from a business standpoint) at all to make the two features work together. Caveat empor.

QUOTE(crelf @ Jan 7 2008, 07:12 AM) But don't bother actually contacting NI. You won't be able to get such a license. It isn't for sale.

QUOTE(robijn @ Jan 7 2008, 04:38 AM) You can't. The pointer type is allocatable but not assignable. The challenge of building a recursive datatype that is dataflow safe is an open challenge.QUOTE(Tomi Maila @ Jan 6 2008, 01:43 PM) a1 : A(Nothing);a2 : A(a1);a3 : A(a2); To my eye, this results in the same behavior as LV already has -- allocatable but not assignable. You still can't build the double-linked list / graph with this setup. The only structure that holds for that is the indexed array setup, a structure that stores a set of nodes and a set of edges. Care to contradict?

QUOTE(Falevoz Y. @ Jan 2 2008, 09:14 AM) There is no programming language in existence that allows this. None. What you're asking for would be, in C++, this: class X { ____X blah; } Not legal. What is legal is: class X { ____X *blah; // Very important asterisk! } i.e., a pointer to the type. Defining the data within the data would be a type of infinitely large size. The second one is possible in LabVIEW. Please look in the LAVA forums for the topic about the Map class.

QUOTE(tcplomp @ Dec 29 2007, 12:53 PM) The demo is A->A. But LV8.5 can do both. All the VIs involved in the recursion must be capable of recursion (meaning dynamic dispatch with shared reentrancy).

Convert it to a .jpg or .png and then use Edit>>Import Picture to Clipboard. Then use Edit>>Paste to put it on the front panel.

I read the post, and I think I'm missing something... are there any differences between the top chunk of diagram and the bottom chunk of diagram other than the branched wire on String 3? Is "String (typedef)" a different typedef than "String (typedef) 2" ?

QUOTE(Kevin P @ Dec 21 2007, 09:49 AM) Accessing a column of a 2D array would still be inplace. The subarray stores a start position, an end position and a stride. In a row, the start would be beginning of row, end of row and stride =1. In a column, it would be start of column, end of column and stride = lenght of row.QUOTE(Kevin P @ Dec 21 2007, 09:49 AM) Finally, a side-rant:One thing that contributes to my suspicion of NI's commitment to good, efficient code is that many of the shipped examples and vi.lib files, even many of the toolkits, have some pretty ugly block diagrams. I know that ugly doesn't *necessarily* equate to inefficient, but it demonstrates a lack of attention to detail which raises more doubts. As one of the C++ programmers, I might suggest that the C++ code is good enough that our G programmers generally don't have to worry about it. The quality of G code doesn't correlate at all to how well the compiler of the G code works. In actuality, I know the G programmers do pay a lot of attention to code quality and by and large the shipping code is very clean. Yes, you can find specific problem VIs here and there, but I don't give a lot of creedence to the position that there's "a lot" of ugly G that ships with LV. I don't know about the toolkits, as I've rarely delved into them, but the same programmers write most of those, so I'd be surprised if many ugly VIs exist there.

You may be able to use the Stop VI primitive, depending upon how you started the VI. If the VI you want to stop was invoked by a subVI call or using the Call By Reference node, then stopping the subVI is the same as stopping the caller VI, which would stop your whole program. But if the VI you want to stop was invoked by using the Run method of the VI Server reference, then that VI is a separate executing VI and you can just stop it. The use of the notifiers/queues/etc mentioned by the other post is useful if you need to know in your original caller that the stop has occurred. But if you don't need such messaging, the Stop VI may be easiest.

QUOTE(Val Brown @ Dec 19 2007, 05:05 PM) That's my standard advice for any unreleased, undocumented, unsupported aspect of LabVIEW. But people have been very successful using these things anyway. It's a lot like getting medical certification for a LabVIEW program. NI doesn't have LV itself certified for use in medical equipment, and we don't (to the best of my knowledge) help a customer get that certification for their VI hierarchy. But some customers have gotten a particular hierarchy certified. If you can make it work, then use it. But it isn't officially supported, and your AEs won't generally even know about it, and they won't find any documentation about it in their database -- it's something only an R&D programmer or a hacker user would be able to help you with.READ THIS POST FOR MORE DETAILS: http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html

QUOTE(Aitor Solar @ Dec 19 2007, 03:58 AM) And, in fact, without the OpenG tools, you cannot add it to the palettes. This is a rusty nail of LabVIEW and was definitely never intended to be exposed to end users. But end users find it useful and worm their way into all LV's nooks and crannies. I've had to start hiding easter eggs at the extreme edges of things just to keep them from being found quickly...

QUOTE(Justin Goeres @ Dec 18 2007, 01:39 PM) I never pin palettes, so drop vs insert weigh equally for me. But that's my personal take. The stuff I posted earlier is LV's general findings from users.

Use AppBuilder to build a source distribution.

QUOTE(hooovahh @ Dec 17 2007, 03:09 PM) The expected solution is that you would just have Release Semaphore also be outside of your error case structure so that any time Acquire Semaphore executes, Release Semaphore is also guaranteed to execute.

I was inspired. If you haven't yet played Portal, I STRONGLY recommend it as the greatest video game *ever*. The freely available "Narbacular Drop" will give you some taste of the game, but only the tiniest taste. The college design team that did Narbacular was hired to do the professional version Portal. They have achieved the status of "living legends" in the game industry.

QUOTE(Val Brown @ Dec 15 2007, 05:00 AM) No reason not to use it that I can think of. It's a fine approach. In LV8.5, I would strongly recommend that the VI as written be marked as "Reentrant -- share instances". That recommendation will be even stronger in future LV versions as the clone pool managment improves. Basically, there's no reason for this subVI to cause friction between VIs, and yet you don't want the memory overhead of each subVI call having its own instance. The shared clones is a spectacular compromise position for VIs like this one.

QUOTE(Justin Goeres @ Dec 14 2007, 08:09 PM) The trick still works... you just have to use a boolean control instead of a boolean constant. But the *far* better way is to use a static VI reference (found in the Application Control palette).

QUOTE Try popping up on a wire and selecting "Insert" in LabVIEW. Does exactly what you're looking for. QUOTE(tnt @ Dec 14 2007, 02:20 PM) what I would also like is to have the option to use the right mouse -> invert boolean in-/outputdynamically on EVERY boolean in-/output of the connectorpane.In this way you practically never need to use the invert vi... We implemented this once in a test version not too many years ago. Push back from many testers, enough that we abandoned the idea, was that the inversion dot is too easily overlooked when reading diagrams and they preferred the visibility of the Not function. If the negate was easily available to VI authors it would create a challenge for VI readers and just add one more item to the list of "practices to be avoided" list Feedback from that test was a major reason why Insert popup menu item was improved to have a shortcut to the datatype palette instead of always going only to the top-level palette.QUOTE(eaolson @ Dec 14 2007, 10:36 AM) Something like this: The compound input to the loop terminal has also been talked about, but it always ends up in the same discussion as wiring the error cluster directly to the compound input. Allowing that raises the hackles of those who favor the existing strong type system of LabVIEW. That idea gets brought up and killed once every couple years. The compound input was debated recently when the For Loop got its upgrade to have an early exit terminal. The ease of getting to the compound boolean function (by popping up on the stop terminal and dropping from the shortcut palette there) was felt to be sufficient. There's a lot of worry about loading up the complexity of the loop structures that are so commonly used by new LV programmers. The For Loop's break is a mode you turn on. We could add a compound mode to the stop terminal, but a that point you've gone through just about the same number of mouse clicks as needed to drop the compound boolean function anyway.