LV Development Environment App’s in a Global VI Namespace

1. LV Development Environment App’sin a Global VI Namespace As Presented by Jim Kring March 4, 2003

2. Presentation Outline • Development Environment Applications (DEAs) • Namespace Issues • Name Mangling • Building Dev. Env. App’s • Dev. Env. App API • Building a Builder OpenG User Group Meeting

3. Development Environment App’s • Development Environment Application (DEA) • an application written in LabVIEW which is designed to run in the LabVIEW Development Environment • commonly used for helping with editing tasks, reuse-tools management, project source code management, application builds, scripting, etc. OpenG User Group Meeting

4. Examples of DEA’s • App Builder • LLB Editor • VI Profiler • others… OpenG User Group Meeting

5. Side Note on DEA’s • almost always installed beneath the <labview>/ directory • usually beneath the <labview>/project/ directory • the project directory is used to populate the Tools pull-down menu and launch a DEA, when selected. • Visit http://openg.org/docs/ for an article called “Customizing the LabVIEW Development Environment”. it includes more info on the project folder and the Tools menu. OpenG User Group Meeting

6. DEA Patterns of Use • Use VI Server and file I/O operations to • move, rename, delete, and copy VIs • build executables • perform limited editing tasks • LabVIEW scripting and editing extensions written in G on the horizon • However, there are unique problems encountered along the way… OpenG User Group Meeting

7. Namespace Issues • LabVIEW’s Global VI Namespace • No two VIs in memory can have the same name! • DEA’s have VIs that occupy the global namespace. • DEA’s interact with other VIs and Hierarchies • The implications of LabVIEW’s global VI namespace must be considered during these interactions. OpenG User Group Meeting

8. DEA Rules for VI Names A development tool, when running should not have in its hierarchy, a VI which is… • loaded from a reuse library such as vi.lib, user.lib, or OpenG.lib • named the same as a VI that may potentially be in a project under development • named the same as a VI within another development environment application To understand the reasons for these req’s let’s take look at a few LabVIEW facts… NO NO NO OpenG User Group Meeting

9. Fact 1- SubVIs in Memory Are Used 1st • When a VI is loaded, the very first place it looks for its subVIs is in memory (the global VI namespace) • If it one is found it links to it, otherwise it looks in the location were the subVI was on disk the last time the loading VI was saved • If the caller is saved, this new link will also be saved OpenG User Group Meeting

10. Fact 2 - “Save As…” Affects Callers • When a VI in memory is renamed by saving it to a new location, possibly with a new name, all VIs in memory that call the renamed VI will be relinked to it in its new location. • If the calling VIs are subsequently saved, this link will also be saved. • If the calling VIs are not saved before they are closed, they will remain linked to the original VI the next time they are loaded. OpenG User Group Meeting

11. Implications of These Two Facts • the namespaces of development environment tools cannot overlap the namespaces of… • reuse libraries • project VIs • other development environment tools OpenG User Group Meeting

12. Examples of Problems • If a development environment tool has Reuse-Library VIs in its hierarchy and tries to build an application from a project, it could attempt to move or rename a Reuse-Library VI in its own hierarchy. • Another likely scenario would be that a project could become linked to a VI in the development environment tool because it loaded a subVI from memory (in the DEA, instead of from its own project source tree). OpenG User Group Meeting

13. Exploiting SubVI Linkage Rules • By loading, renaming (while in memory), saving, and unloading of VIs we can relink and move VIs and branches of hierarchies. • By renaming (on disk, not while in memory), loading, and saving we can fool a hierarchy into calling new VIs. • See Wrapper VIs section of OpenG App Builder manual: http://ogab.sourceforge.net OpenG User Group Meeting

14. The “Golden Rule” for DEA’s “No application should ever attempt to operate on (edit) any VI within a hierarchy that overlaps its own hierarchy.” This is a very simple rule and it seems easy enough to obey, but we will quickly notice that we would violate it in several instances if we include VIs from Reuse-Libraries inside of our Development Environment Applications, unless we had our own copy of the R-L VIs and renamed them. OpenG User Group Meeting

15. Name Mangling • Mangling and Unmangling Names • Name Mangling during an App Build • Post-Build Name Mangling Considerations OpenG User Group Meeting

16. Mangling a Name • Name Mangling “The process of altering a name according to some know algorithm.” “MyVI.vi” + “MyProject”  “MyVI__MyProject.vi” OpenG User Group Meeting

17. Unmangling a Name • Name Unmangling “the process restoring a name from a mangled name by reversing the name mangling algorithm” “MyVI__MyProject.vi”  “MyVI.vi” + “MyProject” OpenG User Group Meeting

18. Mangling During an App Build • During the process of building a Development Application, we can mangle the names of any or all of the VIs within the application as they are copied to the build location. • The entire application may be given a unique namespace (suffix) so that when the application is running, there is very little chance that it will come in contact with a VI named the same as a VI in the application’s hierarchy. OpenG User Group Meeting

19. Mangling During an App Build OpenG User Group Meeting

20. Name Mangling, Post-Build • The VIs in a “mangled” application are different than when under development. • It is often desirable to call VIs dynamically • When we know the names of the VIs we wish to call at edit-time, it is common to use absolute or relative path constants to open references to them. How can we solve this problem of depending on the names of VIs at Run-Time? OpenG User Group Meeting

21. The Solution - Run-Time Mangling The solution to this problem, is to use the name mangling/unmangling tools to both determine the applications namespace, and use that namespace to mangle VI names at run-time before attempting to use them. Let’s look at how to do this in an example of opening a reference to a dynamically-called VI… OpenG User Group Meeting

22. The Solution - Run-Time Mangling OpenG User Group Meeting

23. Current VIs Namespace “Current VIs Namespace.vi” gets the calling VI's name, attempts to unmangle it, and returns the VI's namespace from "UnMangle VI Name.vi". OpenG User Group Meeting

24. Building DEA’s Moving Application Source Code to a Build location involves moving (relinking) its hierarchy to a new location on disk Similar to LabVIEW’s Save With Options…  Development Distribution OpenG User Group Meeting

25. Moving (Relinking) during a Build • There are two methods available for Moving (Relinking) a Hierarchy to a New Location on Disk • Move and Save • Move from the Bottom-Up OpenG User Group Meeting

26. Method 1 – Move and Save The “shotgun” approach to moving a hierarchy. • Save each VI in the hierarchy to the new location • Resave each VI again to make sure that the links to its callees are preserved. • No req’s on the order in which VIs are saved • Does require each VI to be saved twice. • Very little algorithmic design, but it does require more time – a lot more, in some instances. OpenG User Group Meeting

27. Move and Save (example) The “shotgun” method of moving a VI hierarchy to a new location. It’s slow, but easy. OpenG User Group Meeting

28. Method 2 – Move from the Bottom-Up The optimal way of moving (relinking) hierarchy. • VIs are moved, one at a time, starting with the VI at bottom of the hierarchy and continuing upward • Order in which VIs are saved is CRITICAL • Does NOT require each VI to be saved twice. • Complex algorithmic design, but doesn’t require as much time as Move and Save Method OpenG User Group Meeting

29. Move from the Bottom-Up… How? SubVI Linkage Fact - “A caller must be saved after renaming/moving its callee in order for the new link to be persistent in the caller.” • If we make sure to only move callers AFTER their callees are moved, then there will never be any unsaved changes in a caller caused by moving a callee. • However, this requires sorting the hierarchy… OpenG User Group Meeting

30. Sorting a Hierarchy OpenG User Group Meeting

31. Determining VI Hierarchy Level OpenG User Group Meeting

32. User Interfaces • The development environment application user interfaces should have their Front Panel titles set to whatever name the developer wishes to be used as the Tools menu item. • This also obscures the mangled VI name from the end user, as well as the Tools menu item. OpenG User Group Meeting

33. Dev Env App APIs • Once developers have installed a DEA on there development system, they will want to programmatically access its functionality. • Don’t start the design process thinking about how your user interfaces will look and act. • Do the design the API of your DEA first. If you do this, you will find that writing the user interfaces is almost trivial. OpenG User Group Meeting

34. Dev Env App API Form Factor • An API can be any sort of interface, but here we will call it a collection of VIs which are intended, by the creators of a DEA, to be directly called by your Application Source Code. • Additionally the API should be augmented by adding the API VIs to a palette and distributing them with the DEA as a complete package. OpenG User Group Meeting

35. API - Calling the DEA, by Reference • API VIs should not be statically linked to the DEA • We do not want to any installed DEA VIs in the hierarchy of an application. • If they were, they would be moved into the built application during the build process, and most likely, the application would not operate as expected. OpenG User Group Meeting

36. API - Calling the DEA with Wrappers • wrappers used for calling functional VIs within the DEA (Call-By Reference) OpenG User Group Meeting

37. Building a Builder • Chicken and Egg “You need a builder to build you builder” • Manual (or primitive utility) Name Mangling on the first build • Finally a Builder that Can Build Itself (Bootstrapping). OpenG User Group Meeting

38. Future DEAB Endeavors • Integration with the OpenG Package Installer and the OpenG Application Builder • Building at Install-Time (when you can’t distribute certain sources, and other reasons) OpenG User Group Meeting

39. Recap • Development Environment Applications (DEAs) • Namespace Issues • Name Mangling • Building Dev. Env. App’s • Dev. Env. App API • Building a Builder OpenG User Group Meeting