Jim Kring

Here is a page at OpenG.org which is dedicated to GOOP information: http://openg.org/tiki/tiki-index.php?page=GOOP

GOOP and Process Spawning are can be used together very nicely. For example, when spawning multiple processes (multiple instances of the same process), it is often a good idea to create a new instance of a GOOP object associated with it for managing the instance's data. Usually, I accomplish this, by doing the process spawning inside of the GOOP object's constructor. I pass the process a reference to the GOOP instance, and then the process can access the instance's data store, using that reference. I store the spawned VI's reference inside of the GOOP data store, so that a call to the GOOP destructor can kill (Abort) the spawned VI, if it can't stop it using some form of messaging.

I just read an article on DeviceForge.com called .NET dives deeper into gadgets, which discusses the .Net Embedded platform for targeting "bare metal" (no OS). This is pretty interesting since NI has shown at NI Week that LabVIEW is being targeted at smaller and smaller embedded devices and architectures, including those without an OS, such as the FPGA platform. Since Microsoft (or at least one of its partners) is moving in this direction, it seems possible that Microsoft and National Instruments might start competing head-to-head in this arena. In the desktop and server world, the OS and developer tools are tightly coupled. In the embedded hardware world the embedded hardware and developer tools could also be tightly coupled. Maybe MS will try to extend its monopoly into the embedded world, too. Just food for thought.

Michael, you must not have the latest appcontrol or file package. The code works fine on my system. Don't you have OpenG Commander installed? That bit of code was put there to ensure that the code worked, once built (and name-mangled) using the OpenG Builder. -Jim

Hmmm, it sounds like you could benefit from a networked source code control system (such as CVS or SubVersion) to keep all of your project files sync'ed. Once you get over the learning curve, this is light years better than a networked project folder. Jean-Pierre summed up most of our reasoning for putting files beneath user.lib. But, you can find a little more info on OpenG's integration strategy here: http://www.openg.org/tiki/tiki-index.php?p...grationStrategy Also, we are working on a better way to keep packages synchronized between developers/systems using a project. We are going to support a system configuration file that will detail all the package requirements of a project and easily allow you to change between configurations. Couple this, with a networked repository of packages, and getting the right OpenG packages installed will be a breeze. OpenG Commander is coming soon!

You're welcome, Mike. And, here's another interesting read, which is related to this thread: Patents - An Alternate View (notice that it is an essay from the same folks as the one you referenced)

It appears that the probes folder inherits its location from the 'LabVIEW Data' (aka "Default Data Directory") directory. So, I guess that it is a good practice for developers with more that one LabVIEW version installed to change this setting to a version specific folder, such as: *********** labview.ini *********** DefaultDataFileLocation=C:\Documents and Settings\%user%\My Documents\LabVIEW 7.1 Data ********************************

Since NI can (technically speaking, per the NISLA) tell you that any software is unauthorized, then perhaps the EULA does protect them. But a translator/importer/exporter does not directly compete against any existing NI product. However, it does opens the door for competitive products that are not written in LabVIEW. For example, if there exists an XML schema for storing VIs, along with an importer/exporter, then anyone can build an editor for files of that schema. This means that you don't need LabVIEW to edit G. You only need it as a compiler.

Who says that they haven't? http://www.jpaulmorrison.com/fbp/#JavaFBP

There is a fundamental flaw with having custom probes stored inside the "~/LabVIEW Data/Probes/" folder (for example, "My Documents\LabVIEW Data\Probes" in Windows XP). :!: All versions of LabVIEW installed on your machine share the same custom probes folder. :!: If you have both 7.0 and 7.1 installed and you accidently save your probe in 7.1, it will no longer work in 7.0. All I can hope for, is that the custom probes path is not hard-coded into LabVIEW and some secret INI key will allow us to redefine the default probes storage location. However there might be a work-around. Here are some behaviors that I noticed: * the probes folder is searched *each time* you right click on a wire and select the "Custom Probe" submenu. * the probes folder is searched recursively, including all searchable subfolders * subfolders will be excluded from the search, if their name begins in an underscore ("_") character. Here is a possible solution: Create subfolders for each LabVIEW version. ~/LabVIEW Data/Probes/7.0 ~/LabVIEW Data/Probes/7.1 ~/LabVIEW Data/Probes/7.2 ~/LabVIEW Data/Probes/8.0 ~/LabVIEW Data/Probes/8.1 Create a VI that renames all subfolders for LV Version != Running LV Version. For example, if we are running LabVIEW 7.1 the VI would rename the Probes subdirectories so that they were the following: ~/LabVIEW Data/Probes/_7.0 ~/LabVIEW Data/Probes/7.1 ~/LabVIEW Data/Probes/_7.2 ~/LabVIEW Data/Probes/_8.0 ~/LabVIEW Data/Probes/_8.1 Now, only the 7.1 subfolder will be searched for custom probes. The VI may either be menu-launched (for example, from the "Tools" menu) or perhaps, registered to run automatically when LabVIEW launches (using lv_init.vi). Any other ideas or thoughts?

In your example, Michael, how come the RegEx used to strip contiguoes EOL chars is "[\r\n\r]+" ? It seems like the last "\r" is redundantly redundant.

Yes, have a happy birthday, Jean-Pierre. Have a happy new year, too!

Or insert "wrapper" VIs into the hierarchy that intercept and operate on data as it flows into and out of subVIs? Sure, you can. Heres another trick... insert keys into an app's INI file that enable VI Server TCP-IP access. Now you can open a remote application reference to the app and peek/poke into the control/indicator data of its VIs (those that have FP's).

Since VI files contain executable code which may be run using the LabVIEW Run-Time Engine, they are themselves "applications". This means that NI could say that your VI files are not authorized to be distributed for use with the LabVIEW Run-Time engine. This is one good reason why we need to be able to distribute VI source code seperately from the bytecode.

Write a TRUE value to the Wire's Breakpoint property.

Mike, Don't hold your breath waiting for a public release of scripting. There are several reasons that I think it will not be "productized" anytime soon. Here are a few... It is not a feature that will be useful for beginning LabVIEW users (thus increasing the number of LabVIEW copies sold to NI's target audience). There aren't many advanced LabVIEW users that will be willing to pay NI, what NI thinks it is worth (and costs to support). And finally, it opens a whole can of worms with respect to the fact that LabVIEW is a closed/proprietary environment -- scripting means that people can build import/export/translator tools for moving G (source code) outside of LabVIEW and therefore NI's control. As we've seen with the developments in NI's licensing policy, the lock-down is getting tighter. Now, that doesn't mean that NI won't continue to evolve scripting and use it as an in-house tool for making LabVIEW more powerful... :2cents:

I, too, noticed is that it looks like a very mature and well thought out software product. It has major backing by IBM (the creator of Eclipse), CollabNet (driving force behind Tigris.org, home of SubVersion and TortoiseSVN) and hopefully Sun Microsystem. It really seams like it has a solid foundation as THE open source IDE. What I think would be useful for OpenG to start doing, is to use the Eclipse IDE as the project-level environment for invoking the OpenG Builder, OpenG Package Builder, LabVIEW App Builder, and any other functionality needed by OpenG developers during the build/test/release process. Eclipse has good support for integrating external (command-line) applications into the build process. It would be fairly easy to build executables that allowed access to OpenG Builder and other functionality. What we probably won't be able to do (w/o a great deal of help from NI), is to integrate the LabVIEW environment into Eclipse. Eclipse has an API for integrating breakpoints and other debugging tools directly into the target environment. This would be tough to integrate with LabVIEW. By starting to use a "real" software IDE, I think that those OpenG Developers without experience developing in a traditional programming language/IDE will gain a lot of useful exposure to the types of tools and methodologies used for software engineering. This insight will go a long way for helping us define our direction in the context of G as a general purpose programing language. Also, I am looking forward to doing some exploration into Java and how the Eclipse plug-in/extension framework is architected. This research will go a long way for OpenG projects that wish to provide plug-in capabilities.

Has anyone looked at Eclipse? http://eclipse.org/ It is an cross-platform (written in Java) open source IDE for just about any type of project. According to their website... "Eclipse is a kind of universal tool platform - an open extensible IDE for anything and nothing in particular." I downloaded it and took it for a test drive. It is very slick, and has so many features and so much flexibility that it might be daunting for new users (it was for me). It has built-in CVS capabilities, which is useful Source Code Control integration. It is very extensible, but the plug-in API's are all Java. If nothing else, this platform could serve as a very useful example for implementing something similar in G. I think that it is worth some time investigating.

If you like that, then check out this: http://www.heavy.com/index.php?channel=contagious Heavy.com has some funny stuff, along the same lines. I think that I even saw the "Master Card" one there.

My comment was meant to rattle your cage -- it obviously worked. So, you can take it as a personal assault, but hopefully you will take it as an insight. Whether or not you need to take a class for credits, doesn't mean that you can violate the code of academic ethics by asking people to help you cheat. There is an epidemic of cheating on college campuses these days, and it is sad to see an opportunity to learn, wasted. I used to teach a college LabVIEW class, and had to drop/flunk cheaters out of my class -- it's not fun for anyone. Additionally, you've got a bit to learn about participation in a volunteer support and discussion forum. Here's a reading assignment (yes, there will be a quiz): How To Ask Questions The Smart Way >> Don't post homework questions

About a year ago, on November 25th of 2003, I posted a message (see quote, below) to Info-LabVIEW about how changes to the NI Software License Agreement (NISLA) affect LabVIEW software developers. The verbiage of the current NISLA gives NI the right to declare a software product as being not an "authorized application" if it competes with an NI product. Prior to that, it only prohibited using LabVIEW to create "general purpose tools that permit the development of applications to acquire, display, or analyze data."

And, he's been sending people personal emails asking them to do his homework

Your wasting your time in school. You should be looking for job that pays a huge salary to do nothing.

Michael Aivaliotis gave the presentation. Send him a request.

Purchase LV Application Builder: http://sine.ni.com/apps/we/nioc.vp?cid=10731〈=US More info about the LV Application Builder: http://www.ni.com/support/labview/toolkits...ild/default.htm