LAVA 1.0 Content

You really misunderstood me. I really meant that the developers should be able to choose between by-value and by-ref object-by-object. Everything should really happen under the hood of LabVIEW so that the developer doesn't see all the nasty things of C. Uninitialized references should never exist. That also means that one should not be able to use uninitialized shiftregisters or uninitialized controls with registers. Concurrency control can never be made 100% automatic. Software transactional memory (STM) is as close to automatic concurrency control as one can get, but even STM cannot handle concurrency control when you are doing I/O that cannot be "undone". When there is interactions between the software and the disk, network or hardware then developer needs to use some sort of locking system; i.e. semaphores are accesses at least under-the-hood of LabVIEW.

Cool! I saw that you posted this because I subscribe to the feed with Sage. I download your VI, run it and see your post to this thread. Now I go back to Firefox and post a reply. I switch back to LabVIEW and view my reply Now, why does a dog chase it's tail? Because its fun! :laugh:

You would need to clone method dataspases when wire branches, but you can do it lazyly by cloning only those method dataspaces that are going to be used. Then LV should also have stateless VIs which wouldn't have a state, you should use these when ever you don't need a front panel or uninitialized shift registers. This way you can avoid dataspace copies when they are not really needed. LV now copies buffers when wire branches. Why couldn't ir also make a copy of a few dataspaces. After all most class methods don't really need state so in this paradigm they would be stateless.

Performance is the reason. LVOOP can perform much better being by-value rather than by-ref. They haven't yet even taken advantage of all possible optimizations. So we'll see better performance in the future. By-ref in a dataflow language cannot take advantage of dataflow optimization techniques and therefore performs much poorer than dataflow by-value counterpart. Therefore I think it was correct decission to base the LVOOP on by-value system, so that when refs are not needed, full performance advantage of dataflow can be gained. Of course by-ref should still be a parallel alternative to by-value and I really hope we'll see this in LV 9 or what ever it'll be called.

I changed from to I think the CM Punk (real name Phil Brooks, but not me) was not as classic as Robert Young, aka Bob Y. . My avatar displayed kind of small, and I don't think anyone really got it the joke.... I'm staying with the "LV Punk" name. I noticed that some of my postings have changed from pbrooks100 to Phillip Brooks to LV_Punk over time, but others haven't. I think the name needs to stay the same going forward... F.Y.I. My signature is a play on CM Punk's line "Straight Edge means I'm drug-free, alchohol-free, and better than you!" As a true "Straight Edge" LabVIEW guy, MY line would be...

I got tired of my "CM Punk" avatar, and went looking for something new today. I found a site called makecharacters.com that lets you create your own South Park style avatar by picking the components you like. Here's mine. WARNING: It's addicting, and a bit slow, so do this on your lunch break! There are also some accessories and outfits that might not be appropriate for an avatar.

How about properly naming the inputs to Build Array; primary, secondary, tertiary, quaternary, quinary, senary, septenary, octonary, nonary, and denary! :laugh:

EDITED! I've been experimenting virtual machine software to keep my builds separate. I recommend you try one of VM products. Vmware is market leader, but there are also other alternatives like opensource Xen, commercial Xensource and Parallels. I've been using Vmware products. Vmware server is free but has only limited functionality. Vmware workstation costs a few hundred bugs, and should be targeted for developers. They also have a subscription based product for developers, which includes practically all vmware products for a few hundred bugs a year. It may not be used in production environment. Hardware support may be a problem if you need to have some special DAQ hardware etc attached to your computer. I've no experience in this field. If you build is time consuming, you should verify that both you processor and your VM product both can take advantage of processor-level virtualization. Modern processors have special instruction set for running parallel operating systems simultaneously. You save your bugs and nerves if you can build all on one physical machine using multiple virtual machines. Virtualization also gives you other advantages over multiple workstations. You can create virtual machine images for different environments and this way easily test your product on different kinds of environments. If you have a mac, you can run Windows XP, Windows 2000, Linux and OS X operating systems all in one machine using VM product. With virtual machines you can store snapshots of your system and revert your environment back to some previous snapshot state when ever something goes wrong. EDITED!

This is what I thought. Then I'll stick with my queue version of polymorphic datatype.

If I pass a buffer of anything to CIN/DLL on one terminal and return a to the buffer handle on another terminal, LabVIEW doesn't autodispose the buffer now that it is no longer used on block diagram? I've to verify this also since this is a different case from the one you rolf answered.

A colleague of mine shudders every time he hears the words ADA and Green Hills Software.

I'd like to see google search engine embedded into LabVIEW help as it seems to find relevant information at least from the web. I don't like Windows Help system search engine as it always finds topics that are totally irrelevant.

Perhaps I join back to this topic that seems to attract only Scandinavian interest. What I was thinking is that I'll embed the typecasted queue into a LVOOP class as private data. This way I may not get best possible performance, but I do get data protection similar to DataLog Refnums. In addition I can hide the implementation from the user. I start by typecasting to DataLog Refnum as I originally suggested. Later if I feel this is inadequate to my purposes I change to variant as besvingen suggested. I thought implementing the class similar to my last suggestion in topic Refactoring the ReferenceObject example in LV 8.2. -jimi-

I don't see any problem. You of course send the source distribution to your customer and not the entire project. So the customer never sees the password and you never forget it.

Did you already have time to try it out?

About your implementation suggestion, I must say that, I don't really like it. I think that static VIs should not be used as wrappers to dynamic VIs so that one can overcome limitations of the language. I already need to use static VIs as wrappers to dynamic VIs due to the fact that I want to use polymorphic VIs in my classes and I must say that it is kind of frustrating to create always two methods instead of one. I think it would also be hard to explain to users that well, in our language we have decided to implement this feature so that you create two methods, one embedded inside an other, to do this very simple task. Simple tasks should be made simple to achive. Now that we are talking about types, perhaps I suggest something much more general. Something I've been really wanting to see in LabVIEW but have been "too little picky" to request Polymorpic types First of all, I'd like to see polymorphic types. What I mean with this is the following. One should be able to define front panel terminals that are of multiple types simultanously. These terminals would accept all these types of data. Wire propagating from such a terminal could be connected to any node that would accept at least the same types, but could also accept some more types. One can implement such a polymorphic types in a bit similar fashion as enums or arrays are implemented. A polymorphic type controller would be an "type-array" each element of which would be a type specifier. One could also drop another polymorphic type-array into such array so that the resulting polymorphism would include all the items of the array itself and all its subarrays and their subarrays and so on. The "type-array" would be structurally a tree and the polymorphic type of such a tree would be defined by flattening the tree into a set of all the nodes in the tree. Type classes Types should form hierarchies, that is type classes. For example Integer and Floating would be subtypes of general class Number. Furthermore I32 and I16 would be subtypes of Integer type. You could define that your terminal is of type Integer and would therefore accept both I32 and I16 inputs without coercion. The type classes shold in the beginning be built-in only. That is, user couldn't add new members to built-in type classes. Later on however, users should be able to extend type classes by defining own type that belong to certain type class. Type classes are exactly specified by requiring that certain built-in operations are defined for the type. For example a type of class number must have addition, substraction and multiplication defined. Type of class Floating should in addition have division operation defined. Type classes, polymorphic types and type propagation Type propagation of polymorphic types and type classes is somewhat similar issue to type propagation of LVOOP classes. When you wire two DBLs to your "+" operation, you want the output to be DBL. As LabVIEW is now a object-oriented programming, the type should also propagate trough dynamically dispatched methods. So the problematics is exactly the same as with type propagation of LabVIEW OOP classes. Which ever way you decide to implement the OOP type propagation, please make sure it would also be compatible of propagation of other types. I really wouldn't like to be casting all my types all the time. Roadmap Now that we have defined polymorphic types and type-classes, we still need to add wires and extend types so that wires can propagate not only VI references but block-diagrams themselves. We also need totally stateless VIs, real recursion (without opening a VI reference first), local and global variables that can only be written once (i.e. they are also stateless), perhaps lazy evaluation and some kind of lamda calculus, type pattern matching similar to Haskell counterpart and we end up in a fully featured graphical functional programming language. Monads are not needed, since empty wires or something like error cluster can define the execution order for I/O and user interface operations. Loops can be used in dataflow version of functional programming language, as they do not require variables unlike loops in text based programming languages. This kind of general purpose programming language would probably be the most advanced, easiest to use programming language in the world. It would be naturally multithreading and allow writing highly modular code. I think combining dataflow programming language and functional programming language results in a something really amazing. It's a pity that I know National Instruments will never ever do this kind of general purpose programming language. Perhaps I do it myself. Anybody else interested in joining my... quite challenging effort

Grr is right What's a left handed person supposed to do?! It does look very nice, all the options remind me of my brother's Acura steering wheel. He can change CDs, radio stations, iPod lists, etc without taking his hands off the streering wheel. Poor me, a left-handed, dyslexic computer-science LabVIEW programmer with ADHD. :laugh:

Hi, I just went to purchase a new mouse, Logitech MX Revolution. It feels almost perfect. I can strongly recommend. Grr.... how can I not now code all day long :laugh: -jimi-

I thought the correct english word would be sum...? But I'm not native English speaker.

:thumbup: My group's email server is bogged down, so I prefer this to anything in Outlook. I tried the Google Reader, but its a bit awkward to use in my opinion. I like that Sage allows you to mouse over the title and see a preview without actually opening the whole feed in the browser window. Right-click and open it in a new tab is nice too. It appears that some feeds reset the list completely and things I've marked as read come back as unread Now I just need to take the time and figure out how to share my Sage List between home and work computers. I'm sure there is a way, just haven't had the time to look at it... EDIT Well, it bothered me, so I looked into it. You can export your Sage list to an OPML file, then import it on another. I've copied mine to my GMail drive and can now import it at home. Now, if I could set Sage to point to a network stored version of the file instead of import/export.... Hmmm

Hi, I think that there is a way to achieve this, but I have not verified if I'm correct. Presumably you can write your code as "modules" i.e. put your code into LabVIEW 8.0 libraries (.lvlib). Libraries should work like entities that you can easily include to your project. Store the library into a root directory of that library for example "Module A\Module A.lvlib" Then store all your files that belong to this library under directory "Module A". If you have multiple modules, store each module into a different directory. Now when you move directory "Module A" to new location, it's enough if you include this library in its new location to your project. Then relink the project by pressing Ctrl and then click on run of one of your main executables while having the ctrl pressed. Since library gathers stuff together, LabVIEW doesn't need to search for each individual VI but it knows that the VIs belonging to the library are located relative to the library location.

Hi, I've noticed a thing in LabVOOP that is quite annoying. If you have a static method VI, you can pass an object parameter to that method and get modified object of the same class out from one of the output terminals. However, with dynamic VIs you do not get the same behaviour. Dynamic VI methods casts object parameters to the more generic terminal type whereas static VI methods do not cast. See the image below. It's annoying, since if you need to use dynamic VIs to which you pass parameters that are also objects, you need to cast these objects back to original type. I assume this feature is implemented because it may be technically impossible to keep track if all decendent class dynamic VIs also really pass the wire trough the method. If the wire doesn't go from input terminal to output terminal directly or indirectly, one cannot of course preserve type. What I suggest is an addition of a new terminal type similar to dynamic dispatch terminal. This terminal also would require that the wire really continues from input terminal to output terminal so that the type can be passed trough the method VI. However unlike dynamic dispatch terminal, this terminal would not be used for dynamic selection of which method instance to call. I attach also the example project from which the above image is captured. Download File:post-4014-1159251306.zip p.s. I know there are people also on this forum who claim that in OOP one shouldn't create operations external to the class similar to the negate operation in the attached example. However this is not true. There are many more advanced design patterns which use these outsourced methods to add more flexibility and modularity to the software design. Strict encapsulation is often too limited to the requirements of software architecture and this can be in some cases overcome using this kinds of functionality outsourcing. Of course negate is not a good example of these situations, but it is easy to understand.

National Instruments generally won't sell an older version of LabVIEW than is currently released. LabVIEW can generally open VIs from older versions without any problems, the changes will be noted when you load. Simply put, use LabVIEW 8.2 and you're all set. You can download an evaluation version and use it for thirty days before it disables. Talk to an NI rep about upgrade pricing for any older version of LabVIEW to 8.20. There are two options for database access you can look at; see this link (ADO Toolkit) and the LabSQL toolkit. A new book has been released that might help: LabVIEW for Everyone, Third Edition (see link). As far as "employed/annoyed", there are plenty of people who would be HAPPY to be employed, and lots of people who can consult/contract for you if LabVIEW is not your area of expertise. I couldn't follow all the versions/licenses/legal copies statements, but be advised that NI employees do read these forums. There is also a policy of deleting any postings regarding acquiring activation codes or circumventing the licensing of LabVIEW. These are just fair warnings, as this is appears to be your first post.

Sorry to burst your bubble, but I may not have explained the implementation fully. There are three TCP receivers, three loggers and three UIs. Each Receiver creates a unique queue and unique notifier and places the refs in an LV2 global array. Each logger and UI retrieves refs to it's receiver by index. The queue is used by the logger, and the notifier by the UI. I chose the notifier for the UI because it's not a critical function and the implementation of the notifier is "a single element lossy queue" There is only one consumer for each queue. There is no case where the two consumers are reading from a common queue. I need to be able to log without UI for high speed cases, and there is a "stabilize" state that must be reached before logging. So... The receiver can receive and pass data via the queue and notifier. The stabilize state can be determined either in the UI or a separate VI that evaluates the notifier data. When things are "stable" the logger can be started and data written to disk. I'm doing the same thing. I need to perform a least squares fit and "limits test" on a subset of data to show overall state or progress, but "real" analysis could be performed after the fact on the logged data. The data does not necessarily have to be truly decimated (regular interval), just a managable size block for on-the-fly calculations. A lossy queue would free me from "managing" it; I could stuff it from the producer and flush it from the consumer without worrying about an unlimited sized queue exhausting memory, or eating up CPU cycles performing queue checks. I'm thinking of listening to a "full rate" notifier in my "analysis" vi, and using an internal (to the analysis VI) LV queue that would have the enqueue-error-dequeue-enqueue functionality in it; or maybe even a user event that fires the analysis for every N notifications received. If this VI errored or was closed, the internal queue would be destroyed and the notifier data from the producer could "drop to the floor" without penalty. I feel I've been complaining too much about something that can't be changed. I have a method that works for me, so I guess its time to move on and get some work done Thanks to all, and maybe some day we'll have "lossy" queues in LV. Think "Fat Bast@rd" from Austin Powers: The Spy Who Shagged Me... I want my lossy queues, lossy queues, lossy queues; I want my lossy queues, lossy queues, lossy queues... Lossy... Lossy LV queues..