Towards LabVIEW and GCC, or not? Introduction to the eSym Project

Considering the availability of LVH LINX -- originally, LIFA -- as an extension module available for programming Arduino and other microcontroller boards from the National Instruments LabVIEW platform, my first thought is to wonder what defines the toolchain in LIFA.

Comparatively, the NI LabVIEW Embedded Module for ARM Microcontrollers extension (footnote: device support) uses the commercially licensed Kiel uVision compiler. Personally, as a student of DeVry University Online, I've received a one year license for uVision, complimentary with the LabVIEW 2010 and LabVIEW for ARM bundle that we're using for some very simple device programming projects, in a few of the courses. That license will expire in roughly one year's time. If I will begin programming for embedded platforms with LabVIEW, I would like to be sure that there would be some longevity to the toolkit I would be using.

I wonder, Does LINX use GCC, alternately?

In a rough summary of procedures with the LabVIEW programming kit for ARM: When a LabVIEW project is compiled with that kit, clearly LabVIEW performs a translation into C code, then compiles that to machine code, then programs the device with the resulting application. Certainly, the similar could be done with GCC and other free/open source software (FOSS) tools.

Concerning the hypothetical GCC-based procedure for application building and device programming, the "FOSS alternative" could simply apply GNU Make, or even  Gradle, all within a conventional FOSS toolchain. The same toolchain could use uClibc as an alternative to GNU LibC, perhaps minimizing the space requirements for applications compiled with the toolchain. Insofar as that much of the toolchain, itself, would be comprised of free/open source software components -- those, all compatible with the Debian Free Software Guidelines (DFSG) -- it might serve to provide something of an available platform for programming with LabVIEW. Of course, LabVIEW itself  is a commercially licensed product.

What would be the incentive for developing a free/open source data flow programming language, alternately? Without making a "too lengthy" dissertation in this article, the hypothetical FOSS data flow programming language could serve to provide a convenient, desktop interface for data-oriented programming -- in that much, perhaps very similar to LabVIEW -- without the commercial overhead of a commercially licensed product such as LabVIEW.

Would it be enough: Simply to climb the mountain because it is there?

What additional features could be provided in a data flow programming language and toolchain licensed as FOSS -- beside any features implicitly available of a software product produced with a FOSS licensing model, such as instant availability and low commercial overhead? Some thoughts, to matters that may be relatively simple to set as goals, at least:

• If the hypothetical data flow programming toolchain would be developed on a platform supporting ARM microcontrollers as well as Intel microcontrollers, and if that platform would be functionally applicable in a Linux operating system, then -- in short terms -- it could as easily be ported to the Android platform.
• If a data flow programming language -- as a feature of the hypothetical data flow programming toolchain -- could be implemented with a corresponding metamodel onto the Metaobject Framework (MOF), then a corresponding model transformation framework could be developed. The model transformation framework could implement QVT, as for a purpose of transforming a program model -- such that would be developed in the same data flow programming language -- into a program model in any single language supported with the corresponding QVT transform. 
• If the data flow programming model would be implemented with a binding onto Common Lisp:
• A corresponding visual model could be implemented with CLIM, for visual representation of elements in the data flow programming model
• Insofar as that the data flow programming model may be implemented towards a deterministic timing, for programs as would be produced in any single compiler toolchain, it would serve to provide an opportunity for developing a number of ideal "Use case" scenarios, towards models for deterministic timing in developing Common Lisp software programs for realtime systems.
• In utilizing the Common Lisp Object System (CLOS), the Common Lisp binding for the data flow programming model could be developed as not only to extend CLIM, but also -- in another facet -- as to extend a hypothetical implementation of MOF in Common Lisp, in implementing the corresponding program metamodel
• If the data flow programming model would be implemented consistently as an expression of the hypothetical data flow programming metamodel, then any programs developed in that programming model could be easily serialized for storage, using the XMI binding for MOF.
• If accompanied with a corresponding QVT implementation -- viz a viz QVTo --  any model developed under the programming metamodel, ideally, could be transformed into any single target platform programming language, so long as a QVT transform would be implemented for the latter.
• With sufficient application of magic beans, it could even become a glorious beanstalk.

Sometime around when the author of this article was first beginning an acquaintance with LabVIEW, the eSym project was created. The main driving intention in the eSym project was to develop a data flow programming model in Common Lisp. 

At this time, the codebase for the eSym project is in no normative state. The project has been stalled around some orthogonal design issues, such as for developing a modal locking model for thread-safe slot value access onto the Common :Lisp Object System --- most likely, as to apply cl-async via green-threads, in an extension onto the Common Lisp Metaobject Protocol (MOP), Furthermore, the author's own attention has been directed towards the possibility of developing a Common Lisp programming framework onto the Android platform -- such that may need a substantial integration between Android Studio and/or the Android Developer Tools (ADT) and any single Common Lisp implementation supported on the ARM platform, viz a viz SBCL and CCL, in Common Lisp implementations compiling to machine code, as well as ABCL, which compiles to Java bytecode and might therefore integrate more easily with the Android programming environment, overall.

The prospective "Common Lisp on Android" project would represent a subsantial divergence, orthogonal to further development of the eSym source tree. 

Another Semester Ensued - Article Follows: Modularization, set theory, and SysML (rev. 1.0)

As the author being a student of a program in electrical sciences and information systems, at a certain online university, part of the author's attendance to the same university is represented by way of the author's own discussion forum responses. In those courses presenting of topics that the author may consider to be somehow relevant to the author's own informal academic studies, the author may wish write at length, to develop any single thesis in a response to the forum items. When time allows, then the result is -- typically -- something like a short, informal thesis paper -- often, towards a thesis in some ways orthogonal to the the content of the original discussion forum item, though addressing the discussion forum item to any single point of orthogonal relation.

This year marks what will have been the last year of the author attending that same institution -- the author planning on continuing from the simple associates program, into a broader study of mathematics. The author does not wish to denote the present institution, in any too short regards, if it may seem to invite any sense of competition from readers.

The following article, in is present edition, is a transcription of the author's own response to a discussion forum item. Though it would be perhaps overmuch, to develop a complete thesis article in that discussion forum, but perhaps this article may be revised at some later time, to be expanded into a full thesis document. The topic was, essentially: Modular design.


A modular approach to systems design may allow for a sort of functional definition of the functionality of reusable, individual systems elements and the interactions of individual systems elements in any constructed system. Perhaps it may be said to be a concept extending of some fundamental principles of object oriented software design -- such as of encapsulation and reusability. In some further abstraction, perhaps a concept of modularization may be said to extend of some concepts defined in broader mathematical set theory, such as with regards to sets defined of properties of sets -- in a sense, functional sets, though I'm afraid that my terminology as such might not be conventional within the broader mathematics.

Perhaps in a broad sense, the model driven architecture described by the Object Management Group (OMG)[1] may be considered to represent something of a development of a practical, normative medium for developing a modularized view of a complex system. Considering a feature developed of the model driven architecture, SysML -- technically, as SysML being defined from a metamodel implementing the Metaobject Framework (MOF), as also published by the OMG -- practically, SysML develops a number of generic concepts for developing a modular view of any discrete system[2] SysML is used specifically in some applications in the automotive industry[3].

Hypothetically, SysML may be applied for modeling of any discrete system -- even so simple a system as of a conventional household appliance, such as a simple toaster for bread.  For a design of a system involving many of discrete components, however, a modeling language such as SysML may serve to develop a medium for definitions of the components of the system, in regards to component functionality, functional interactions between components, and applications of components within their intended usage environments.

Certainly, considering the complexity and nuances of definitions in SysML -- for instance, as with regards to types of elements that may be applied within any of the various types of model diagram in a SysML model, and applications of SysML models within any form of practice, and the extensibility of SysML  as via UML prototypes -- SysML also inheriting some features of the Unified Modeling Language (UML) another metamodel extending of MOF -- perhaps SysML may seem to be overly complex for small applications in systems design.

Perhaps, orthogonal to a concept of modular design -- namely, in regards to vendor communications and systems conformance -- SysML serves to establish a common diagram language -- perhaps, as an alternative to ad hoc flowcharts in systems design. Semantically, SysML serves to establish a sort of common semantics for modular views of systems.

Hypothetically, even a single, functional VI -- such as would be defined, functionally, in LabView's G data flow language -- a VI could be modeled semantically, in a SysML block diagram. In a short estimation: a VI in LabVIEW may be modeled in SysML with a 'block' element, then defining a SysML 'port' element to the same block, for each input and output defined in the VI.   Semantically, if a number of VI 'block' diagrams were defined, they could then be illustrated -- in any level of abstraction -- illustrated for those VI's interactions within a LabVIEW G program.

For a complex system of VIs and external devices communicating with LabVIEW as via a PXI interface[4],  perhaps a SysML diagram could serve to provide something of a simplified view of the functionality of the system of VIs, devices, and other physical systems elements.

Hypothetically, if there may be any practical benefits assumed of a development of a SysML diagram for a system applying LabVIEW: Such a development might serve to assist in applications of the system, and in maintenance of its design -- thus highlighting a few more benefits of modular design, as ideally towards addressing concerns of interoperability and maintainability,as directly with regards to discrete system A, indirectly with regards to the original design of the system A.


Works Referenced:
[1] OMG. MDA Guide. PDF edition
[2] Friedenthal, Sanford et al.  OMG Systems Modeling Language (OMG SysML™)Tutorial . PDF edition
[3] Weilkins, Tim. Systems Engineering with SysML/UML. Morgan Kauffmann OMG Press. 2007. Kindle edition
[4] National Instruments. PXI Platform. Web page.

---

End Note: This article corresponds, indirectly, to the author's own informal studies -- broadly, with regards to data flow programming language design, more specifically towards a design of a graphical data flow semantics for Common Lisp, such that the author is endeavoring to develop in the design of a project named eSym. Of course, if copyright pirates begin to circle, it could be easily enough renamed to something more appropriate.

Insomuch as of that study, the author observes -- albeit, broadly -- that there is some of a crossover towards concepts perhaps represented in designs of Common Lisp compilers. There are, of course, also some more challenging features to the matter -- such as for how to define a block-level view of a function returning a variadic set of return values.* In an interactive diagram, that could be easily enough resolved, but what of in a static diagram, such as for an item of documentation? Perhaps that can be easily resolved, too -- one could define an "&REST" return-value port as in extending SysML's port type firstly with a concept of a "return value", supplemental to an extension of the SysML block type with a concept, "function" and as such, specifically for how such a concept is developed in Common Lisp.

 Then there's the question: How to determine what values a function returns, and determine that in a portable manner? If nothing else -- towards an interface for such reflection in Common Lisp -- perhaps it may be developed in an implementation-specific manner, firstly, focusing on how function objects are implemented in any single open-source Common Lisp platform, then the design of it gradually revised for portability onto other Common Lisp platforms. In a real sense: This would not be so simple, if at all possible, without free/open source software licensing.

Sure, too: Perhaps most programming languages don't allow for returning multiple return values, as Common Lisp allows for --  as in a manner essentially orthogonal to the syntax of the list, insofar as functional return values, but also allowing for transformation of return values into a list of return values, if need be -- as may need not always be, considering the availability of the Common Lisp 'multiple-value-bind' macro, but certainly there are applications for a transformation of a multiple return value set into a formal list of return values -- albeit, that requiring some operations on CONS type objects, i.e."Consing".

* Semantically, the term variadic might be more often applied in regards to functional parameters, and not return values. In Common Lisp, the term variadic may also be applied to functional return values -- though perhaps it would not be an instantaneously accepted application of that term, as such.

Semantics - there are books about that, certainly.