Tomi Maila

QUOTE(gmart @ Aug 10 2007, 04:48 PM) Does this have the same effect as Ctrl + Shift + Run when all files of the project are in memory?

You provide us now with too little information to solve the problem. Are you trying to read a text file? Is it tab delimited? What are the datatypes stored in the file? Do you have code you are using to read the file and could you share it with us? Does the problems occur only with files over 1GB or also with small files? Can provide a small sample file that reproduces the problem?

When masscompiling a folder that is under external Tortoise SVN source code control, LabVIEW incorrectly masscompiles also subversion internal files by interpreting them as LabVIEW files. Tortoise SVN creates .svn folders to under each source code controlled folder. The .svn folder contains only Tortoise SVN internal files. Under .svn folder Tortoise SVN also stores unchanged versions of the files in the source code controlled folder. These files are stored in format Filename.ext.svn-base. For example Main.vi would be stored under .svn folder with name Main.vi.svn-base. LabVIEW masscompile tries to masscompile these files even when the file extension .svn-base clearly indicates that these are NOT LabVIEW files. Thes meshes up with Tortoise SVN bookeeping and as a result masscompile cannot be used for a project that is under source code control. STEPS TO REPRODUCE - Install Tortoise SVN from http://tortoisesvn.tigris.org/ - Reboot - Create a local source code control repository by right-clicking on an empty repository folder (C:\repository) and selecting Tortoise SVN -> Create repository here from the context menu - Import any LabVIEW project to the newly created local repository by right-clicking on the project folder and selecting Tortoise SVN -> Import - Check out the imported project from the local subversion repository to a new empty project folder by right clicking on empty project folder in Windows explorer and selecting SVN Checkout from context menu - Tortoise SVN creates hidden .svn files in each sub folder of the newly created project folder - Use LabVIEW to masscompile the above new project folder - LabVIEW masscompiles SVN internal files

Have you tried opening all main level VIs and then pressing ctrl+shift+run on one of them. This forces LV to recompile and the bug may disappear... I've had similar situation a few times and recompiling has helped.

QUOTE(Christina Rogers @ Aug 9 2007, 04:32 PM) Any particular reason not to use YouTube? Tomi

QUOTE(Darren @ Aug 8 2007, 06:24 PM) Actually I'm not sure the bug is limited to these cases only. For now all the examples of the bug found have required a subVI border but I'm not sure if that is always the case with this particular bug. I think it would be better to let NI R&D to investigate what actually happens behind the scenes before writing a VI analyzer for the bug.

I was thinking how bad this bug actually is. I found a very common use case of passing data to dialog windows where this bug can cause a lot of harm. When a main VI calls a subVI that is used to display data it's common to use value property nodes within the subVI. However using value property node may cause severe troubles as this bug modifies data in constants and wire buffers elsewhere in the calling VI. See the images below for this use case. http://forums.lavag.org/index.php?act=attach&type=post&id=6559 Main VI passes data for subVI to be visualized http://forums.lavag.org/index.php?act=attach&type=post&id=6560 SubVI uses value property node to modify the displayed data http://forums.lavag.org/index.php?act=attach&type=post&id=6562 Main VI after execution, moving mouse over the constant displays the changed constant value http://forums.lavag.org/index.php?act=attach&type=post&id=6561 Download the example project for LabVIEW 8.0

QUOTE(silmaril @ Aug 7 2007, 12:37 PM) Actually ImageMagick is not GPL. It's some proprietary license that may be compatible with GPL meaning that ImageMagick can be used in a GPLed project. However it's not a GPL license and hence you may not need to GPL your project at all. If ImageMagick would be of GPL license, then you would need to GPL all derivative work which in this case would mean your library.

QUOTE(Ben @ Aug 6 2007, 07:51 PM) Is it always the rookie that files all the bug reports?

QUOTE(Ben @ Aug 6 2007, 07:46 PM) I was just about to file a report bu you do that After all you are a champion and have more direct channels...

I was able to reproduce the bug in LV 8.2.1 and LV 8.5. I guess this issue is related to the LabVIEW in-placeness algorithm. Would you please report this bug to NI if you have not already done so. What happens is that LabVIEW decides not to make a buffer copy for the subVI as it incorrectly thinks that the buffer is not modified by the subVI. However the buffer is modified by the subVI by calling a property node for an indicator. As a buffer copy is not made, the call to the property node actually modifies the original buffer. This results the buffer to become empty after the subVI call. I changed the property node for local variable and the bug disappeared. Replacing the local variable with property node reproduced the bug once again. The bug appeared for both value and value (signalling) properties. I found even stranger issue. The buffer modifications "backpropagate" to a constant on block diagram. See the attached project (for LV 8.5). To reproduce, open block diagram of main.vi. Take a look at the constant there. Then run the VI. Hide the block diagram and show it again by pressin Ctrl+E twice. The constant value has been modified. http://forums.lavag.org/index.php?act=attach&type=post&id=6547 main before execution http://forums.lavag.org/index.php?act=attach&type=post&id=6548 main after execution http://forums.lavag.org/index.php?act=attach&type=post&id=6549 subVI http://forums.lavag.org/index.php?act=attach&type=post&id=6546 Tomi

QUOTE(yen @ Aug 5 2007, 07:45 AM) What wouldn't one do to get to Texas

QUOTE(Jim Kring @ Aug 4 2007, 10:58 PM) I guess I would do the same thing with a hex editor.

QUOTE(David_A_Moore @ Aug 4 2007, 01:11 AM) I'm not sure the meaning of term freeware is legally clear. EDIT: My intention is by no means criticize your work nor your license terms. The sole purpose is to express that I'm afraid that unclear terms may actually limit the usage which may not be your intention. Using something like BSD license is clearer to the users and you don't need to consult the lawyer to come up with such.

QUOTE(David_A_Moore @ Aug 4 2007, 12:44 AM) Actually not having a license means that the the code is copyrighted by the authors and the authors have full rights to the stuff unless otherwise stated. Copying or using is not permitted without permission by the authors. A license loosens these legal conditions to allow other parties extended rights to the software. I didn't take a look if you actually have some sort of license or not. If you don't I would strongly recommend you to come up with some sort of license so that it's clear what the rights of the users are. You can give full rights away but you must explicitly state that in format that is legally binding.

QUOTE(Aristos Queue @ Aug 3 2007, 11:29 PM) Oh, this is almost like a http://en.wikipedia.org/wiki/Socratic_method' target="_blank">Socratic dialogue... This is definitely the single best new feature in LabVIEW since the introduction of LabVIEW classes in LV 8.20 and actually making them work in LV 8.2.1

It seems it's official now. I posted a blog post to list the most important new features in LabVIEW 8.5.

Ooops... QUOTE(LV Punk @ Aug 3 2007, 04:19 PM) How would you know they are going to release such a product at NI Week

QUOTE(dsaunders @ Aug 2 2007, 06:57 PM) You've lived in Finland! May I be curious where?

QUOTE(dsaunders @ Aug 2 2007, 06:19 PM) Wow. Not bad, but actually it should be "Hyvää päivää". Tomi

This short documentary clip tells the story of the most skilled traditional hunters in Finland (Suomi in Finnish), the country where I live... <center><object width="425" height="350"><param name="movie" value="http://bubblare.fi/v/suomi/"></param><embed src="http://bubblare.fi/v/suomi/" type="application/x-shockwave-flash" width="425" height="350"></embed></object></center>

QUOTE(Aristos Queue @ Aug 1 2007, 06:00 PM) I create dynamically references to reentrant VIs that use functional globals. Each reference refers to separate instance of the reentrant VI then and each instance has its own functional globals to store the state of the instance.

QUOTE(george seifert @ Jul 31 2007, 10:03 PM) Would you be so kind that you would submit a bug report to NI. This can very well be LabVIEW related issue and it's better that they have a code that can reproduce the issue so that they can investigate the issue and possibly even fix it.

QUOTE(george seifert @ Jul 31 2007, 04:22 PM) Sounds like a driver issue. Only kernel level processes can hang the whole operating system. In windows most non-windows kernel level processes are device drivers. So I presume there is an issue with one of the device drivers you either directly or indirectly use in your project. I don't know if timed loop uses some sort of kernel level process for the timing, that may very well be. Someone from NI can maybe say something about this.

In general code hangs because of race conditions or because of LabVIEW or driver bug. The race condition may happen also within external code. But as always the nobody is able to help you without the code. So unless you cannot post failing code, at least I'm incapable of helping you. Tomi