Introducing GRANITENET and the FELDSPAR Platform Agnostic Object System.

As the author of this article being someone who has developed a distinct sense of interest about the logic and the existing body of work in regards to concepts of operating systems design -- moreover, a sense of interest as with regards to the effects of specific design choices in operating systems design, as of design choices ultimately resulting in discrete effects with regards to operating system applications, in any single common domain of computing, including software development, and effects in regards to application system maintenance --  the author of this article, though for some time familiar with the Debian GNU/Linux operating system, the author of this article has lately become more a fan of the FreeBSD operating system. It is this author's candid opinion that FreeBSD presents a markedly less cluttered development environment than the GNU environment of GNU/Linux systems. Not as though to meanly criticize either the Free Software Foundation (FSF) or its supporters, the author of this article is aware that operating system distributions such as Debian GNU/Linux are systems that have evolved, over time, initially from relatively small-scale origins. Considering a conceptual paradigm in which GNU tools are developed as to be modular, moreover portable with other GNU tools, moreover in which the Linux kernel itself and applications of the Linux kernel have been shaped with developments in operating system standardization -- broadly, under a heading of a colloquial definition of UNIX systems, more specifically as under the headings of international standards such as the versions  of POSIX and specifications published by the Open Group and later X/Open company, moreover as with regards to standards published by the Internet Engineering Task Force (IETF) -- the author of this article is aware that it may entail no manner of a trivial work, to develop any single, working computer system out of so many individual software components and software systems standards.  Perhaps there has been a certain degree of centrally managed organization, in the development of the FreeBSD operating system -- if not, moreover, a greater degree of flexibility as with regards to distinctions of the BSD licenses, juxtaposed to the GNU Public License (GPL) or derivatives of the GPL -- such that may result in an impression -- as to the author's opinion -- that FreeBSD is a really well organized, really uncluttered operating system, moreover very easy to apply in begining software and systems development. Certainly, such an impression is aided with the availability of so many centrally managed reference documents about FreeBSD, as in regards to the FreeBSD base system and the FreeBSD kernel.

The author would not wish to abridge any introduction about FreeBSD. This article, presently, is developed not insomuch as to make an in depth study of the FreeBSD operating system, but rather to begin to develop a set of concepts that the author has found occurring to the author's own sense of consideration, during applications of the FreeBSD operating system. The author has been operating a local area network (LAN) with FreeBSD on the the LAN gateway host, on the software build host, and on the author's primary notebook laptop, on the LAN, for a small number of months. The author has begun to develop a concrete concept of the configuration of the same LAN, referring to it then as GraniteLAN. In an architectural sense, GraniteLAN may be integrated moreover with hosts configured of software defined networking (SDN) services -- there under the heading GraniteSDN -- as to develop an overall systems development network -- with the full network under the heading, GRANITENET. Presently, the author does not wish to develop any length sidebar about the architecture of the GRANITENET design, or the design philosophy of the same. It's basically a concept for a scalable DevOps network, and a small office/home office (SOHO) network, such that may be utilized not only from GRAITELAN, but moreover that may be utilized from a mobile appliance not immediately connected to but configured for connection to GRANITESDN. In its architecture, GRANITENET would apply a distinct number of common UNIX networking services, such as LDAP, NFS, NIS, Kerberos, and -- furthermore -- RADIUS.  Though it may seem relatively easy to write about, as such, but -- in order to develop a manageable framework of so many network services, as such, and for it to be relevant in regards to applications on contemporary operating system architectures -- it may not ultimately be as easy to "Glue together," in application of so many software components. At least, it may be easy to "Put together" the concept of GRANITENET's design -- initially, as it representing a manner of a paper machine, as to apply an older phrase to the  matter -- as it entailing a design of an effectively multi-homed application of the FreeBSD operating system.

In regards to the manageability of the design and applications of GRANITENET, of course there must be a manner of a design incentive thought to exist. The author might not believe that every reader would share the author's sense of appreciation about the logical design of each of Common Lisp the Language, 2nd Edition, and CORBA systems, furthermore the Object Management Group's concepts of Object Management Architecture and Model Driven Architecture -- moreover, the portability of systems developed onto CORBA and, separately, the portability of applications developed onto the Common Language Infrastruture (CLI), the latter as popularized of the Microsoft Dot-NET and the Xamarin and Mono platforms, furthermore as standardized onto ECMA-335.

Insofar as it representing a concept of a paper machine,  the author has certainly expended some paper and graphite, in putting together a number of offline notes about the design of GRANITENET, moreover the design of a system the author denotes as FELDSPAR. FELDSPAR would represent an application of Common Lisp, CORBA, and the Common Lisp Interface Manager, as to create a bundled application development kit of free/open source software for applications of the same software and systems components. In that regards, perhaps it might seem like overmuch of an aspiring goal -- as to apply GRANITENET in developing the FELDSPAR framework, while GRANITENET is not even completely constructed, in itself, as yet. However, in retaining a sense of focus about the logical qualities of the design of each of GRANITENET and the FELDSPAR framework, it therefore remains a manageable set of concepts, at least to the author's own sense of consideration.

In beginning to describe these discrete concepts to the Internet audience, it must naturally entail a development of a literal body of documentation. Thus -- in focusing about the Darwin Information Typing Architecture (DITA) -- there is a sense of a topic repository model developed in the FELDSPAR systems design, insofar as of the present paper machine edition of the FELDSPAR systems design. The topic repository model -- in some regards, semantically -- it might resemble something of a concept like of a Wiki. Though a FELDSPAR topic repository would be published to the Web, but -- in it utilizing DITA,l in its content source model -- it would not be immediately managed "on the web". The FELDSPAR Topic Repository model would allow for managing the body of content of a topic repository, as in application of so many DITA editing tools, multimedia content development tools, and changeset management tool such as Git -- without HTTP interverning between the editor and the filesystem. As such, perhaps it may not seem to be an immediately enterprise friendly framework, but perhaps it may be scalable outwards from its initial SOHO friendly design.

In beginning to document this design, in a digital format of text, the author of this article wishes to make reference -- immediately -- reference to MARTE, specifically MARTE 1.1, furthermore to make reference to the DOAP RDF schema. Surely, it may be possible to develop a great amount of semantic sugar, in application of such normative specifications. Presently, the author wishes to recommend a concept of software platform, in an abstract sense, as may be extended to subsume concepts both of operating system platform and of toolchain architecture, furthermore as to provide a sense of structure about application components commonly referred to as libraries -- then to include the DOAP RDF schema, as to develop a documentation framework with which software developers may be able to make consistent, ostensibly convenient reference to all points of upstream software distribution, for any single software component.

Towards developing an initial usage case to this sense of structure in software and systems: The author of this article has begun to write a small series of notes, in the author's own Evernote notebook, as to begin to develop some normative documentation towards an application of the Enlightenment Foundation Libraries (EFL) and the EFL WebKit integration, namely towards developing an EFL port for the Common Lisp Interface Manager (CLIM) as well as extensions for CLIM, in regards to web appliations, such that would be developed as for application at least onto FreeBSD, Linux Desktop, Android Mobile, and Microsoft Windows Desktop operating system platforms.  Perhaps it aspires as towards a comprehensive design, to be thorough in regards to development and support of operating system applications.

Though the author is furthermore interested about some concepts of microcontroller design, reprogrammable computing, and the history of the infamous Lisp Machine, but perhaps it may turn out to be a manner of a fortuitous effort, to begin with regards to applications of existing microprocessor achitectures and existing operating systems, specifically beginning at the manner of a colloquial UNIX-like framework developed of the FreeBSD Project -- furthermore, as FreeBSD being extended in a small number of by-in-large domain-special FreeBSD distributions.

So, that would be towards an unabridged introduction.

In focusing immediately towards applications of the EFL toolkit, there is immediately a concern that occurs as with regards to illustrating the toolkit's software components and software component depencencies, as towards any single distribution of the EFL toolkit -- in a sense, as towards any single distribution of a bundled set of EFL toolkit components, whether immediately with or without the EFL WebKit integration, and finally in a distribution to any single operating system platform, in application of any single toolchain architecture. This would be essentially orthogonal to -- but, in a sense, essential to -- the development of a CLIM port for EFL.

The author proposes to develop a model for each of the following concepts, in extending the MARTE 1.1 Profile for the UML metamodel:

• Concrete Computer Machine Architecture --  immediately, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• e.g. as in reference to:
• The FreeBSD sysctl property, `hw.model`
• Compiler optimizations as may be specified in FreeBSD /etc/make.conf and/or FreeBSD /etc/src.conf
• Machine architectures in Debian GNU/Linux
• Machine architectures in the GNU Compiler Collection
• Abstract Software Platform -- likewise, perhaps extending of the Detailed Resource Model defined in MARTE 1.1
• Concrete Operating System Platform
• Concrette Toolchain arhitecture
• e.g. MINGW 
• Subsumes: MINGW x86-64
• Abstract Software Application and correspondingly, Abstract Software Distribution, in a noun sense of the latter term
• Software Distribution/Application model on a FreeBSD operating system
• Software Distribution/Application on a Linux operating system
• Software Distribution/Application on a Debian or Ubuntu GNU/Linux operating system
• Software Distribution/Application on an Android Operating System
• Software Distribution/Application on a Microsoft Windows operating system

Orthogonally, it is the author's hope that the resulting UML profile models will be compatible onto the CORBA Component Model -- such that, in a sense, may complemented with a UML profile model extending of the concept of abstract software application, if not moreover integrating a manner of a system for software distribution in regards to CORBA components, there certainly making reference to OSGi and also Maven.

That being so, then how may the author propose to publish a UML profile model, in any vendor-compatible regards? The author proposes to apply Modelio, and to publish the UML profile models finally as serialized XMI. The author furthermore proposes to apply the respective UML profile models, in development of a manner of a component metadata database, there integrating the DOAP RDF schema and some manner of a web publishing model for presenting the metadata database, in any managed manner, online. The DOAP RDF integration, in itself, may entail a development of an extensional RDF schema, moreover an application of some existing tools for RDF graph modeling in Common Lisp.

Of course, there is a sort of a boostrapping dilemma, in such design. The author proposes to address the bootstrapping dilemma, in -- albeit, perhaps in something of a expressly nolinear sense -- but in an overall iterative sense, however. In such a sense, the author does not propose to specify that the design of the RDF application would wait on the design of the project-oriented management information system (Project MIS). The RDF application must wait, however, for the design of the final component metadata schema.

Towards such an application of RDF, the author wishes to comment towards a sense of applying Common Lisp as a data system feature, within a data programming system, there closely and comprehensively integratred with the underlying operating system. The author proposes to limit this specific design to the FreeBSD operating system,  moreover to focus about a small number of individual, concrete components such as already developed as and for individual Common Lisp implementations. The goal of this aspect of the design, to the author's opinion, the goal is to support software systems development with software systems development and documentation. In such a regards, perhaps it might seem like a manner of a DevOps concept, however developed of a popularly unconventional framework

The RDF application, specifically, it may be developed as to extend of an XML Schema Datatypes implementation. As in a manner across the XML Schema Datatypes Implementation, it may be integrated onto a data persistence model for RDF, there to apply a HypersonicSQL service as a data storage service.

If there may be a rhetorical question, such as, "Where to begin, next?" the author prpoposes to continue with the development of the UML profile models, as denoted herein.

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. 

Notes - MetaCommunity.info fork of McCLIM

Towards developing an application framework for supporting a platform-agnostic approach to development of graphical desktop applications in Common Lisp, I've made a fork of the McCLIM codebase, organizing the codebase under the MetaCommunity projects group at Github. Corresponding with so much as the maintenance updates in the fork, I've also begun to keep an issue tracker with YouTrack, under the hosted YouTrack InCloud service, At this time, I would not request contributions about of those endeavors. This is simply a note that I would like to share, regarding such existing work.

Insofar as keeping track of the aims and goals of the development of the MetaCommunity.info (MCi) fork of McCLIM, whereas the project comprised of the fork does not yet "Fit" into any specific heading within the two main MetaCommunity.info projects groups -- respectively, the Clyde projects, named after the Firth of Clyde, directed  mostly towards applications in mathematics and electrical engineering, and the Fourier projects, named after Charles Fourier, those to be focused mostly about literacy, tourism, and ethical conservationism, so far time and focus permit -- so, instead of documenting this small effort, presently, at the MetaCommunity.info work journal,  instead I thought it would be appropriate to publish this outline, here at DSP42.

So, with that much of adieu, my notes about the MCi McCLIM fork.

The main points of focus in the development of the MCi McCLIM fork are as follows:

• Maintenance updates
• Documentation
• Usage cases
• Scigraph
• Extensions: ??? 
• Usage cases on the BeaglBone Black platform (ARM) in applications of BBB TFT LCDs
• Application: Multi-headed display for desktop measurement/analysis system
• Application: Small electrical systems monitor (Solar electrical system)
• Additional notes:
• Deterministic timing in RTOS systems
• Memory locking
• Process scheduling
• Garbage collection in the Common Lisp implementation
• Kernel architectures (onto Linux kernel space)
• See also: Realtime applications of Java / Realtime JVM implementations
• Extensions in development of another mathematics platform in Common Lisp
• Polar coordinate graphing *
• Graphing for objects on Euclidean and Complex planes *
• Measurement Units (See also: Igneous-Math)
• Phasor diagrams *
• EE Applications (AC systems; signals synthesis; signals analysis)
• Applications in classical mechanics
• Linear algebra *
• Trivial concept: Presentation type for a matrix view of Common Lisp arrays
• Less than trivial concept: Differential analysis, with corresponding presentation types
• Extensions for systems modeling and interactive model design, in Common Lisp
• URIs
• XSD
• XMI
• UML Primitive types)
• MOF
• UML metamodel
• SysML metamodel
• ODM metamodels (RDF, OWL, Common Logic)
• Extensions for a CORBA-centric desktop application framework
• ORB monitor
• IDL designer (IDE)
• ??? (TBD)

* See also; Scigraph application, as published in McCLIM (referencing the MCi fork)

Certainly, the development of the fork is focused mostly towards usage cases. Beyond the maintenance updates, there may not be much to add to the McCLIM codebase itself.

Perhaps there may be an opportunity for adding some developer documentation to the codebase, over subsequent changesets in the codebase -- pending development of a suitably comfortable documentation system, perhaps extending of DocBook XML

This, then, would represent the first significant "Note to public" regarding the McCLIM fork developed under MetaCommunity.info.

Thus far, the fork is representative of the source tree cloned from Timothy Moore's original McCLIM source tree, with some changes merged in from Andreas Fuchs' fork, as was developed onto the original McCLIM CVS repository. I've also made a small number of maintenance updates to the source tree, including a short effort for a portable multiple-value setq (needs testing), and a defconstant* form to avoid errors on repeated redefinition of constant values.

Subsequently, the fork may also merge the changes developed under Robert Strandh's McCLIM fork. I'll make a note of that in my own Diigo bookmarks, and here.

This effort is, at the outset, mostly an academic matter. I cannot imagine any immediate commercial applicability about such work. Perhaps it might seem, then, as though it could represent something of a quixotic kind of "lark", in the conformity-oriented social network of "the modern." Regardless, there is the source tree as updated, to-date.