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. 

Names, Name Syntaxes, and Namespaces – A Survey

With apologies for the poor formatting, in the article's presentation within its style in the Blogger web service.

I've begun developing a small proof of concept, for a URI parser implementation …  in which each of the following concepts would be defined:

• Names
• Name: Identifier of an information resource, within an information service
• Application: URI – applications in URI decoding, storage, and encoding
• HTTP user agent implementation.
• URI processing and handling, in defining a Resource desktop model
• URI Schemes for practical resource reference 
• HTTP(S) URI scheme(s)
• File URI scheme
• Bibliographical URI schemes
• "info" URI
• Sompel, Han, et al. The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces [RFC4452]
• Info Scheme Registry [info-uri.info]
• See also (informative): DOI Foundation. DOI® System and Internet Identifier Specifications
• ISBN URN [RFC3187]
• ISSN URN [RFC3044]
• Application architecture, ad hoc model:
• URI query model
• Resource proxy model
• Resource presentation model
• Bibliographical reference model
• Literary publishing model
• Archival research (practical, cf. national and local libraries, historic landmarks, historic narratives)
• Application: Registration of UML named entities within a UML modeling system
• Namespaces and names in the UML metamodel 
• UML NamedElement metaclass, UML Namespace metaclass [UML Infrastructure Specification (UML 2.4.1) subclause 11.7, Namespaces Diagram]
• Application: Registration of named objects, in repository services published by a CORBA Object Request Broker
• Referencing CORBA 3.3 specification,  Part 1, Interfaces 
• CORBA IRObject interface
• Subclause 14.5.2, IRObject
• Interfaces and Containers Within a CORBA Interface Repository (IR) (CORBA 3.3)
• CORBA IR
• Subclause 14.5.4, Container
• Subclause 14.5.3, Contained
• CCM ComponentIR
• Subclause 14.6.1, ComponentIR::Container
• …
• Object Identifiers in CORBA Services
• CORBA RepositoryId Interface
• Subclause 14.7, RepositoryIds
• Formal ReposiroryId Syntaxes
• Identifier syntax: "IDL"
• RepositoryId structure, from a perspective of IDL processing 
• IDL RepositoryId prefix part
• Subclause 14.7.5.2, The Prefix Pragma
• Subclause 14.7.1, IDL Format
• IDL RepositoryId version part
• Subclause 14.7.5.3 , The Version Pragma
• Syntax: "major.minor", each an unsigned CORBA short integer
• IDL RepositoryId name part
• IDL scoped name
• Subclause 14.7.1, IDL Format
• Subclause 7.20, Names and Scoping
• Identifier syntax: "RMI"
• Subclause 14.7.2, RMI Hashed Format
• Java class name, hash code, optional version designator
• Identifier syntax: "DCE"
• Subclause 14.7.3, DCE UUID Format
• Identifier syntax: "LOCAL"
• Subclause 14.7.4, LOCAL Format
• CORBA ObjectId interface 
• CORBA Portable Object Adapter (POA)
• Specification subclause 15.3.9, POA Interface
• Subclause 15.3.9.18,  create_reference
• Subclause 15.3.9.19,  create_reference_with_id
• Specification subclause 15.2.4, Reference Creation
• Name Syntax 
• Subset: URI syntax 
• URI as meta-syntax
• One URI syntax per each URI scheme
• URI Scheme registry: IANA – Assigned URI Schemes
• Highlighting:
• The "urn" URI scheme
• The "urn" URI scheme as a meta-syntactic subset within URI meta-syntax
• Implementing URN namespace syntaxes as registered in the IANA URN namespace scheme registry
• URN namespace (scheme) registry: IANA – Assigned URN Namespaces
• Hieracrhical and "flat" name syntaxes
• Hierarchical name syntax implementation 
• e.g. An http, https, ftp, or file URI interpreted in a service context
• "Flat" name syntax implementation 
• e.g DNS URI [RFC4501]
• any URI, in a context in which the URI is interpreted as an XML namespace [XMLNames]
• Given a URI interpreted exclusively in an XML namespace context, the URI's structure is not applicably relevant for the URI's interpretation as denoting an XML namespace
• URI schema, URI syntax, URI escaping: Beyond the scope of URI interpretated as XML Namespaces
• Application Concept: Given a textual URI, O, Initialize an URI object N of Syntax A and a metaclass M, such that a N will be an object of type M, and M may be located by the syntax A, within a single names implementation 
• URI syntax provides that the schema of any absolute URI shall be denoted in the URI. The URI scheme S of URI O may therefore be determined from O, and the metaclass M located, with S applied onto a discrete index of URI scheme implementations.
• Once the metaclass M is located, then M be used to initialize an standard object N, using CL:ALLOCATE-INSTANCE
• Once the standard object N is initialized, then N may be used for method dispatching, in a manner of iteratively consuming O for initializing N. 
• The application may observe, furthermore, that Common Lisp indirect arrays may be used as to effectively initialize N without necessarily creating "new" native string objects in parsing the text string, O – thus, ostensibly minimizing system RAM usage in URI decoding,
• This methodology may serve to allow an application to dispatch methods onto N, for purpose of decoding O as A, in initializing object structural components A'1…A'n 
• e.g A'1…A'n for an HTTP URI [RFC3986]
• A'1: network host name (i.e DNS domain name or network host address)
• A'2: Network service port
• A'3: Service user name in HTTP URI
• DEPRECATED: Plaintext password in URI userinfo subset)
• A'4: URI "directory path" elements 
• i.e. URI path subset to last forward slash. 
• Represent as null if path is zero-length
• To do: Define semantics of not using NULL as a slot value type.
• Within an application of CLOS:

  (WITH-SLOT-VALUE (VALUE OBJ SL) 
       (BEHAVIOR-IF-SLOT-BOUNDP (THE* (SLOT-DEFINITION-TYPE SL) VALUE))
       (BEHAVIOR-IF-NOT-SLOT-BOUNDP OBJ))

• Compiler optimization onto slot value types
• Applicable only if a class' definition will not change throughout the Lisp host runtime session (i.e TO DO: Define MOP intransient class extension) and 
• Applicable only when a class' definition is available to the compiler, as a finalized class definition 
• May be implemented via a compiler macro, such as would be defined as to compute the slot value type of any specific slot of any finalized, intransient class, in such as may allow for further optimization by the compiler. 
• A'5: URI "file part" element 
• i.e. URI path subset following last forward slash and preceding anchor or query subsets
• A'6: URI "anchor"
• A'7: HTTP URI (HTTP GET) query elements – (OR NULL (SIMPLE-ARRAY (CONS STRING(OR STRING NULL)) * )
• Name Syntaxes and Namespaces
• Concept: A namespace as representing a container for names of a single name syntax
• Applications onto URI meta-syntax
• One name syntax per each URI scheme
• One name syntax per each each URN namespace
• One name syntax per each Info URI info scheme
• Applications onto UML, MOF, SysML
• One name syntax
• Arbitrary number of names and namespaces, within each model
• Applications onto CORBA
• RepositoryId format "IDL" as effective name syntax
• …
• Applications onto XML
• One XMLNS namespace per XML element node. Contents: Namespace prefix, URI bindings. Should be indexed on URI prefixes (element, namespace assignment) and namespace URI (namespace prefix initialization)
• Namespace equivalence : Dependent on Namespace URI content, not dependent on URI structure.
• Namespace URI may be referenced by way of namespace prefix
• Similar behavior for entity naming in RDF, OWL
• Namespace inheritance (XMLNS)
• Duration/Lifecycle: Each XML infoset's XMLNS namespace(s) may be mem-freed via scheduled GC, after the root XML document node and subnodes are no longer needed for presentation or other infoset processing, and not referenced from within any single names index.

Sharing some simple notes about Maxima

Maxima

• Formally, Maxima is a computer algebra system
• Derived after MIT Macsyma -- see also, A Brief History Of
• In a sense, An extensive mathematics platform in Common Lisp
• System Definitions
• maxima.system : Uses MK:Defsystem
• maxima.asd : Uses ASDF
• Maxima and CLOS?
• CLOS and CLIM?
• CLOS and OWL?
• OWL, RDFS+OWL inference, SWRL, and mathematical interpolation?
• CLOS and data processing tools onto ...
• the Sloan Digital Sky Survey? 
• Autonomous navigation in "Outer space"?
• FFT, signal domain transformations, Planetary Data System, and asteroids
• Three uses of CL:DEFCLASS, all in numeric.lisp
• Numerous uses of CL:DEFSTRUCT
• Some ANSI CL implementations use CLOS implementations derived from PCL
• PCL, CL:STRUCTURE-CLASS, and CL:STANDARD-CLASS
• MOP and FUNCALLABLE-STANDARD-OBJECT (sidebar)
• Maxima and "not directly Lisp"
• Maxima 'mac' and 'dem' files - see subdirs of 'share'
• Documentation?
• Maxima GUI
• TCL/Tk (?)
• Maxima and CLIM
• REPL integration and formula display: share/contrib/mcclim
• Serialization, integration with other computer algebra systems
• Maxima and MathML: share/contrib/maximaMathML

Simple notes are simple.