LAVA 1.0 Content

Was this issue solved?

I got Brian's project to "vanish" (crash without error message) on Friday although I didn't follow Brians instructions. However today I cannot make it vanish even when I follow Brians instructions. Seems like a hard-to-find memory leak bug.

Consider a LabVOOP object. It can contain provate data elements. These data elements can be objects or contain objects (e.g. in clusters and arrays) and these objects can further contain private data elements that are objects. Do not confuse term object with term class here. So the object refer to other objects which refer to other objects and so on. This construct forms a data structure we call a tree. As objects do not share memory in LabVOOP, there are no nodes (objects) in this tree that are children of more than a single other node. Furthermore objects cannot refer to themselves. The question now is how to effectively modify for example a leaf node of such a tree. As examples are easier to comprehend, let's make an example. Consider a file system. You start with the following object hierarchy. File System ObjectFile Folder File is a data container, it doesn't refer to any other file system object. However Folder refers to zero or more other File System Objects. This UML relation looks the following. Folder (1) ----------> (*) File System Object Let's consider that we now want to add a file to this file system hierarchy. Now we can call Add File method of a Folder, but as objects are by-value and not by-reference, this doesn't update the tree but creates a copy of the original Folder which is updated. The challenge now is what kind of design pattern should be used in general so that the whole tree gets update appropriately when it is passed to a method that modifies one of its nodes that is not a root node. An intuitive way would be to implement a dynamic method "Add to Tree" to the File System Object class. This call would add a file or folder to the tree to a position specified by user. The method would return a modified tree. Simple and elegant but in LabVIEW it doesn't work. First recursion is not possible. Second dynamic VIs cannot be reentrant so that recursion is not even possible using call by reference node. Third there is a bug that crashes LabVIEW and corrupts projects when adding a call by ref node to a class method. So this method seems to be opted out. Well, you can traverse the tree using shift register as a stacks. To be able to traverse the tree, we add a dynamic method Get Children to File System Object class. This method is overridden by File and Foder classes. This makes your simple method of adding a node quite complicated. It works for the File System Object case as all children objects are File System Objects. But this is not always the case. You may need to modify a tree where you do not know what kind of objects there are in the object tree. So currently I have no idea how to manage tree traversal in a general use case where you do not know what kind of objects there are in the tree. Recursion would be a reasonable way to go, but for some reason it is not possible in LabVIEW. I now challenge you dear developers to think of a general way to modify by-value object so that the modification doesn't target to the object itself but one of it's private data member objects or their private data member objects in such a way that the hierarchy may contain multiple instances of the same runtime class, e.g., a Folder. If there is not general solution to this problem or the solution is so complicated that it's practically unusable, then I strongly suggest NI to make recursive calls to both dynamic and static class methods possible.

As nobody has yet aswered, I'll try to clarify my problem a bit. Consider a LabVOOP object. It can contain provate data elements. These data elements can be objects or contain objects (e.g. in clusters and arrays) and these objects can further contain private data elements that are objects. Do not confuse term object with term class here. So the object refer to other objects which refer to other objects and so on. This construct forms a data structure we call a tree. As objects do not share memory in LabVOOP, there are no nodes (objects) in this tree that are children of more than a single other node. Furthermore objects cannot refer to themselves. What if I need a graph instead of a tree. I'd still like to take advantage of highly parallel nature or by-value LabVOOP. In my main application the wire should always pass the whole graph. When the wire is branched, a copy of the graph should be made. Only when traversing the graph the graph nature should be visible. If I had a copy constructor together with by-reference object I could get by-value implementation of a graph. But I do not, not yet at least.

Now that I've used LabVOOP very extensively over the past few months, I must defend NI here. LabVOOP is not a traditional OOP language and it should not be considered to be a traditional OOP language. There defenitely is a need for by-reference implementation in some use cases, but not all. Indeed, by-value implementation provides a very powerful tool for some other use cases. By-value implementation allows the developer very efficiently to parallelize the processing as objects share no common memory segments. This becomes a very important fact as we are beginning to see super scalar processors with eight or even sixteen cores. As objects do not share common memory, the computation can easily be distributed around a cluster which will really provide huge benefits over shared memory processing of by-reference implementation. I do not think that by-value and by-reference implementations are mutually exclusive, e.g., C++ has both variations side by side. Although LabVOOP doesn't currently have a by-reference mechanism, that can be added later on whereas by-value implementation cannot be added on top of by-reference implementation, at least not any straight-forward way. (Single-element-object-queues cannot be considered a by reference mechanism as queues cannot be passed to subVIs with a parent class input connector.) Instead of blaming the current LabVOOP implementation of pitfalls, we developers should be constructive and suggest how LabVOOP can be further developed into a more powerful programming language. NI cannot go back and change the current implementation any more, but it can go forward and make it more flexible and even include by-reference objects. Those developers blaming that the by-value implementation is purely wrong should stop thinking if they can also take benefit from the super scalar nature of the by-value implementation. I myself am currently working on a project where we try to write a massively multithreaded application totally based on LabVOOP classes. p.s. There still is a by-value object use case I do not know how to implement using LabVOOP elegantly... anybody smart enough to come up with an elegant solution?

Yes, this works. Although opening VI reference by VI path is a bit clumsy and of course very slow. I also suspect that there may be a LV 8.20 bug related to opening VI references to class methods using open VI reference and then calling then using call by reference node. Have you used this methods Brian? If you have, have you encountered mystic project corruption or LabVIEW crashes especially when using dynamically called VIs? EDIT: Brian, it seems you were fast finding a bug You may have saved my day or really rest of the year. I've a project that probably corrupts because of this bug and I cannot submit the project to NI support as it contains confidental parts that are hard to isolate.

Super strings and other super nodes are invisible with your current energy level, it's Friday agter all. You should retry on Monday after you have rested over the weekend. However it may be that the super nodes appear only so shortly that you are unable to see them although they really are there. Debug your block diagram carefully, a super string node may appear transiently as your data passes trough it. It may also make some sort of sound, so make sure your work mates keep quiet as you debug your diagram. p.s. I really want NI to add animated as well as noisy icons. Imagine a VI which would make sounds as you debug, wouldn't it make life so much more exciting... (do we have a life?)

Sorry AQ, it doesn't work in my case. It's the class private methods that should see the correct value in the private data and it's too large an overhead to require all the class methods to access class private data using class methods instead of directly accessing the data. The real reason I asked this question is that I've an application that needs to initialize an object huge number of times (order of million times a run). As calling initialization method is an overhead in this case, I though of by-passing method-based initialization and using contant-based initialization. However it appeared not to be possible. So when you will work on constructors for LVOOP in the future, please use "constant folding" so that constant initalization would be computed already at compile time if just possible to speed up the execution.

AND fairly close to what I guessed! I've mentioned before I'm dyslexic, maybe that's why I got them reversed :laugh:

Excellent. I'll try to remove the most sensitive parts from the project. If I still after that manage to recreate the problem, I submit it to your support. I appreciate Roy that you considered my problem important enough to post your first post to this forum! Thanks for the proposal. I did consider this. I tried to open the project on another computer, but it was corrupted there as well. As I don't know if the corruption is due to prior memory errors, I'm currently running memory diagnostics. Nothing found this far. EDIT: At least one 1 hour test passed. So memory problem is very unprobable.

I tried. I reverted to a working backup and then edited every VI so that allow debugging is turned off. LabVIEW crashed when I tried to save all VIs and I ended up having a corrupted project. I haven't retried it yet.

I reverted to my sunday backup. It seems to work fine. I repeated the work I did on monday and tuesday i.e. added one class to the project from scratch. Guess what. The project got corrupted again, exactly the same way as the last time. EDIT: I talked to the local NI support this morning. They had no ideas how to help. They could only help if I could isolate the bug. I don't know how. Without symbol tables for C++ I would need to reverse engineer machine code. Gets kind of hard. So I have a project we have been working on for three months now. It is in two separate pieces the other one of which gets corrupted when I try to work it further. Despite of the SSP contract NI cannot help. There are no patches available to LAbVIEW and as Stephen said, there is no public information when one will be available. Nobody knows if the patch will even fix the problem. I start to think of our team moving to the combination of native C++ and managed C++ sooner than I thought yesterday. Any ideas? EDIT2: The debug output of Visual Studio debugger looks like following when I try to open my project and LabVIEW crashes: Another place where I see odd behaviour is whn I try to close my project after saving all. A popup appears asking me to save some unsaved VIs (although they were just saved). The debugger output during this thing is below: Missing HResource for _ProjectWindow gUnattended will cause VIs leaving memory during GetInstHandle to get saved automatically. This is dangerous. -nick.neumann EventOracle::DestroyQueueObject 2 EventOracle::DestroyQueueObject 1 Successfully loaded "Save before closing?"

When you create and override VI, LabVIEW will insert call parent method to the VI. If the parent method icon is not of standard size i.e. the icon is smaller, the override VI will look funny by default. Well this is not the bug however. The bug is that when you move the call parent method node, the dispaly is updated incorrectly. See the attachment.

Hi, I have a class hierarchy of multiple classes in LVOOP. Let's call my top most parent class "Car". I define it a private data member which I'll call "top-speed". I set default value to 0 as my general car doesn't have top speed. The I create a child class called "Ferrari". As I know that my Ferrari top speed is 200MPH, I'd like my Ferrari class constant to really represent this value. So the question is, is there a way to define different default value for the parent private data in a decendent class so that when I drop Ferrari constant to the block diagram, it would at least have correct properties for Ferrari. There are no constructors in LVOOP so I cannot use constructors to take care of the task as in other OOP languages. I can write an initialization function, but I wonder if it could be avoided. I guess not... (perhaps this post should be in the wish list section and not here).

I hope you undestand that this kind of data modification changes the statistical distribution of the data i.e. extremas become more probable than in the original data. Therefore you shouldn't run statistical tests to the data decimated this way unless you modify the tests to take the modification into account (which may be very hard to do properly).

I don't know exactly what you want but what about something like this...

Search the LAVA and NI forums with the keyword "protection" http://forums.lavag.org/index.php?showtopi...p;hl=protection http://forums.lavag.org/index.php?showtopi...p;hl=protection

Thanks Stephen for your extensive reply. We've been using this method you proposed for about a month now and it really stabilized the development environment a lot. However it seems not to prevent all the corruptions and all the crashes. I'm afraid that there are major problems that NI development team are still not aware of. There are crashes when I press the run button even though we've followed this guideline. There are crashes when I try to Save all. There are crashes when I open projects. What I'm most afraid of is that there are corrupted VIs or other components as a result of these crashes and I have absolutely no means of finding it out. We made a move to LabVIEW 8.20 because of LabVOOP. We were starting a major project by the time we knew that LabVOOP is going to be released. This project would have been architecturally near impossible without some sort of OOP. LabVOOP made the project possible, although lack of constructors, copy-constructors and destructors is a still a major problem. We can work around constructors, but there is no good work-around for the lack of copy-constructors and destructors. We would also need by-reference classes for some parts of the project, althougt at least in our project we also benefit from the fact that LabVOOP is not only by-reference as it scales better this way. In addition inability to create reentrant dynamic VIs causes us problems. We need recursion and we have managed to center all the needs for recursive calls to only one VI. We have divided the recursive calls to three different VIs. A reentrant VI that is called recursively and that does all the actual processing. This VI is a static class VI that has a required class input and a recommended class output. A second reentrant VI that does the actual calling using call-by-reference-node. The first VI calls this second VI to make the call to isolate the call to a single place. Third non-reentrant VI is used to manage VI references to the first VI, opening them when there are not enough references open already. The opened references are stored to a shift register to allow fast recursive calls. This three VI structure seems to cause major problems, probably because the VI-references to the first VI opened by the third VI do not get properly updated as the class structure changes. Our project was quite stable until we added this structure. We have written it twice and both times the project became unsable after adding this structure. The second time it seems a bit less unstable than the first time. What would make me more trusting towards LabVIEW would be totally different kind of attitude towards known bugs. and towards professional developers First the known problems should be public and NI should publish workarounds to these problems if there is one. Second NI should release patches to at least major bugs as they are fixed, not waiting a major service pack to be released once a year. This would help us developers to identify which bugs still need reporting and which are already fixed. Currently we have to wait for the next major release. If the problems we are encountering are not fixed in this release it may take another year until the problem is fixed. This simply is not acceptable. Third there should be a way to find out if any VIs in the project are corrupted. Current Ctrl+Shift+Run doesn't fix all corruptions and there is no way locating corruptions. The worse thing that can happen is that corrupted VIs written many years ago make application crash and there is no way for the developer to locate the problem. Fourth NI should somehow guarantee the professional developers that LabVIEW is developed as a general purpose programming language for large scale applications and not only as a tool to create very small and simple projects. Currently there is no such guarantee from NI side, on the contrary NI is putting very much effort in developing all those useless features targeted for nobrainers. If we professional developers cannot feel valued customers whose needs and opinions are listened, how can we go on using LabVIEW as a development tool. Fifth there should be a public roadmap for LabVIEW so that we developers could estimate if LabVIEW is keeping up the pace. Now we need to live in the darkness until NI releases their next release. We have no idea if they are going to commit to one feature or another. Sixth NI should open a new forum targeted especially for professional developers. Current NI forum is used too much by beginners and is therefore useless for communicating about advanced issues. LAVA is a nice forum, but being NI external forum it doesn't reach many enough NI developers. Seventh NI should make available the source code for LabVIEW core under GPL type license (including LabVOOP but excluding hardware integration) and release advanced debugging tools so that developers wouldn't be 100% dependent of NI in fixing the bugs related to their application. Currently if there is a bug in LabVIEW source which causes our application to crash or misbehave, there is simply no workaroung. You cannot guarantee your customer that your product is 100% reliable if you don't have control over the source code of your product. NI just doesn't have good enough a track record to make us trust. Eighth there should be gold or platinum level support contracts that would guarantee that LabVIEW bugs are fixed in certain time window so that large developers would have more safety in the development process. Ninth NI should target LabVIEW to a larger audience as a general purpose programming language so that LabVIEW developers would have larger customer base for their products. It is hard to be a LabVIEW developer in a world where LabVIEW is such a small niche. Our current vision is that for the time being we will use LabVIEW as it provides a fast way to develop what we are developing. We can test our concepts using LabVIEW pretty fast compared to other programming languages. However we do not see it possible for us using LabVIEW as development tool for our enterprise level application and API, because of the above mentioned problems and because of some short comings in the language itself, especially due to the difficulty of expressing by-reference data. I very much appreciate your contribution Stephen to this forum and to LabVIEW development towards more like a professional tool. If NI as an organization would have similar target as you personally do, I wouldn't think we had a problem. But NI as an organization is not giving us much hope with it's current policy towards professional LabVIEW developers.

Well, to be honest, I don't know. LabVIEW is not very informative when it crashes. I'm using OOP very extensively, so I assume quite many of the bugs are OOP related. It seems that there is a bug in the OOP compilation algorithm, probably not all class related constants get updated correctly, which corrupts VIs and then causes crashes. The crashes themselves occur because LabVIEW doesn't seem to properly handle exceptions, and does not check for invalid NULL pointers. One of the bugs probably relates to calling OOP VIs using Open VI reference and Call by reference node combination. The VI Type specifier constants probably do not get correctly updated when an underlying class of one of the connectors is modified and this may cause crashes. In addition some of the bugs have been project explorer related. I've made a decission to move away from LabVIEW in the future mainly because it simply is not stable enough for our purposes. As we are developing developer toolkits this also means that NI will loose all those customers that will use our tools. The only way I can see us using LabVIEW is that LabVIEW core source code will be opened so that the community can make the core stable. In addition this would help LabVIEW to develop towards the needs of professional users and not only the needs of newcomers. I wouldn't care if DAQ related parts of LabVIEW were closed source as long as the core would be open source.

I encountered the same bug. Did anyone find a solution that doesn't require moving dynamic VIs to static ones?

Hi, LabVIEW 8.20 seems to have a large number of bugs that make LabVIEW either crash or freeze or corrupt the project etc. I've very patiently been sending bug reports to local NI support. They have then submitted bug reports to the head office. However the head office has refuced to investigate bugs that occur on large projects because "these are project dependent bugs and cannot be recreated in an empty project". I have managed to recreate some of the bugs with an empty project but some of the bugs really seem to occur only with large projects. As I am not NI test engineer, I cannot consume my time by trying to create empty projects that bring up bugs. Rather I need to get my projects on the right track again so that I can continue my work. Because of these kind of aswers, I've stopped sending my large projects that cause LabVIEW to crash to NI support as it doesn't help me nor anybody else and only causes extra work to local NI support. The question is, is there any way to debug LabVIEW bugs by yourself. And I do not mean LabVIEW VI bugs but LabVIEW core bugs. I once again ended up into a project that I cannot get opened again. LabVIEW either crashes or freezes or claims that "cannot copy reentrant dataspace" depending on how I try to open the project. I have a backup from yesterday which I could revert to, but as this is a bug that keeps occurring again and again, I'd like to finally know why this bug occurs to be able to avoid it. The current project contains classified information, so this time I even cannot submit the project to NI, at least not without explicit NDA which I regret they will refuse to sign.

I read it perfectly, Thank you...

Hi, I need to implement a graph structure in LabVIEW. Each node in the graph can be of any subclass of Graph Object class. No graph object can directly derive from "Graph Object" class but one of its subclasses which define what kind of "Graph Object" we have. Not all "Graph Objects" can have children. As a structure graph is like a tree but the nodes can have links from one tree structure to the other. You can think of it as a file system directory tree. The file system objects can be of three subtypes: files, folders or shortcuts. Files and folders together form a tree and shortcuts make this tree a graph. Files cannot have subobjects whereas folders can contain multiple subobjects. Shortcuts contain one subobject. In a general graph there could be recursive references, however that's something that I do not need. So I can do without recursive references from an object back to itself or one of its predecessors. One additional requirement is that the graph flows i.e. the implementation is pure dataflow and is not implemented using queues or other kinds of globals. This restriction is due to the fact that the problem I'm solving is very computing intensive and I need to get it highly parallel to decrease the computation time. Now I'd like to ask the community what do you think would be a best possible way to implement graph data structure in LVOOP as pure dataflow. We could contrain to an example of filesystem with shortcuts as I think it is general enough that I can derive the solution to my problem from the solution to the file system problem. The class hierarchy would then look something like this. LabVIEW ObjectFile System ObjectFile Object Folder Object Shortcut Object

There are cases where you know that your problem is highly parallel and very processor intensive. In these cases it would be nice if you could force the calculation to dynamically distribute to multiple processors without explicitly dividing the problem into multiple parallel loops. There could for example be a right click menu from which you could select how the loop is parallelized. The options would be: Sequential ParallelDynamic Two threads Three threads Four Threads Five Threads Six Threads Seven Threads Eight Threads ... The dynamic option would define the number of threads for the loop at runtime and create copy of the loop dataspace for each thread dynamically at runtime. If user would specify the number of threads at compile time then the compiler could create the dataspaces for each thread already at compile time and therefore the looping would be performancewise more efficient. If the number of required threads is not known at compile time the user should select Dynamic, especially when the computation inside the loop is heavy and the cost for spawning the threads is low compared to the total computation time. Alternatively to the context menu configuration parallel loop structure could have an optional constant which would define the number of threads at compile time. This constant would be disabled if the loop would be configured for dynamic parallelism.

http://en.wikipedia.org/wiki/SI_prefix I guess "p"refix might be right I had posted on LAVA a year or two ago that I thought it was for positional; but hey, we learn something new every day