Jim Kring

QUOTE ("http://www.boingboing.net/2004/07/27/elizabot-passes-sexc.html") AQ wrote: > Does emulating God suffice to pass the Turing Test? Makes me wonder... does emulating a schizophrenic person who thinks they are god suffice to pass the Turing Test?

QUOTE (Norm Kirchner @ Dec 8 2008, 12:54 PM) It would appear that your http://www.wikisummaries.org/Built_to_Last#Chapter_6_.E2.80.93_Cult-like_Cultures' rel='nofollow' target="_blank">assimilation into the NI corporate culture is nearing completion :laugh: Cheers, -Jim

QUOTE (brianafischer @ Dec 5 2008, 11:03 AM) If you aren't able to see it, it's probably http://forums.lavag.org/VI-Scripting-Readme-First-t1207.html' target="_blank">scripting (a.k.a. a private VI Server feature).

Correction ==> CAR # 111447

QUOTE (Phillip Brooks @ Dec 2 2008, 10:07 AM) The relative path of "::" on Mac is equivalent to ".." (parent directory) on Windows and Linux. I tested opening the vi (Test File Patterns.vi) on LabVIEW 8.2.1, 8.5.1 and 8.6 in Windows and it works fine for me: http://lavag.org/old_files/monthly_12_2008/post-17-1228245191.png' target="_blank">

QUOTE (crelf @ Dec 1 2008, 02:21 PM) Thanks everyone! You all make it a pleasure to be a part of and serve our great LabVIEW community

Confirmed by NI and CAR # assigned. [CAR 818352] Status: Fix planned for next major LabVIEW release (post 8.6 ==> 8.7 or 9.0?)

QUOTE (Tomi Maila @ Nov 29 2008, 03:24 PM) Hi Tomi, Thanks for the suggestion. I guess a work around might be to create our own native file dialog using Carbon Framework API calls. -Jim

[cross posted to ni.com] The file dialog allows specifying multiple types (that can be selected by the user) by passing the dialog primitive a semicolon delimited list of patterns. For example, you can allow the user to choose TXT or INI file types by passing a pattern of "*.txt;*.ini" to the file dialog primitive, as shown below: However, when this is run on Mac OS X, neither of the specified file types is selectable by the user, as shown below: I have tested this on LabVIEW 8.2 and 8.6 for Mac -- both have the same problem. Here is an example that can be used to test the bug: Download File:post-17-1227995063.zip The help documentation for the File Dialog primitive states that this should work on all platforms -- there is no exception for Mac: QUOTE Does anyone know a work-around or if I'm doing something wrong?

QUOTE (Justin Goeres @ Nov 26 2008, 02:43 PM) Does the EXE have a benign argument/mode such as /?, /help, /version, etc. that just shows the help or version information?

I heard that Norm was offered the deal, due to his NIWeek keynote dancing (DDR) skills.

QUOTE (Dean Mills @ Nov 21 2008, 04:32 PM) Same with the classic (compatibility) queue VIs.

QUOTE (Neville D @ Nov 21 2008, 03:07 PM) Or, how about native semaphores that can also store a single data element and that allow us to specify inheritance of the semaphore reference type

Omar, Thanks for sharing your story with us. This is certainly one of those "Why did LabVIEW let me make this mistake?" scenarios, and every LabVIEW user will eventually make this mistake a dozen times over the course of a long career. It should also be noted that this affects any of the non-native by-reference "objects", such as: (classic) notifiers, semaphores, rendezvous, configuration files, (classic) queues, etc.

QUOTE (BrokenArrow @ Nov 19 2008, 06:10 AM) No worries I hope you enjoy the 3rd edition. Feel free to bring it to NIWeek and I'll happily sign it -- but that might make it worth less on eBay than the coffee and beer stains Cheers, -Jim

QUOTE (jlokanis @ Nov 18 2008, 11:45 AM) Great point -- yes, there is a race condition that could cause the destroy to happen before the bottom modification occurs. I originally (when I created the example) had something like the one, below, but I removed the error handling to emphasize the use of semaphores. You're right that (short of using error chaining) wiring the bottom semaphore reference to the destructor's sequence structure (as shown below) is a good fix. QUOTE (jlokanis @ Nov 18 2008, 11:45 AM) Also, the use of sequence frames and semaphores could be eliminated by instead protecting the data in a single element queue instead. This is a cleaner way to solve the problem and better coding practice, but would not demonstrate the use of the semaphone. Yes, you could definitely use a single element queue. You could also use a functional global variable. Along those lines, Appendix D of LabVIEW for Everyone (where I pulled this example from) provides a historical overview of the different mechanisms for doing by (non-native) object-oriented programming in LabVIEW (and shows the natural progression of technologies and features). However, it does not touch the single-element queue or other more advanced implementations of by reference objects. Thanks, -Jim

QUOTE (BrokenArrow @ Nov 17 2008, 12:14 PM) When did this turn into a negotiation? QUOTE (ragglefrock @ Nov 17 2008, 02:43 PM) I'll do it for $52 When did this turn into a bidding war?

Please try again -- it's now available for download from within VIPM. There can be a delay between when OpenG libraries are released and when the package becomes available in VIPM.

QUOTE (BrokenArrow @ Nov 17 2008, 11:03 AM) You're welcome. Now, just imagine all the other good stuff in http://labviewforeveryone.com' rel='nofollow' target="_blank">LabVIEW for Everyone

QUOTE (jdunham @ Nov 17 2008, 10:28 AM) Yes, and this is the exact example used in LabVIEW for Everyone >> Semaphored Data Store (pages 912-917). Here are some screenshots of the example VIs from that chapter. Race Condition (Buggy Code) No Race Condition (Good Code) -Jim

QUOTE (Val Brown @ Nov 17 2008, 10:13 AM) Yes, especially since the "Not A Refnum" function does not handle Semaphores (or "classic", non-native Queues and Notifiers).

QUOTE (BrokenArrow @ Nov 16 2008, 10:53 AM) Semaphores are ideal for enforcing mutually exclusive access (i.e. locking and unlocking) to a shared resource (global data store, communication pipes/sessions, instruments, etc.). For one great example, see: "LabVIEW for Everyone", 3rd edition >> Appendix D, "LabVIEW Object-Oriented Programming" >> Semaphored Data Store (pages 912-917) Semaphores are rarely used, casually, in LabVIEW programming. However, they are extremely useful in certain situations.

QUOTE (hooovahh @ Nov 7 2008, 07:32 AM) It's worth noting that the Palette API ships as part of vi.lib in 8.6, which might be why the code was removed from NI's website (which I haven't confirmed).

I am using "vi.lib\AppBuilder\BuildTargetBuildSpecification.vi" to build a Build Specification in my LabVIEW Project, programmatically. The build takes a while and I would like to get status information while the build is happening, just like the progress/status dialog shows when you run the Build Specification from within the Project Environment. I have not found any way to get the status information. I did find a global variable, "ABAPI Dist Build Status.glb.vi", that looks promising. However, it probably only has status information in the Application Context in which the builder is running. I'm wondering what the name of this application context is, so that I can try to obtain the status information. Any ideas?

QUOTE (Daklu @ Oct 28 2008, 09:54 PM) Why not start with just 1 VIPM license? This will allow you (or another member of your team in a reuse librarian mode) to build VI Packages that everyone on your team can install with the free VIPM Community Edition. This could also serve as a way to demonstrate to your team the time (i.e. money) savings that is possible using VIPM to more effectively and efficiently reuse code. QUOTE (TobyD @ Oct 29 2008, 12:26 PM) The idea is that you only need one license to build packages. Then anyone who want to use the packages downloads the free version and installs them. You can tell your manager you're getting 10+ licenses because he/she doesn't know that everyone else is getting the free version :ninja: Oops, I missed this post. I agree completely