Aristos Queue

QUOTE(jdunham @ Nov 11 2007, 08:56 AM) I meant pick one within any single VI, not necessarily across all VIs. Again, the readability issue when both styles are used on a single block diagram is one that has been mentioned to me by more than one user.

QUOTE(JFM @ Nov 10 2007, 06:25 AM) This message has existed since LV2.0. Docs about it can be found if you search around on ni.com. I think LAVA has something about it somewhere, too, but I know the ni.com stuff exists.

QUOTE(Tomi Maila @ Nov 9 2007, 04:21 PM) Nope. At the end of the day I'm still a C++ programmer, and G is just a hobby. :-) It was enough for me to prove that LV Classes could solve this use case. Now, as someone who has actually crawled through the Variant code extensively -- I don't know what happens for small trees, but I'm going to bet that the LVClass solution blows the other away as the number of key-value pairs increases (probably noticable around 2000 pairs). I won't go into why, but that's my bet.

QUOTE(eaolson @ Nov 10 2007, 09:48 AM) See my reply http://forums.lavag.org/index.php?showtopic=9504&view=findpost&p=38375' target="_blank">here for general commentary on what is appropriate to put in a VI's icon and what isn't, IMHO. The criterion I discuss there is ambiguous in the case of VI reentrancy. I don't have a clear opinion on that one.

I do like the suggestion about wire colors for the abstract ancestors. That's useful. But may I suggest a tweak... there are multiple hierarchies that might be used together on the same diagram, and having them all be gray takes us right back to the "all clusters look alike" problem. Perhaps we could say pastel colors should be used for abstract ancestors and dark colors for concrete classes. That way you can have a red hierarchy, a blue hierarchy, etc. I've discussed elsewhere several times why dynamic dispatch subVIs aren't called out on the diagram by some glyph, or halo, or something. Search those posts out. Summary: When reading the caller diagram, I really don't care about the underlying implementation of the subVI. Whether it is a static dispatch subVI or a dynamic dispatch subVI is irrelevant -- the icon should tell me what the call does, not how it does it. Similar commentary applies to recursion. Why don't we change the name of functions that call DLLs? Is it important that the caller knows that the subVI uses an external library? No. These are implementation details. If a LabVOOP user develops a brand new set of data types for a LV toolkit and gives them to the LabVIEW user to use, the LV user shouldn't have to understand or be distracted by concepts of dynamic dispatch that have no impact on his/her use of the toolkit. Same goes for recursion. Or DLL calls. (A counter example: When a subVI is an implementation of a LV2-style global, that *is* something that should be noted on the icon. It impacts the caller to know that this VI has global effect, and its value may be affected by other callers.) QUOTE(jdunham @ Nov 9 2007, 05:00 PM) That doesn't make sense to me. Use one style or the other. Several users have told me that when the types are mixed on one diagram, they get confused about what is a node and what is a terminal. I know it has happened to me too. I find the large icons have lots of useful information for non-LVClass types -- the conpane of VI References, the type of refnums, and typedef identification. It's a style choice whether you like large or small, but pick one.

I have posted a new revision of the Map class, now with tree balancing. I have edited the original post (so that anyone in the future who stumbles on the thread doesn't use the old revision by accident). For convenience, here's a link to the original post so you can download the revised class. As you can read in that post, I didn't implement the tree balancing. Thanks to Jason Dunham who offered up his code for everyone's consumption.

I'm going to flag this whole discussion for the LV performance team and see if there's any feedback. They're a bit busy at the moment, so it may be a while before a response.

QUOTE(silmaril @ Nov 9 2007, 04:25 AM) I got it wrong... it's the == that's false and != that is true. It's the <, > and == that are false. I knew there was some logical impossibility that you could find -- ie a two numbers that are neither greater, lesser nor equal to each other -- but I got it wrong in my memory which logical impossibility it was. (I should learn to double-check the documentation before posting details like this...)

QUOTE(crelf @ Nov 7 2007, 04:16 PM) Open TCP/IP prim has a required "port" input. But the VI for connecting to the web has an optional input for "port" -- it defaults to port 80. You can still provide a port, but in that case, most of the time the default is fine. So use case is anytime a generic API is used in a specific context, there may be a 90% use case for the specific case, but there's no such for the general case. So you make it optional in specific and required in generic.

QUOTE(neB @ Nov 7 2007, 01:54 PM) I DISBELIEVE. Simply put, the conpane pattern isn't even known to the compiled code. There's no way that could make a difference. The gencode only knows about the terminals that are actually used. I mean, conpane isn't even in the LV runtime engine -- it *can't* be compiled into the code in any way shape or form. Oh, and LV doesn't have a call stack. The dataspaces are just patched together directly. There's no call overhead unless inputs have to be copied because the input has to be unshared to avoid stomping on the original input.

If ever direct link doesn't work, just do this: Go to www.ni.com In the search text box, type in "Product Suggestion Center". The top hit is the link you're looking for.

QUOTE(Michael_Aivaliotis @ Nov 6 2007, 12:22 PM) This is why I've been pushing features such as custom probes, custom icon editors, etc. Then implementation *is* your problem. Mwuhahahaha!

QUOTE(mballa @ Nov 6 2007, 09:36 AM) That's explained in the description of the VI that converts from array to flat string.

QUOTE(Robbie Gehbauer @ Nov 5 2007, 03:04 PM) The inverse of that VI is in the palettes -- the one that goes from path to class. The one that goes from class to path is not in the palettes. [One of the dangers of working with unreleased versions of LV; can anyone guess what will be in the palettes in the next release? :-) ]

Here's even better... actual code...

QUOTE(mballa @ Oct 29 2007, 09:02 AM) I posted new versions of the tools on the ni.com page. Download the new VIs and see if the pieces you need are now available. I redid the block diagrams so that more was un-password proteced. I don't think there's any way to get an LVClass Refnum in LabVIEW other than the app methods Open or Create, but perhaps what I've exposed for you will get you enough from the class names.

The reason for the "Is Nan?" prim is that testing for equality of NaN is tricky. According to the IEEE standard for floating point calculations (which LV follows), if I have a value A that is NaN and I compare it to a value B that is NaN, then I should get FALSE for tests of both equality and inequality. In other words, A!=B and A==B are both false. That's how you detect NaN. This makes it hard to build generic code for checking "is the input wired?" because anytime you want to use NaN as your magic value, you have to do different work than any other data type. Your best bet would simply be to create two VIs, one that has the input marked as Required and one that doesn't have that input at all. The user could then drop whichever one they needed. You might be able to do something clever involving a polyVI used to select between instances, too, but all the ideas I can think of along these lines have some drawback.

QUOTE(YaSmEeN @ Nov 4 2007, 02:35 PM) No. You can put a tab control on your front panel and access multiple pages of that.

QUOTE(Michael_Aivaliotis @ Oct 18 2007, 01:42 PM) You know, if I wanted to maintain two copies of the VIs online, I probably would've said something like, "Please cross-post these VIs to a site other than ni.com, such as LAVA, so that if I make modifications I can have the joy of updating two forums instead of just one." For the record, I didn't say that. Oh, by the way, there's a new version of the .zip file posted on ni.com (follow same link as my original post). I'll leave the cross-posting as an exercise for the reader.

QUOTE(Justin Goeres @ Nov 2 2007, 02:29 PM) Just in case of what? If I have 2^15 x 2^15, I get 2^30 as my maximum bound. It can't exceed I32, much less U32. I only went to U32 because an area should never be negative.

QUOTE(wevanarsdale @ Nov 2 2007, 12:41 PM) OH! You're right! I was looking at the dimensions and seeing I16 x I16, and thinking "what's the big deal?" But I16 x I16 gets stored back into an I16, so of course, that's pretty small. The dimensions need to be cast as U32 *before* the multiplication node.

QUOTE(paracha3 @ Oct 31 2007, 02:07 PM) a) Default instance shouldn't be private. Not sure what you're seeing that makes you think it is, but it is a public property, quite deliberately. b) The default instance property doesn't work in the runtime engine. To get around this, LV8.5 includes a VI in the "Cluster, Class & Variants" palette that does the same thing as the property but works in both the dev environment and the runtime engine. (PS: That reminds me I need to update the Factory pattern in the document so that others don't get burned by this.).

QUOTE(jpdrolet @ Nov 2 2007, 07:04 AM) But 32767x32767 pixels is a HUGE diagram. Both of my monitors together are 3360 pixels across, so I think we're ok. Anyone making VIs that cant fit within 32767x32767 needs to discover "Create SubVI From Selection" quickly (or they've got a bastard developer on their team who is hiding code way out at the edges of diagrams hoping it won't be noticed).

QUOTE(Norm Kirchner @ Oct 31 2007, 04:13 PM) And yet there might be people who don't know what LVX is. Can you post a link to previous discussions about this?

QUOTE(paracha3 @ Oct 30 2007, 06:02 PM) Look up the Factory Pattern in the http://forums.lavag.org/LabVOOP-Design-Patterns-v10-t3845.html' target="_blank">design patterns document.