Wednesday, January 28, 2015

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. 

Tuesday, January 27, 2015

DSP42 'blog volume II

So, I've found an alternative to writing in this web log as if it was some kind of a cryptic, personal journal.  It's called Evernote.

Sunday, January 11, 2015

In a View of a Software Project as a Tree-Like Structure: Towards Memory Locking and Memory Access Control in Common Lisp Programs

On beginning a study of National Instruments' LabVIEW programming platform, last year -- that, as was contingent on being a student of a sort of vocationally-focused introductory program in computing, networking, and the electrical sciences, a program hosted by a certain online university -- the author if this article has begun studying a broader concept of data flow programming. Contingent with that study -- not as if try to trump-up any competition towards National Instruments (NI) but rather towards a broader academic study of data flow programming -- the author has been developing an expression of a concept of data flow programming, in Common Lisp.

The author would gladly make reference to the source-tree for that item, here, but it may not be in any useful state for applications, presently. The author has been referring to the project as eSym -- as to denote something towards a concept combining of component concept of symbolic logic and a metaphor with regards to electrical current flow.

While developing eSym, the author has discovered a number of complimentary concerns that may be addressed in a Common Lisp program. Those concerns may be addressed before eSym would be any further developed.

The following article presents an outline of those initial concerns, then proceeds to develop some concepts as with regards to a sense of a broader context in development software programs in Common Lisp.

  • An extension may be defined onto the Common Lisp Object System (CLOS) -- at the least, in implementations applying of the Metaobject Protocol (MOP) -- such that the extension would allow for a thread-local modal locking procedure -- and more specifically, a read/write locking procedure -- onto slot values of a Common Lisp standard object.
    • This, in turn, may be implemented onto a portable interface for modal locking, such that may be developed directly onto Bordeaux Threads (BT), in a platform-agnostic model
      • In parallel to developing a modal locking layer onto Bordeaux Threads, an additional portability interface may be developed onto so many implementation-specific timer interfaces
        • ....such that may then be applied in a revised `BT:WITH-LOCK` then allowing a blocking keyword argument -- the behaviors of which would be fully described in the documentation, but in summary of which: 
          • blocking t : block indefinitely to acquire lock
          • blocking nil : do not block. Rather than returning nil, should signal error of type lock-held if lock is held, such that the calling function could then handle appropriately without storing a return-value from the failed lock acquisition request
          • blocking {integer} : block for a duration specified by {integer}, and if timeout, then signal error of type timeout-exceeded
        • ....and that may then also be applied in a new `WITH-MODAL-LOCK` macro, as well as underlying `ACQUIRE-MODAL-LOCK` function
        • Alternate to Bordeaux Threads:
          • Threading in cl-async [github]
            • Extended with a BT-like interface in Green Threads
            • CPS: Continuation Passing Style [multscheme]
            • In operating systems applying a pthreads threading model, this may provide an interface onto an underlying PThread implementations, as via cl-libevent2 and transitively, libevent
            • libevent provides a platform-agnostic model for development of asynchronous programs onto C
            • As far as a portable timers implementation in recent revisions of cl-async : See also  delay / with-delay (?)
  • The data flow programming language, in its abstract graphical representation, could be implemented as an extension of the abstract graphical syntax and the underlying semantics of the Systems Modeling Language (SysML) ... as SysML being implemented with a metamodel extending of the meta-metamodel defined of the Metobject Framework (MOF).
    • Alternately, a SysML view for the data flow programming language's data flow graphs could be added later.
    • This may extend, indirectly, of de.setf.xml -- with de.setf.xml providing an interface for parsing the XMI schema and the XMI schema then serving to present a structured interface for processing and I/O onto metamodels serialized onto the standard MOF/XMI binding , with any number of vendor-specific conventions in the same.
    • An implementation of the Object Constraint Language (OCL) should be developed as part of the same -- such that may apply the ATN parser, such that is applied in de.setf.xml -- the parser implementation in the OCL implementation therefore remaining aligned with the XML implementation
  • This data flow programming model may  of course be implemented with extensions onto McCLIM, for managing interactions with a data flow programming graph, as via a CLIM application frame.
In parallel to the matter of thread-local slot value locking: While I was developing some notes as with regards to a lock ticket caching framework -- and a more generic object buffering framework -- as to address a question of how a program may provide an interface for controlling access to the slots of  buffered object, such that the buffered objectwould be simultaneously accessible in a buffer cache and from there, accessible in any number of threads of a program, as well as being accessible broadly in the data space of the containing process -- I had developed a question as to how and whether it may be possible to control access to a region of memory. In regards to how that may be approached in software programs developed on the Linux kernel, my question -- as such -- was promptly answered, on discovering the shmget(2) and shmctl(2) manual pages, as well as the useful  shm_overview(7) such that provides an overview of an independent SHM interface providing file descriptors for shared memory segments.  I would denote some additional caveats to this matter, as well:
  • The  shmctl(2) manual page, specifically, describes some of the structural qualities of the following structure types in the Linux programming environment:
    • The C structure type shmid_ds 
      • Application: This type appears to be used for providing information about the Kernel's implementation of the SHM interface. For instance, there are some structure slots for recording of times and process IDs (PIDs), within the shmid_ds structure type
      • The shm_perm slot provides further structure, as denote in the following
    • The C structure type ipc_perm
      • This type uses the key value as applied also with shmget(2)
      • This type also provides a record for UID and GID values as well as flags for access permissions defined onto a shared memory segment
    • Consequent to a further study of the shmctl(2) manual page, it may seem that the shmctl() function is defined for purpose of reflection onto system-wide registers with regards to shared memory allocation
    • An orthogonal question: Onto what platforms other than Linux is the Linux SHM interface considered portable?
      • BSD?
      • QNX?
  • It's not the same as mlock(2)
    • Application: Ideally, there may be a compatibility interface defined between values used in  shmget(2) and similar SHM functions, and values used in mlock(2). Such a compatibility interface may or may not exist, presently, within the body of existing work in free/open source software and systems
    • mlock(2) may be applied in at least two manners of usage case
      • To prevent a memory segment from being paged to disk, as to ensure that data in the memory segment will not be recorded in any permanent medium, namely towards applications in data security
      • To ensure that a segment of memory will not be paged to disk, as towards ensuring a deterministic timing within the calling program, for access onto the same segment of memory -- as towards applications in a realtime operating system (RTOS) environment, such as for embedded computing. As a further reference, to that effect: sched_setscheduler(2)

This outline, of course, does not present a full interface onto SHM in Linux, for any single Common Lisp implementation. The previous outline may serve to develop some further knowledge, towards some questions with regards to memory management, within any single Common Lisp implementation, viz a viz:
  • One  "first question", as towards the origins the previous outline -- more broadly, as towards preventing unwanted access to regions in a program's data space -- in that regards, towards a design for data security within Common Lisp programs. 
    • The question, in short: How can an interface be developed for controlling access to memory registers within a program's data space, in a Common Lisp program on any single operating system platform? 
    • Nothing to compete with the Java programming model, certainly, though Java also defines some controls for data access, at least insofar as with regards to definitions of Java fields and Java methods in Java classes. The author is not presently aware of any similar SHM interfaces in Java.
  • A second question, as contingent around the matter of RTOS applications: 
    • The question, in short: How can memory be locked, within a Common Lisp program -- whether permanently or temporarily -- as to not be shifted in the data space, within garbage collection processes?
      • This is orthogonal to the question: How can memory be locked, within a Common Lisp program, as to not be paged out to the system's page area?
    • The "second question" is notably a naive question, it demonstrating some assumptions as to what side effects a garbage collection (GC) process may produce, within a Common Lisp program. Namely, there is an assumption that an object's object address may change within the duration of a Common Lisp program -- assuming that an object in a Common Lisp program may not be left where originally created within a program's data space, after completion of any single GC iteration.
    • Of course there would be some orthogonal concerns, and perhaps some orthogonal design concepts, for instance:
      • Is it possible to define a specific region of memory as being locked with mlock(2), and such that that region of memory may be used for allocating multiple Lisp objects? 
        • May that serve to provide a methodology for implementing a non-paged memory IO region wtihin a Common Lisp program?
        • May it serve to allow for a tunable efficiency in applications, such that mlock(2) may not need to be applied at every time when a new Lisp object is allocated? 
        • If a shared memory control interface would implemented, in parallel to this feature, of course the shared memory control interface may produce some side effects as with regards to this feature's implementation -- for instance, in that an access-controlled region of memory may be effectively contained within the mlock'd memory region.
      • There may be some additional concerns addressed, as with regards to manual memory management in Common Lisp programs, for instance:
        •  That  if there may be an application in which one cannot simply cons and forget and leave the garbage collector to clean up the memory space for unused objects
        • ...then as well as the implicit memory allocation of creating a new Lisp object
        • ...a Lisp program may provide an interface for manual memory deallocation, thus towards both
          • obviating the burdens for the garbage collector and also 
          • allowing for a deterministic procedure chain, insofar as for memory management within a Common Lisp program
        • This can be implemented with requirement for multithreading.
          • An explicit memory deallocation thread may be implemented
            • to be coordinated in scheduling alongisde the garbage collector
            • ...such that it would be accompanied with rigorous definitions of memory deallocation forms, for ensuring that objects created for "one time use" within a single lexical environment will be explicitly marked as to deallocate when control exits from within the same lexical environment.
            • ...though that would require a storage of a separate "to-deallocate table" essentially separate to reference-counted memory -- lazy references? -- and a methodology for iterating across the same table, perhaps alternate to a methodology of scanning Lisp objects recursively for count of object references and recursively deallocating those denoted only as "not referenced".
            • ...and may be applied with an functional interface, parallel to cl:gc, rather such as foo-mem:prune
            • ...such that an application applying the memory prune function may be exist in parallel to applications not doing such explicit memory deallocation.
            • ...and should be accompanied with a conditions model, such as for when   foo-mem:prune would be applied on any object that would contain, as an n-ary  referenced object, any object that would be known as that it cannot be pruned, for instance any definition of a class defined in the cl package
            • ...and must also be accompanied with a lengthy description of how foo-mem:prune would function on individual objects to be pruned
              • Note: Reference vs definition -- for instance, that a reference to a string is not a string object itself
            • Essentially, this may serve to develop a concept: Memory management for objects referenced within only a single lexical environment
            • Ideally, this should be implemented as to not entail any overhead for "Reference counting".
Certainly, a Common Lisp interface on the SHM features of the Linux kernel may be implemented as a layer onto an interface onto mlock(2) -- and so, the development of the mlock(2) interface could effectively precede the development of the SHM memory control interface. Also clearly, such extrnsions would need to be implemented in all of an implementation-specific manner, as onto the memory management features of any single Common Lisp implementation. This, then, would certainly require much of a detailed study onto those same features, and perhaps an application of the C programming language.

Some further notes in documentation should be forthcoming, to that effect, as may be published in this web log, henceforward. The author proposes to limit the study onto two Common Lisp implementations specifically: such future time as when it may be immediately feasible as to address the following procedural outline into an implementation:
  1. To begin such a study of memory management, on those platforms.
    • Ostensibly, to develop a series of SysML models for describing the conventions applied in memory management on those platforms
      • UML class diagrams for illustrating structures and relations of explicit and inferred data types (e.g. VOPs in CMUCL and SBCL)
      • SysML block diagrams for developing a block/port-oriented view of memory and memory management  in the respective Common Lisp implementation
      • Onto CCL, block diagrams illustrating of qualities of the FFI interface
      • State Charts in SysML for describing memory management in terms of finite state automota
  2. To develop an interface for an  mlock(2) locked region of memory in a program's data space
  3. Implicitly: To develop a Common Lisp interface onto an operating system's underlying authentication and authorization (A2) model
    • To furthermore extend that interface onto the A2 procedures of Kerberos 
  4. To develop an interface for an SHM controlled access to memory within a program's data sapce
    • To develop such condition types, deubugger features, and other features unto the Common Lisp semantics, such that may serve to simply the programmer's view of the memory access control forms 
If the reader may wish to inquire as to why those two platforms are specified, in this article:
  • Both of those platforms may be applied on an ARM microprocessor architecture
    • ARM, in turn, is applied within a number of embedded computing platforms, including mobile phones
  • Although there are additional Common Lisp implementations available for the ARM architecture -- including ECL -- it may be feasible to limit the study to, essentially: 
    • One implementation of or deriving from CMUCL, as with SBCL at the original "Point of fork"
      • This should be approached with an observation about signals, interrupts, and foreign threads in SBCL -- as denoted as being problematic for an interface onto a Java Virtual Machine, at the web site for CL+J 
      • This should be approached, also, with an observation as with regards to the newer thruption model in SBCL, and related features defined in recent editions of SBCL
    • One implementation deriving its implementation more broadly from LibC, as with CCL and its own respective foreign functions interface
      • This may be approached with consideration: 
        • That the Linux Kernel is implemented in C
        • That the fundamental interfaces to the Linux Kernel are provided as for C programs
        • That the FFI model developed in CCL may applied in a prototype fork for and towards applying such extended memory management procedures as denoted in the previous outlines in this article
Of course, it would be impractical to assume as if an extension could be addressed instantaneously onto two separate Common Lisp implementations, if only a single developer is developing the same extension. At this point in the article, the author arrives at a point of decision as to which Common Lisp implementation the author would wish to focus on, first, if to develop such an extension. That question, then, may be pushed further down the effective stack, with a couple of corresponding questions:
  • How may a mobile application development model be developed in free/open source software, for supporting development of mobile applications and desktop applications with Common Lisp?
    • How may CLIM be applied within such a model for mobile application development in a free/open source regards?
    • How may that be extended, furthermore, in applications of "new" embedded computing models, such as may apply the BeagleBone Black platform, Gumstix, or any other single-board computing model capable of running a Linux operating system?
  • How easily can CCL or SBCL and McCLIM be installed onto an Android device, for purpose of development testing?
    • How easy would it be to use the CLIM REPL, in such an installation?
    • How many separate concerns may be addressed onto CLIM, as for design of mobile human computer interfaces -- in whatever regards, if as an alternative to conventions developed of popular desktop computing interfaces? 
      • How and how well may CLIM be integrated with an on-screen keyboard, as of a tablet PC or a notebook with touschscreen?
      • Would it not be useful to include a modeline -- even if it would be a 'hidden modeline' of a kind -- onto every single window created, in such an appliation of CLIM? Then how would the 'meta' key be implemented, for key input to such a modeline?
  • How can a commercial interface be developed, onto such work, and it not be limiting towards the free open source nature of the software that would be applied in such work?
    • Sidebar: "Free/open source" does not imply "Insecure"
      • A deterministic model will not be illustrated for that thesis, in this article
    • Sidebar: Incentives?
      • Data-secure computing for small/medium enterprise - referencing strongSwan, Kerberos, and JacORB as providing support for Kerberos and SSL onto CORBA
      • Games programming for mobile platforms, in Common Lisp? 
        • Can we make it look more like Half Life? Should we?
        • What about music?
          • What about folk music?
        • What about educational applications developed albeit with a novel game-like interface but lending towards any actual, fundamental concepts in mathematics, if not also towards the material sciences?
          • What wonders may await, in the literary works of Charles Babbage?
          • What wonders, in a view providing of an implicit sense of gender neutrality, if not a broader sense of cultural neutrality, with regards to mathematics and science? barring any discussions lending immediately to a maturity of nature.
      • Furtherance of concepts in the state of the art?
        • IDE development in the heterogenous systems programming environment
          • Towards implications for the software development environments in applications of virtualizaiton and software-defined networking (SDN)
          • "Because CORBA"
      • Beginnings of discussion with regards to community support, if not for further commercial support for Common Lisp  applications on mobile platforms?
        •  "There's the kicker"
        • Existing services for issue support may include:
        • May entail some platform-specific focus about Linux
          • The following mobile platforms implement Linux:
          • Focusing on the Android platform, specifically, there may be an interface available for bug tracking onto any single Anrdoid app store (TBD)
        • Questions with regards to tools
          • A hypothetical model for capturing results of an application error: Fork, save diagnostic data-optionally save entire Lisp image, and debug on 'Own hardware"
            • Revisions for "Other users" : Do not save session-local data within diagnostics; Do not save Lisp image; ensure full authorization and authentication with upstream issue tracking agency, in network transactions transmitting of diagnostic information
          • Debugger hook : How to apply that usefully on a mobile platform?
            • Usage Case - Developer's mobile platform
              • Context: Prototyping and testing
              • Context: Unexpected situation in program
            • Usage Case - User's mobile platform
              • Context: Regular application procedures
              • Context: Unexpected situation in program
          • Debugger hook   How to apply that  usefully, for server diagnostics?
          • Data models : How to "flag" session-local data values, so as to prevent their printing or storage onto media outside of environment of a running Common Lisp program?
          • Systems models : How to securely and conveniently (?) encrypt a saved Lisp image?
            • Further implications onto design and development of digital platform operating systems?
          • How to integrate developer tools, in a novel manner, with Xen? 
            • cf. Xen Dom0 
              • Emulator as Dom1 instance
              • Xen must be (?) installed directly on platform hardware
              • Orthogonal to: Microkernel design.
            • cf. Amazon Web Services
              • Application of Xen
To this point in the article , the article has diverged from the original topic of developing a data flow programming model in Common Lisp.  Figuratively, the eSym project might represent some figurative icing on the figurative concha otherwise described in this article. The majority of such tasks as would entail an extension of interfaces onto the Linux kernel -- as addressed in this article, albeit superficially -- those might be approached albeit without a cup full of sugared bread, but with a substantial portion of documentation regardless.

This article has described a substantial number of individual concepts and related task items, such that may be addressed into development of an essentially arbitrary number of source trees.

This is developed under the MetaCommunity project, towards a further goal of developing a comprehensive architecture for application development in Common Lisp, and an orthogonal goal of reviving the design of MIT CADR for application onto contemporary microprocessor architectures, denoted as the CIIDR project.

Thursday, January 8, 2015

Language - Russian - Notes

In an effort to broaden my own sense of cultural literacy, I've begun studying the Russian language, this year. I've collected three primary literary resources that I will be applying, in this study:

The first item -- a resource published by Penguin -- it is comprised of a single book. The second and third items -- both, published by Hodder & Stoughton -- are boxed sets, each, of CDs and a book. Although, personally, I've manged to separate some of the CDs and books from their respective containers, in the last two items -- now having kept one booklet and one CD still in a box in storage, in a locale presently half a state away from me, candidly -- but with the three resources together, and in applying some web-based resources, also, I'm certain that I should be able to develop something of a meaningful a study with those resources, regardless.

Of course, not as if to plagiarize any of those resources -- so, with formal reference, as such -- I do plan on developing  a set of personal notes, in this study. I would like to publish my notes, as such, here at my DSP42 web log, while proceeding along in the study.

Presently, I'm using the Google Chrome web browser. I mention this, as to denote a convenient feature that is avaialble in the Google Chrome web browser and its baseline, Chromium, namely: Both editions of the browser are integrated seamlessly with Google Translate, Essentially, this serves to allow for a web-based translation of pages loaded in the browser, such that doesn't even require a direct visit to .Google Translate. That feature, in turn, may serve to assist the reader for interpreting pages at the Russian language Wiktionary

Returning to denote a matter with regards to non-digital resources, in this language study: The first study resource that I would like to denote, here, it is in regards to a term of greeting, a word like "Hello," with two distinct expressions:

Those words are both denoted, in the Lexvo dictionary at the links, each as an interjection, in a grammatical regards. More directly, each expression represents a sense of greeting -- whether respectively to a casual audience, or to a formal audience.

Considering that it's become a fairly early hour in the morning while I've been writing this article, I will conclude this study, shortly. One matter that I would like to denote before publishing this revision 1.0 of this article: Russian is a friendly, succinct language.

Updating this article:

Resources abound, for studying the Russian language. This article, individually, may represent simply an effort towards presenting a number of resources that the author is familiar with, if not towards developing any single manner of a conceptual, ontological view of a semantic bridge between the English and Russian languages.

In the latter regards, as well as Lexvo and Wiktionary, there is also the Yet Another Russian WordNet (YARN) project developing an original, semantically structured Wordnet lexicon in Russian.

In a technical view, the WordNet manual pages may serve to provide something of a sense to the conceptual structures in which the WordNet lexicon, itself, is defined.

Focusing on Common Lisp programming language, specifically there are Vsevolod Dyomkin's notes about NLTK 2.3 - Working with Wordnet in Common Lisp.

Wednesday, January 7, 2015

Toards an Ontology for Computer Networking and Concepts

I was writing a response to a discussion forum item in a course about computer networking, this evening -- a course that, in a tools sense, is essentially addressing some of networking with Cisco network routing components, and I know there's also Juniper in digital networking -- but in a moment in which it did not seem like a course simply conveying a single corporate model for computer networking, I thought it was apropos to begin a comment in a manner orthogonal to my primary response in the discussion forum. The beginning of this rhetorical tangent was about a matter of applications of structured hostnames -- that is, hostnames in which some of a matter of structural information would be conveyed in a lexical encoding, in the hostname.

The orthogonal part of my comment -- which I was careful to denote as orthogonal in the beginning of that section of my comment -- it was towards a definition of an ontology for computer networks. The initial prototype was as follows -- edited, here, for uniqueness in regards to Individual object names.

Prefix: : <>
Ontology: <>

Class: Host 

Class: Role 

Class: Location 

Class: Application 

AnotationProperty: hasHostname 
    Domain: Host 
    Range: xsd:string 

ObjectProperty: hasRole 
    Domain: Host 
    Range: Role 

ObjectProperty: hasLocation 
    Domain: Host 
    Range: Location 

ObjectProperty: hasApplication 
    Domain: Host 
    Range: Application 

Individual: Beijing 
    Types: Location 

Individual: InternetGateway 
    Types: Role 

Individual: Router 
    Types: Application

 Facts: hasHostname "bjg_int_router"^^xsd:string,
  hasLocation Chicago,
  hasRole InternetGateway,
  hasApplication Router

Outside of the semantic context of the original discussion forum, perhaps that simple network ontology may seem peculiar for its singularity. I had developed that ontology -- there in OWL Manchester syntax -- as it illustrating how some of the qualities of a  network host may be modeled in an ontology, essentially in a manner independent of any single network hostname.

In a sense with regards to possible applications of that ontology: I had noted -- in the end of the orthogonal section of my comment, this evening -- that a network ontology could be applied within a management information system (MIS) as for support of network troubleshooting and for general information to network management staff.  I had noted, also, that it could serve to limit any of a sense of complexity that might attend with an application of software defined networking (SDN) as might be developed within a virtualization / cloud services architecture. I had also taken care to note that -- in the development of an application for that ontology -- it would not be as if to compete with Puppetlabs' Puppet framework.

Whereas, the orthogonal section to my single comment -- in that forum, this evening -- my comment had already become fairly verbose with the addition of that ad hoc ontology, and considering that the discussion forum is defined within a course about computer networking, not insomuch about software and systems design, I had not endeavored to develop any single concept of a design plan, there, beyond the simple matter of the ontology -- secondly, a short summary of possible usage cases, for application of the ontology.

Though the orthogonal section of my my comment was verbose, there, I had thought it was worth retaining in my comment, this evening, as that it would serve to illustrate an application of an ontology technology, hypothetically for and within a support system for computer network design and computer network administration -- towards something practical, as a development of an ontology about networked computing systems. Of course, now that I have developed this comment, separately here at my DSP42 web log, I am cautious mostly as to avoid if anyone may wish to interpret this article on an odd skew. That, essentially, is to why I do not often comment to any too trivial concepts, online and -- if I would comment to any trivial concept -- why I would couch it in a lot of verbosity: Namely to avert such asinine opportunism as I am too far familiar with of Internet users -- that the Internet's little sharp-shooters might simply be too bored to bother trying to play themselves out to me, in any further.

When I'd developed that ad hoc ontology in the context of the original discussion forum, that ontology had seemed to me like it could be a great concept to develop, and to share even in an orthogonal section of my comment. Outside of that context -- presently, as into the abject circus of the wide Internet -- it does not seem so worthwhile to me, to develop that ontology in any further -- but then, again perhaps some of that is a side effect of some of the momentary, but frequent, sickening idiocy in the liberal circus where is my present residence. One might not think it was a diaspora, by its outward look, "Such an area." One might wonder, however, where such a circus may intend to convey itself to, in whatsoever -- and how has such a circus become of this US?

That in such a circus as I refer to, here, self-deluding entertainment is clearly the "Going thing" among all the hipsters, I cannot imagine as if anything of any manner of a complex software design could be of any use, in such a society, in whatsoever. Clearly, they have their entertainments, the circus-goers. That must be enough, then, and I should not even bother except to leave, indefinitely.

Tuesday, January 6, 2015

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.