Aristos Queue

QUOTE (Yair @ Jun 27 2008, 05:31 AM) What you're missing is that I didn't fully explain how the PStr is encoded. a) The PStr is a length byte plus the text, so that is 17 bytes, not 16, and thus padding is required. b) The first byte, 0x12, is the total length including padding: 18 c) The second byte, 0x10, is the total length not including padding: 16 d) Thus 18 + the two length bytes = 20 QUOTE Are you sure you didn't switch the 8 and 11 here? In the code, \b comes in the first part and \t comes in the second. \t is the tab character, which I thought was character 11, but I checked my ascii table. Turns out it is 9. I corrected my original post. I also added the hex view for clarity. \b is not hex 11 as you thought. It's the slashcode for character 8.

> Can someone advise us on the additional changes that must be > incorporated (step-by-step) in the .dll generation with already > existing wrappers? I've never seen a DLL that you couldn't invoke from LabVIEW. What sort of changes are you expecting that might be required? Are you getting any particular error code from LabVIEW when you try to make the DLL call that might shed some light on this? NOTE: If you cannot find a trivial solution to this problem, you really should be posting to the DevZone Forums on ni.com. The AEs there have a better chance of answering this sort of question.

QUOTE (highway @ Jun 25 2008, 12:27 PM) Not necessarily. The editor is a much heavier component than the run time engine alone. There is some weight to the engine -- just loading a VI has some operational overhead -- but in any non-trivial VI, what is going to matter more will be what you're actually trying to do in your VIs. If your VIs are computation heavy, you may have a problem. If the VIs are lightweight, they may work just fine. QUOTE Also, the 2 computer have different distributions of linux, will that be a problem? Or do I just need to develop my VIs on a linux computer no matter what distribution? Not my area of expertise. :-) I'll let someone else answer this.

AH. By *dragging* from the tab to the shortcut bar, I now have the icon. Just creating a new shortcut and typing in the address didn't do it. I wonder why the other links successfully got icons? Who knows.

Welcome home, wolf. :-)

What would it take for LAVA to have a glyph of its own when it is displayed in my browser's list of shortcuts? Some websites have them, some don't, and I don't know what makes the difference.

This document on ni.com details all the ways that LabVIEW classes can preserve data values that typedefs of clusters cannot. It goes into detail about what type of data edits can be preserved, what the effects of renaming a class are on the class, its descendant classes and its caller classes (those that use the renamed class as a data member). http://zone.ni.com/devzone/cda/tut/p/id/6316 All of this preservation of data and the automatic mutation of flattened data from one version of the class to the next is possible because of the format of LV classes when flattened to a string. That format is documented in another LAVA thread.

QUOTE (Eugen Graf @ Jun 24 2008, 05:08 PM) You can create a flattened cluster string in C++ and then write a custom unflatten routine for your class that can parse the string and populate the fields of your class. But if you want to use the Unflatten From String primitive, then you'll have to format the data like a LabVIEW class gets flattened. What does an LVClass look like when we flatten it? The string has four parts: "NumLevels" The first 4 bytes represent a uInt32. This tells us how many levels of the hierarchy are recorded herein. SPECIAL CASE: If NumLevels is zero, absolutely nothing else follows. Zero indicates that this is an instance of LabVIEW Object, the ancestor of all classes which has no fields, no methods and inherits ex nihilo. "ClassName". The next several bytes represent the fully qualified name of the class. First there is a single byte that tells the length of the qualified name of the class. This is followed by a sequence of Pascal strings , each one representing one segment of the qualified name. The last Pascal string is a length byte of zero. This section of the flattened string includes enough zero pad bytes to increase the class name section to a multiple of 4 bytes. "VersionList". The next series of uInt16s that represent a list of version numbers. Each version number is 4 uInt16s, usually written in the format W.X.Y.Z, where W, X, Y and Z are each a uInt16. There are NumLevels of version numbers. The first version number is the version of ClassName class, followed by the version number for ClassName's parent, and so on to the version of the oldest ancestor (not including LabVIEW Object). SPECIAL CASE: If NumLevels == 1 and the version == 0.0.0.0, then this is the default data of the class. Skip section 4 -- no further data follows in this special case. If version is zero for any other value of NumLevels, the string is considered corrupt and the unflatten functions will return an error. "ClusterData" -- This is a series of flattened clusters, one for each level of the hierarchy. The first cluster is the oldest ancestor class. Pay attention: The version numbers start at the descendant class and go up the hierarchy. The cluster data starts at the oldest ancestor and goes down the hierarchy. Each block of data starts with 4 bytes interpreted as an int32. This int32 represents the number of bytes in the data that follows. If this number is zero, then we use the default default data for this level of the hierarchy. If this number is non-zero then this is the standard flat data representation for the cluster at this level of the inheritance hierarchy. After each cluster there are enough pad bytes to get the length of the string back to a multiple of four. Here, for example, is a flattened class object (I put the string into slash notation to make this "easier" to parse): 00021210Bacteria.lvclass000506070b0100000t0000000f0004abcd0000 The first 4 bytes are NumLevels. NumLevels in this case is 2. So we have a class that has one ancestor between it and LabVIEW Object.Next is the PStr that is the name of the class: Bacteria.lvclass. After that are 2 NULL pad bytes to get the length back to a multiple of four.Next is the first version number: 5.6.7.8. That's the version number for Bacteria.lvclass.Next is the second version number: 1.0.0.11. That's the version number for Bacteria's parent class. We'd have to have Bacteria in memory to ask it "Hey, who was your parent class back when you were version 5.6.7.8?"Next come the data blocks.The first data block has data size 0. That means that we'll just assume that the parent cluster was the default default value.The second data block has data size 15. So the next 15 bytes are a flattened cluster of the cluster of Bacteria when it was version 5.6.7.8. Remember that the Bacteria.lvclass currently in memory might be a much later version of the class -- LabVIEW will automatically handle the conversion for you (which you can read all about here). In this case, it looks like those 15 bytes of data contain a string ("abcd") and a couple other cluster elements. Just write code in C++ to generate this string and you can have LV unflatten it. Contrariwise, you can have LV flatten the string and you write the C++ function to parse it. IMPORTANT NOTE: The flattened form of LV data is readable on *any* endian platform. We always flatten int32s, uInt32s and other data types into little endian order. If you are on a big endian machine, make sure that your custom write function takes care of reversing the bytes.

QUOTE (jjylf @ Jun 24 2008, 08:11 AM) Yes and no. JAVA uses object serialization -- implement the "Serialize" interface on your class to have it be able to flatten and unflatten. The primitive types of JAVA have serialize naturally implemented for you as part of the language specification. The problem will be that LabVIEW's flat string format and JAVA's are almost certainly not the same. There's no IEEE standard for flat representations of numeric data. Workaround #1: If you use Antoine's solution (the one that Ned recommended that you NOT use), this is something that LV can read/write and JAVA can read/write. Use this: ObjectOutput out; out.writeInt(5); to create the string, and use the inverse InputObject to read the string in Java. Workaround #2: LV's format for flat data is documented in the "interfacing to external code" documents that ship with LV. Java's format is similarly documented (I know O'Reily's has it and I'm sure that in one of the various online doc sites you'll be able to find it). Write code in one language or the other that can read/write the other language's format.

a) The context help wires issues is a known bug in 8.5 (and 8.5.1). It will be fixed in the next version of LabVIEW. b) A class is a library. So is an Xcontrol (.xctl) and a StateChart (.lvsc). The "link to" option should work for any of the library types, even though the radio button explicitly mentions .lvlib. If it doesn't work, let me know. c) Having said (b), the issue you mention of the palettes showing only the VI name... this is intended behavior. There's no room to display the full name of the VI, with all of its library qualifications. So we only show the VI name and assume that whatever palette layout you're writing will make it obvious from context what library this VI is a part of -- either by its icon or the name of the palette. The "link to" option -- if you used it for a .lvlib -- would not have any effect upon the display name of the VI in the palette.

QUOTE (crelf @ Jun 15 2008, 09:23 AM) QUOTE One of the reasons we have the t-shirt is to demonstrate a united force at NI-Week, and if everyone shows up wearing different t-shirts, then that perception is much less effective. Besides, you'll have http://forums.lavag.org/Pick-your-niweek-2008-badge-icon-NOT-t10978.html' target="_blank">the NI Week badge icons to show individuality. :-)

Demo VIs are ALWAYS more exciting when they involve man-eating rabbits. If you don't believe me, you can be the one to tell the man-eating rabbit squad that they're not getting a part in the demo. I for one am happy to submit to their demands. (Note: This replaces my former Declaration #1 which was that sine waves are boring and do not make for a thrilling demonstration. That is now renumbered as Declaration #2.)

QUOTE (Jim Kring @ Jun 17 2008, 04:25 PM) Careful what you ask for, guys. LabVIEW 20.4 will be sentient and after your jobs. :-)

Looks a lot like the stuff I did growing up, just with less typing. :-)

QUOTE (tcplomp @ Jun 17 2008, 05:13 AM) You're right that conversion and typecast are behaving differently, but that would change on a machine with different endian-ness.

So would I. Since I know you know how, please report it as such.

QUOTE (iandev @ Jun 16 2008, 03:04 PM) What is the "original problem of collision between equal method names in those classes"? Is AppBuilder throwing an error because those VIs have the same file name? That shouldn't be happening. What should be happening is that those VIs are saved next to the EXE, each in their own subdirectory, where the EXE can access them. That's the expected behavior of LV8.2 and 8.5. It is not considered a bug, although it is considered to be behavior we want to change in the future, but at the moment two VIs of the same name cannot save inside the EXE because historically it wasn't a scenario we had to worry about and the old code requires more refactoring than we anticipated. It's being worked on for a future LV release. But you should be just fine building apps today.

Reported to LV R&D as CAR #116157.

QUOTE (tcplomp @ Jun 16 2008, 05:50 AM) a) These items serve no purpose outside of the LV editor (i.e. they have no value to a user writing his own programs in LV). That's the first thing that recommends them for being private. b) The API for these items had some dispute about it. We may decide that we want to change the implementation of these properties/methods in the future LV versions. Making these private means we do not have to support any mutation of existing VIs that load in that future version. We keep a list of which of our VIs use those properties/methods, and we don't bother trying to programmatically mutate other VIs on the off chance they use these properties/methods. c) It doesn't fall in the category of items that we want to have AEs provide support for. These three reasons apply to the particular properties in question. There's a fourth reason that things become private and that is that it opens some sort of door that, if used incorrectly, can destabilize LV itself. That's not the case with the particular properties we're discussing today. If enough reasons apply to a given property, it becomes private. It's the personal judgement call of the individual LV developer who creates the property/method.

QUOTE (Eugen Graf @ Jun 14 2008, 07:51 AM) You should use static dispatch when it fits your design. You should use dynamic dispatch when it fits your design. I know... that isn't the simple rule that you're hoping for, but Tomi really did lay it out for you very very well. If you have a class that you know will never have any descendants, then, yes, you should make everything static dispatch. There is a small performance overhead for dynamic dispatching and there's no point in paying it. The only exception to this would be a member VI that you want to call recursively since recursion in LV8.2 and 8.5 (and, I'll go ahead and say, for the forseeable future) requires a reentrant dynamic dispatch VI. If your class has descendants, or if you expect it to have descendants in the future, or you can imagine a scenario in which someone might want to create descendants in the future, then you actually have to think about which to use. If you want to guarantee the behavior of a given subVI call is always the same -- meaning you want to make it one of the invariants of this class hierarchy -- then you should make it a static dispatch VI. Obviously, any member VI that does not take the class as an input is a static dispatch VI. If you want to define an interface and let the child classes provide the details, then you want to create a dynamic dispatch member VI. It is particularly common for certain algorthims to have a public static dispatch VI and a protected dynamic dispatch VI as its core. The static dispatch VI has certain pre-condition/post-condition work, and then the details at the core of the algorithm are filled in by the child classes. This is done to make sure that the child classes never break the contract of the pre-conditions/post-conditions. Since a child class doesn't have to use Call Parent Node when it overrides the parent, this is a useful technique (particularly on large programming teams) for making sure that all child classes are written to conform to certain rules while still giving them flexibility.

QUOTE (Antoine @ Jun 13 2008, 07:08 AM) That's new in LV8.5, not 8.0. :ninja:

QUOTE (Eugen Graf @ Jun 10 2008, 05:17 PM) Hm... my reply would be: "Binary strings are massively slower, require more memory, and are not what you want to use unless you absolutely cannot use variants." Save the binary strings for when you're flattening to a file or for communicating over some network connection.

QUOTE (PJM_labview @ Jun 13 2008, 10:55 AM) You can quickly write a nice little loop using those VIs that post user events with the relevant information to your main event processing loop. I've done it for various apps of my own.

I confirmed this bug. I'll file the bug report and post the CAR number here in a little while. [LATER] This was reported to R&D (# 115897) for further investigation.

I would be surprised if we did any such work on the math VIs until classes have been on RT for at least one release (to make sure they're stable).