Onto ... Graph Theory in Applications of Ontology

Though with apology to the indeterminate readership, I don't have a convenient bibliography to present about it, offhand, personally I've been studying some concepts in ontology, for a small number of years -- all, in informal study. I've really not ever managed to develop an academic transcript adequate for transfer to any manner of an Ivy League school or anything like. I suppose, personally I'm still trying to understand what academia means, to me, as academia being such that I consider to be a necessary part of life. I would not wish to make any long sort of an anecdote as to denote why I consider that I'm of such a view, perhaps it's a bit of a meta-semantic sidebar anyway, towards the present article.

Presently, I've begun to develop a thesis concept with regards to how ontologies may be applied in a sense of personal or academic knowledge management -- nothing quite so technically aspiring as the Nepomuk ontologies, though I suppose it could "Aim" towards that, at some time, as when there would be any applications to speak of that could utilize Nepomuk's facilities for adding an ontological layer onto personal information management (PIM). Presently, I'm trying to focus more about a concept of concept -- in a manner of a literary sense of concept -- such as may presented meta-semantically in extensions of the SKOS ontology.

Considering an ontology, in a generic sense, as a form of a reference medium, orthogonally, one may endeavor to view an ontology as it being essentially a literary kind of reference medium. However an ontology -- whether in RDF, OWL as extending of RDF, KIF, Common Logic, or other format -- however stored or transmitted in its essential structures, an ontology typically contains a lot of essentially textual information. In a sense of RDF, an ontology may contain textual information in forms of short texts about resources -- texts that are likewise resources, such that may be furthermore reified as resources, within any single RDF graph medium. Perhaps it may ever be recognized as a nice susbset of application media, the set of ontological graphs altogether.

Presently, I would like to denote a simple thesis statement that I've been able to etch out the raw stuff of own knowledge, this evening: In a practical application of ontologies, focusing namely on the Web Ontology Language (OWL), one may define two categories of OWL ontology for practical applications:

• Structural Ontologies, containing definitions of OWL Class, Object Property, Datatype Property, XSD Datatypes, and Annotation Properties for applications
• Instance Ontologies, as applications of structural ontologies, such that would be applied in definition of OWL Indvidual type resources, in extending of structural ontologies.

Though I would not wish to seem excessively proprietary about it, personally I've begun to develop a corresponding thesis about a small set of structural ontologies, such that may be applied in tracing of information conveyed in jouranilsm, and might likewise be of some use for applications perhaps in at least an ad hoc manner of field archaeology. In a trivial sense, it may be decandted to a matter of: Persons, Places, Events and References, in a bibliographical sense. The Events concept might seem to be the pivotal concept, at that -- in however an event may be in any sense singularly defined, as in a  context of any single literary work.

There's a fifth concept that I would like to add to that small list, this evening, if one may endeavor to develop at least an ad hoc sense of structural geneaology. It's a concept that I've yet to find any single ontology for, however -- essentially, orthogonal to an Events ontology, if there may be any single ontology for literary endeavors about constructed objects. I do know of a small few of resources I could revisit online, as to do conduct more research about that concept, perhaps this evening. I'm afraid that it might be a bit of a disorganized list, if I'd try to itemize that set of resources, immediately. It's also a task wholly orthogonal to the thesis topic that I'd hoped I might be able to begin to write down, presently -- and although the latter may be a bit of a vague idea anyway, but it's such that I'd like to continue to whittle about, literally, towards further developing an idea for application of a small set of structural ontologies and instance ontologies in ... in no exacting usage case, as yet.

Personally, I'm not certain of how far a concept of proprietary knowledge may or may not extend into formal academia. Towards my further sense of disdain at that sense of ambiguity, even if I am researching of these topics, informally -- not being a student of any single, formal course about ontology, at present -- I consider that I should certainly try to respect any number of formal academic models, even in my own research and writing -- at least inasmuch as I  might understand such models, candidly.

What, then, do I mean by proprietary knowledge?  In as much of an exacting sense as in which I can try to define what I mean, in that phrase: I mean, any knowledge legally and necessarily protected under terms like with regards to literal intellectual property. Not as if to indulge in writing any lengthy sidebar with regards to any sense of  commercial intelligences or small business, but if I would denote intelligence as a noun, I consider that I should as well denote how it is a noun that I consider has a natural, plural form. At that, though, I think it goes far towards psychology, and personally I'm not well read about that domain of academia.  It would be quite a sidebar to begin, this evening, to define what I may mean to denote by that simple term, in an exacting sense.

So, but in being aware of some concepts of proprietary knowledge, and in avoiding any particularly revolutionarily characteristic sort of views about any concepts of propriety, I know there are things that I know, such that -- for online discourse, and not only -- that I advise myself, implicitly, to not even denote I know. Perhaps it's a bit of an odd thing, but "That's life," as I understand it -- never 110% transparent. I feel that that's such that I should denote, distinctly, before any further discussion of ontologies. Orthogonal to that oblique disclaimer, I know there are things that I don't know, too -- if there may ever be any single count of known things, probably more things in the second category than in the "Immediate knowledge" category. I think it's as well to not be too deterministic about knowledge -- moreover that science, as a human effort, indicates that no person's knowledge is ever absolute and complete.

Perhaps its simply that I wanted to note, this evening, that there is a thesis concept, vaguely "Here," and that I know there's probably more of a bibliography about it, mroe than what I have ever found, as such. Perhaps, either, I'm simply trying to circumscribe an arc around a notable gap with regards to any profound and immediate illustration of a thesis concept, in software, such as may entail an application of any number of concepts in ontology.

In my not being direct, in this article, I'm certainly not trying to avoid mentioning any manner of a pink elephant in the room, with regards to applications of ontologies. Orthogonally, I don't personally happen to follow the logic of the Manning/Snowden/Assange conspiracy, though I have certainly read of it. 

Inasmuch as considering that a study of academia may entail, implicitly, a study of a veritable plethora of knowledge, namely human knowledge --inasmuch as even to present the ultimate, existentially challenging question, What is knowledge? -- perhaps, though, what I should be concerned about with a perspective about software, perhaps it  may be more towards a practical question of presentation, How well may knowledge be presented?

Not to cut corners in this informal thesis, I understand that there's a design as for a human-computer interface (HCI) toolkit, the Common Lisp Interface Manager (CLIM). As an HCI toolkit, perhaps the design of CLIM, so far as to CLIM 2, has been focused about graphical displays and keyboard interactions, but certainly that's in keeping with the sort of HCI environment that we may be most familiar with, as sighted computer users at personal computers.

CLIM presents something of a simple, basic, practical model for HCI implementation in graphical display/textual keyboard/on-screen pointer environments. Also, CLIM has some features catered for print-based representation of graphical objects, as towards a sense of print as media.

Personally, candidly,, perhaps I have not always been a great fan of the interface for the CLIM obect model, in Common Lisp. I'm a little put off that it doesn't seem, to me, that it completely utilizes the Metaobject Protocol (MOP), though I know MOP is not an ANSI-standard fare in the Common Lisp Object System (CLOS) anyway. I simply think there must be a more effective way to program interfaces with CLIM, of maybe that's simply too naive of an idea.

As it being an object model however, I'd say CLIM is pretty square.

So, now I'll just jump right to the point of applying CLIM and Franz Allegrograph -- taking a short break from this thesis article, presently

Franz, Inc. publishes a VMDK edition of their semantic information systems platform, AllegroGraph. Presently, the VMDK edition includes AllegroGraph pre-installed in a 64-bit Ubuntu 14.04 OS, the Trusty Tarpaulin edition of the Debian-based Ubuntu GNU/Linux operating system. The VMDK can be installed to a virtual appliance in VirtualBox, or any number of other desktop-based virtualization systems. In a nutshell, it provides a quick start-and-go interface for working with Franz AllegroGraph.

As far as how to configure VirtualBox networking for accessing the VMDK from outside of the VMDK's software space ... that will not be presented with details, in this article. The VirtualBox manual includes the complete details of that. This article will assume that the VirtualBox virtual guest appliance is configured with VirtualBox NAT networking, with a host interface having the IP address 172.16.42.1

Moreover, this article assumes AllegoGraph is configured in agraph.cfg, with at least the following configuration directives:

Hostname 10.0.2.15
Port 10035

Thirdly, this article will assume that the VirtualBox NAT networking is configured for port forwarding in the VirtualBox interface between the virutal host OS and the virtual guest OS, simply to the effect:

172.16.42.1:10035 <=> 10.0.2.15:10035

With such a configuration installed, a developer may apply any of the AllegroGraph clients, in developing on the virutal host OS -- with apology, developing no lengthy side-thesis about software defined networking (SDN), here, or either, about integrated development environment (IDE) platforms applicable for Common Lisp software development. In a practical sense, certainly such configuration properties can be managed via software, but even in so much of automation, it probably would help to understand at least a little bit about TCP/IP networking. Within the virtual host OS, the networking and port forwarding properties can be managed via the VBoxManage shell command. Within the virutal guest OS, as in this example, the configuration properties can be managed via both of the files, /etc/network/interfaces and /home/franz/ag/lib/agraph.cfg

So, with such a configuration installed, there are the AllegroGraph clients, and a bit more of TCP/IP networking. Beyond a context of VirtualBox host-only networking, a framework for SSH port forwarding could be applied, on top of the VirtualBox port forwarding.

Presently, this thesis article will jump, by a certain distance, to develop some concepts about object models. The development of that aspect of this thesis article must naturally entail a presentation about some concepts developed in CLIM. This article will now assume an outline format, towards an overview about CLIM.

CLIM - An Overview

• Interaction
• Menus
• Key bindings
• Modeline
• Presentation
• Presentation types
• Presentation methods
• Device Interface
• CLIM port
• CLX port
• GTK Cairo port
• ...
• HCI structures in CLIM applications
• CLIM Graft and Sheet objects
• CLIM Frame objects
• The application frame class
• ...
• CLIM Pane objects
• The application pane class
• ...
• Objects displayed on a CLIM pane
• Geometric objects via CLIM drawing forms
• Text via CLIM drawing forms
• Presentations
• ...
• CLIM and Common Lisp
• Streams in CLIM
• ...
• CLIM and X.org
• XLib
• CLX
• Adding support for XFree86 shared memory extension 
• TBD
• Input methods
• Integration with window managers
• Integration with desktop environments
• ...
• CLIM and text media
• ...
• ...
• Climacs
• ...
• CLIM and CORBA
• TBD - Thesis not yet developed

Secondly, this article will now develop an outline focusing on Franz AllegroGraph as an RDF information service.

Towards developing a CLIM layer for AllegroGraph - Notes / Outline

• Presentation Types
• Triple Store / DB
• Triple
• subject, predicate, object
• graph
• triple ID
• Resource
• Unique Part Identifier (UPI) strings
• Class
• RDF Schema
• OWL
• Annotation properties
• rdfs:label
• skos:altLabel
• skos:prefLabel
• skos:hiddenLabel
• Graph Display
• Graph 'link' properties
• e.g. SKOS broader / narrower properties
• Graph layout
• Radial graph
• Hyperbolic graph
• Tree graph
• Resources may appear multiple times in a tree graph hierarchy
• Resource aliasing for individual presentation in tree graph
• Graph Management
• Graph Management Actions (Default)
• Open graph service connection (i.e. connect to graph server)
• Create graph DB
• Delete graph DB
• Rename (?) graph DB
• Close graph service connection (i.e. disconnect from graph server)
• Graph Management Panes
• List of "registered" graph DBs
• Registry by way of application of ... something compatible with CORBA object services (TBD) (Persistent naming, etc)
• TBD: Implementing an access control layer onto AllegroGraph triple stores
• Fundamental service interface model
• Implementation as an adapter
• Graph service: AllegroGraph
• Display management: CLIM
• Integration with CORBA
• TBD - more towards providing a triples-graph service for other graph/SPARQL servers in Common Lisp or Java
• Usage Cases
• TBD

Lastly, this article  will endeavor to develop a platform-agnostic view about RDF media and CLIM -- again, presented here in an outline format.

Broader Context: CLIM + Semantic Web (A Generic Model)

• RDF Resources // URI Referencing
• See also: ODM
• Generic  model for collections of RDF tuples
• Concept: tuples-index
• Registration of RDF namespace per triples-index
• Classification of ontologies
• Application: Per-ontology presentation method selection
• Examples // Use Cases
• Presentation methods for SKOS Concept classes
• Presentation methods for RTM Topic classes
• Selection criteria for classification in resource => presentation type assignment
• RDF namespace of resource's RDF URI
• Type of entity (RDS class, OWL class, RDF property, OWL object property, OWL datatype property, OWL annotation property, XSD type)
• Properties defined to entity
• Requires a full-graph search initially
• List of properties may be updated on graph change
• Concern: Concurrency
• RDFS/OWL Classes & CLIM Presentation Types
• RDFS/OWL classes available only in connection to any single tuples-index
• Presentation types may be defined as in association to an individual RDF namespace
• Presentation types may be defined as in association to an individual tuples-index
• Presentation types may be defined in individual source trees
• Such source trees may be referenced as in an index or transformation of the URI of any single ontology namespace (?)
• ? Internal table for registration of presentation types for reference via presentation methods
• Concept: Presentation of tuples
• Classic presentation mode: subject, predicate, object
• Presentation of each of a subject, predicate, object will be affected by presentation method defined for each individual resource referenced in that field of each tuple
• Concept: Presentation of reified tuples
• Append 'button' area for activating presentation layer for reification data
• Project: Object model for SPARQL
• CLIM layer
• Concept: Table view (onto SPARQL)
• per each column
• An RDF/OWL property
• Column displays resource denoted in that property
• A column heading
• per each table
• SPARQL query (as an object)
• "Key" column[s]
• applicable for sorting in table display
• Concept: Graph view (onto SPARQL)
• Concept: Metadata view (onto any single set of specifications/standards/conventions in a context of linked open data )
• Arbitrary
• Usage cases (blue sky?)
• Bibliographical display and editing [application]
• "FOAFpedia" app
• Integration platform (app) for collation of bibliographical information
• Bibliographical information for "Good Jedi"
• Is not LinkedIn
• Is not Encyclopedia Britannica, etc
• Bibliographical information for "Dark side of the moon"
• Is not INTERPOL's single registry or analogous national registries
• Topic maps
• Alternate to "Mind maps"
• Concerns
• Implementation in CLIM
• Integration with file media
• Integration with desktop/mobile computing systems
• Resource graph as a central data service on each platform
• Resource graphs on desktop platforms
• Nepomuk
• TBD
• Resource graphs on mobile platforms
• See also: androjena
• Resource graphs on enterprise server platforms
• (?)
• Service model
• Interface model
• Resource=>application dispatching on Android platform - i.e "Open with..."
• See also: 
• Java Content Repository (JCR) (2.0)
• JSR-283
• Implementations (Java)
• Modeshape
• Apache Jackrabbit
• DOM L3 Load & Save
• Towards a streams model for CORBA
• Integration with web media
• See also
• Vincent, Cristopher R. W3P: A Portable Presentation System for the World-Wide Web
• Presentation: Article
• Presentation: Slides
• HTTP Services - Common Lisp
• CL-HTTP at NTT-Data
• Hunchentoot
• Concept: HTTP as an application-layer service
• OSI seven layer model
• TCP sockets
• Trivial request/response cycle
• Response codes
• HTTP 1.1 - See also
• In Proceedings: The Eighth International  World Wide Web Conference (1999)
• Krishnamurthy et. al. Key Differences between HTTP/1.0 and HTTP/1.1   
• Kaplan and Oldham. Managing TCP Connections under Persistent HTTP
• HTTP proxying
• WebDAV
• Concept: HTTP as a CORBA object service
• Web resource as object
• Accessible via HTTP/HTTPS
• Identified with a request URI
• Related: Request method (GET, POST, etc)
• May require persistent state data for access
• Persistent client identity data (cookies)
• Writable via WebDAV
• CORBA
• ODM

Towards a set of concepts for a separate focus article:

• Prolific mobile computing
• Mobile operating systems utilizing the Linux kernel
• Android platform
• Manufacturer-specific applicaitons
• Firefox OS
• Apple iOS
• BlackBerry
• See also: QNX
• Prolific laptop computing
• Google Chromebook
• Also based on the Linux kernel
• Microsoft Windows laptops
• ...
• Ubuntu laptops
• HP TouchSmart laptops
• FreeBSD desktop distributions
• ????
• Computing in Small Office/Home Office (SOHO)  Environments
• Software Defined Networking (SDN) as scalable online service platform
• Amazon Web Services (AWS)
• OpenShift Origin
• Digital Ocean
• ...
• System on Chip (SoC) platforms and single-board computing platforms
• Texas Instruments AM35xx Sitara SoC
• BeagleBone Black
• Allwin A20 SoC
• Cubieboard 3 (Cubietruck)
• Broadcom BCM2835 SoC
• Raspberry Pi
• Alternate design concept: Computer on module (CoM)
• Juxtaposed to SoC as a design concept
• Commercially, another delivery platform for manufacturer's microcircuit designs
• e.g. Gumstix
• Company profile at Texas Instruments
• See also: Gumstix Gepetto

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
• ...as 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:

• Steel Bank Common Lisp (SBCL)
• Clozure Common Lisp (CCL)

...at 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:
• YouTrack
• Bugzilla
• Request Tracker
• GNATS
• Debian BTS
• Bug tracking in Canonical's Launchpad system
• May entail some platform-specific focus about Linux
• The following mobile platforms implement Linux:
• Maemo
• Android
• Fire OS (Kindle Fire)
• Firefox OS
• Chromium OS
• Any single single-board computing platform on which Linux is available
• BeagleBone Black (BBB)
• Can run Android, more specifically. See also: Rowboat
• Raspberry Pi (RPi)
• Gumstix
• Etc.
• RTOS features "To be determined" by platform (TBD)
• 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.

A Review of Geometric Features and Visual Models for Radial Graph Presentation

This evening, I've been endeavoring to develop something of an idea as to how CLIM may be applied for drawing hyperbolic graphics onto CLIM panes -- focusing on McCLIM,  for such application, namely as with regards to the MetaCommunity.info (MCi) fork of the original McCLIM codebase.  Although this initial study would be non-trivial, namely to my own limited academic knowledge of mathematical systems, but it's my hope that I may be able to trudge my way through this study, to develop something of an idea for a functional application of existing theory about hyperbolic graphs -- if not the broader algebraic topology -- namely towards a design of a new graphing component for McCLIM.

Reading [KobourovS2005], this evening, the authors denote two popular approaches for mapping a graph in the hyperbolic space onto the Euclidean plane:

• Poincaré Disk Model
• Beltrami-Klein Projections.

There are two additional approaches denoted by [ParksH]

• Poincaré Half-Plane Model
• Hyperboloid

This article, as a short collection of notes, will presently focus on the presentation in [ParksH]

• Beltrami-Klein Projections
• Named after the work of Eugenio Beltrami and Felix Klein (ca. 1870)
• Euclidean space is constrained by a disk, for purpose of the projection
• Points are defined within the circumference of the disk
• Lines are presented as chords between points
• For points A, B not on the circumference of the disk, the geometric extension of each of A and B to the circumference of the disk -- respectively, to points P, Q -- may be required for some calculations -- such as to calculate the projected distance between points A and B:
• d(A,B) = 1/2 |log (AP*BQ) / (BP * AQ)|
• For a A  situated on the circumference of the disk, A is denoted as an ideal point
• The pole C for two points A, B, is the point on the Euclidean plane at which the lines defined as tangent to each of A and B meet in an intersection. C, of course, is not within the space of the disk
• Concept of parallelism: Lines are parallel if they do not intersect within the area of the disk
• Concept of perpendicularity: 
• For line M being a diameter of the disk, N is perpendicular to M  -- in the hyperbolic projection -- if N is perpendicular to M in a a sense of the Euclidean coordinate space
• For lines M and N not being a diameter of the disk: N is perpendicular to M, only if the geometric extension of N beyond the area of the disk would intersect the pole of M.
• Angular measure: TBD
• Poincaré Disk Model
• Named after the work of Henri Poincaré (ca. 1880)
• Likewise, Euclidean space is constrained by a disk, for purpose of the projection 
• Likewise, points are defined within the circumference of the disk -- excluding the circumference or boundary of the disk. See also: [TernesM] 
• For a circle -- as a geometric object -- defined within the hyperbolic projection, the circle has essentially two functional center points -- one for the circle in the Euclidean space, and one for the circle in the hyperbolic space, as projected onto the Euclidean space. See also: [TernesM], which the following sub-points are in reference to
•  The midpoint of a line likewise has two coordinates -- one in the Euclidean space, and one in the projected hyperbolic space
• The definition of an angular bisector must also be calculated for the characteristics of the projection
• Two types of line, for points A, B:
• A diameter of the disk, passing through points A, B
• An arc passing through points A, B and ending as orthogonal to the circumference of the disk (see also: [VenemaG] p. 97, ch. 14) 
• Concept of parallelism (arcs) : That the arcs M, N do not intersect at any point within the disk
• Concept of perpendicularity: That two lines M, N meet orthogonally i..e at a right angle (See also: Angular measure)
• A relatively easy matter to calculate, computationally, for two lines that are diameters in the Poincaré Disk projection
• Less relatively easy to  calculate, if either or both of M and N is an arc
• to calculate the projected distance between points A and B, with ideal points P and Q:
• d(A,B) = |log (AP*BQ) / (BP * AQ)|
• This is expressed in [VenemaG]  (p. 97, ch. 14) as follows:
• d(A,B) = |ln(AB, PQ)|
• Angular measure: "To measure the angle between two lines in a Poincaré Disk, you measure the Euclidean angle between their tangent lines."
• TBD: Some ambiguity as to what the term tangent line may mean, in that definition. In any interpretation, that definition would be constrained only ti arc type lines within the disk
• If the term refers to a line draw tangent to a point on the circumference of the disk,  and external to the circumference, but for any line AB, there would be two tangent lines in that interpretation. Those lines, of course, would be parallel if AB describes a diameter of the disk.
• If the term refers to a line drawn tangent to each endpoint of an arc -- namely, at the points where the arc meets the circumference of the disk, ortogonally -- then for any line AB, there would be only two such tangent lines, both meeting on the Euclidean plane, at a point within the circumference of the disk
• In either interpretation, there would be -- respectively -- four or two individual tangent lines for each arc. It would then be effectively impossible to measure the angle between tangent lines for two intersecting arcs
• In a third interpretation: The term tangent line, in that application -- and namely, for an arc type line -- might refer to a line drawn tangent to the arc, at the point of the intersection. For a non-arc type line, the line itself might be used for the determination of angle, at the intersection. This is probably the correct interpretation of the term. See also: [WolframP]
• Limit Rays: Arcs that meet at a common point on the circumference of the disk [WolframP]
• The author describes a method for projecting a Beltrami-Klein Projection onto the Poincaré Disk Model

Of course, the hyperbolic trigonometric functions may have some applications in a graphing model for information visualization. See also: [KobourovS2005][KobourovS2012]

For a more in-depth analysis of the geometry of the hyperbolic space in the Poincaré Disk projection, see also: [SchutzA]

The qualities of the abstract geometric spaces of these projections would certainly make for a lengthy study, to the student of mathematics. Concerning a question of how these projections may be applied for information visualization, there are some many illustrations provided in [KobourovS2005] and [KobourovS2012]. Perhaps it may be well to consider some additional models, furthermore -- not limiting the discussion to the set of known hyperbolic projections. 

Certainly, there is a significant variety of information visualization models  defined in the information sciences. [HermanI] Particularly, either of the Cone Tree / Relative Disk Tree (RDT) projection models proposed in [JeongC] or the model proposed in [MelanconG] might serve to define a visually appealing graph with a minimum of spatial compaction, in a visual model for a directed acyclic graph (DAG). 

Towards development of an ontology model, such as may be suitable for construction of a DAG view: In an application of SKOS,  as within an OWL ontology model, it may be advisable to ensure that every object property defined in the ontology will be a subclass -- whether directly or indirectly -- of exactly one of the object properties, skos:broader or skos:narrower, With that level of consistency in an ontology, and given any single individual instance M1 within the ontology, it would be possible to define a simple algorithm for computing the descendants of M1 by following the graph of skos:narrower relations -- directly, or as the compliment of skos:broader - for all property expressions within a specific instance of applying the graphing algorithm. to the ontology, selecting each property of which M1 would be a subject, then subsequently taking each object of the relation as the subject for a subtree, for any number of object properties selected in any one instance of applying the graphing algorithm -- the graphing instance being constrained, for purpose of brevity, constrained to any number of generational iterations of the algorithm.

Of course, although the graph display procedures might be the most time-consuming features to design for an ontology visualization system -- as to display any single structure of any single graph of individual instances and their object property relations, within an OWL ontology -- however, a graph itself may not serve to convey all of the information presented in an ontology. 

In at least, a complimentary table/page view model might be applied, as to create a focused view for display of ontologically structured information for any single individual instance within the ontology. The table/page view might be applied, moreover, as to allow for a convenient editing onto the set of ontology properties defined to any single individual instance. 

Considering the effective depth of complexity that this article has now arrived to, this article will conclude at the simple remark: "TO DO: Study"

Some additional works were discovered, during the research for this article, namely as with regards to hyperbolic projections onto the Euclidean space. [ChepoiV][BowditchB]. 

[KobourovS2005] Kobourov, Stephen G and  Kevin Wampler. Non-Euclidean Spring Embedders  (2005)
[ParksH] Parks, Hal. The Poincare Disk Model and The Klein—Beltrami Model.
[VenemaG] Venema, Gerard A. Exploring Advanced Euclidean Geometry with Geometer's Sketchpad. Archived
[WolframP] Wolfram MathWorld. Poincaré Hyperbolic Disk
[SchutzA] Schutz, Amy. Hyperbolic Functions.
[TernesM] Ternes, Megan. Tangent Circles in the Hyperbolic Disk
[KobourovS2012] Kobourov, Stephen G. Spring Embedders and Force Directed Graph Drawing Algorithms (2012)
[HermanI] Herman, Ivan , Guy Melançon , and M. Scott Marshall. Graph Visualization and Navigation in Information Visualization: a Survey
[JeongC] Jeong, Chang-Sung and Alex Pang. Reconfigurable disc trees for visualizing large hierarchical information space. See also: [Related]
[MelaonconG] Melançon G and I. Herman. Circular Drawings of Rooted Trees
[ChepoiV] Chepoi, Victor et al. Diameters, Centers, and Approximating Trees of δ-Hyperbolic Geodesic Spaces and Graphs
[BowditchB] Bowditch, B. H. Relatively Hyperbolic Groups

State of the MetaCommunity McCLIM fork - Apps "OK," fonts "Up in the air"

In my own small efforts in software programming, this year, I've made a fork of McCLIM -- a short overview provided in a previous 'blog entry, here at my DSP42 web log. It's been to nothing too sensational, as yet. I've made simply a few maintenance updates, and have added a dependency onto the mci-cltl-utils software system -- that much, as for applying a DEFCONSTANT* macro within McCLIM. 

Certainly, there are still some more maintenance updates to develop onto the fork, before getting along to any new developments onto McCLIM. In that regards, the last issue that I'd observed of it was that the font selector example is failing. It would appear to be due to something in regards to the interface onto the fonts table in CLX. Perhaps, that may easily resolved, insofar as the the present state of the source tree.  I think it serves to call some broader concerns to mind, however, insofar as developing an application architecture for Common Lisp desktop application development, within a contemporary computing environment.

Broadly, I've been using the Sharplispers CLX fork of Texas Instruments' original CLX codebase, and the CLX backend for McCLIM. I've tested a number of the applications provided in McCLIM, using the CLX backend. Specifically: The McCLIM listener, inspector, and debugger can be verified as running successfully, with that edition of CLX and on SBCL 1.2.5.76-65a44db. Furthermore, the Scigraph application has been updated to run by-in-large successfully, on that same platform, although again there are some maintenance issues with it.

I've also tested Climacs, on that platform. It runs successfully, too.

I'd tried applying the GTK Cairo backend for McCLIM, but without a lot of success in that port, presently. With some regrets, that may serve to make it more difficult to apply McCLIM onto mobile platforms. I had hoped that the GTK Cairo backend might've made a good component to apply for McCLIM on an Android platform, and well it still may. Presently, if it does not successfully run on so much as a contemporary Ubuntu Linux platform, then there's not much to show for it, at present.

One superficially minor change now developed in McCLIM: In regards to CLIM's multiple-value-setf behaviors, it should now be  portable onto ECL and CCL (ARM architecture), as well as SBCL (amd64) insofar as free/open source Common Lisp implementations. 

With regards to fonts: When adding a set of ASDF system definitions to the fork that I've made of the original Garnet source tree, I'd observed that Garnet is now extended with Truetype font support, such that utilizes CL-Vectors and extensionally, ZPB-TTF for providing a support for TrueType fonts onto CLX . The clx-truetype system may be applied not exclusively onto Garnet, though it is integrated with Garnet as in the gem-font-methods file in the same source tree.  One might hope that it would be fairly trivial, to apply clx-truetype likewise onto the CLX port in McCLIM. Insofar as with regards to fonts and typesetting in CLIM itself, there -- I think -- is one of the broader concerns of the matter. To a few superficially simple questions:

• How may it be possible to provide functions for denoting superscript or subscript typesetting, in CLIM?
• If not, then how may such functions be defined effectively onto McCLIM?
• To what practical ends may such developments be focused?
• May it be possible to implement the entire Cascading Stylesheets visual formatting model onto CLIM? Specifically, of CSS 2.2?
• Note: `vertical-align` and related properties in the CSS model for inline blocks
• Extensionally: How may it be possible to implement an entire MathML interface onto McCLIM?

Such questions might seem trivial, at the outset.

If the CSS 2.2 visual formatting model may be implemented onto McCLIM, perhaps it may be implemented as to extend of MetaObject Protocol. Hypothetically, any one or more metaclasses may be defined as to allow for a modular  implementation of the CSS 2.2 visual formatting model, such that the implementation may also be portable onto XSL Formatting Objects (spec version 1.1). Sure, it would be nothing too conceptually original, to develop an application protocol that may extend of both and that may be integrated with McCLIM, furthermore -- even insofar as for representation of text according to textual formatting specifiers. Historically, there's also DSSSL

XSL-FO and DSSSL may be particularly suited to a page-oriented media, if not specifically a page-oriented model for graphical user interface design. Insofar as page-oriented media in CLIM, of course there's also the McCLIM PostScript backend

Orthogonally, an implementation of SVG onto McCLIM may seem pragmatically "Out of the question," at this time. Though it would serve to keep pace with contemporary widget toolkits defined in C and C++ -- such as Qt, GTK, and Cairo, all of which provide support for rendering of graphics developed in a medium of SVG -- however, it may represent another distinctly non-trivial design issue to approach in any single fork onto McCLIM.

Of course, the design proposed of the Dobelle-App system -- as specifically with regards to development of mobile  applications in Common Lisp -- it would require that McCLIM or any other single graphical user interface toolkit would be suitably applicable in Common Lisp on a mobile platform, as well as on a desktop platform -- furthermore, beyond simple "Proof of concept" implementation. If a framework may be developed and applied for CLIM applications on desktop and mobile platforms -- not only for backing of a thesis article, but furthermore as a framework for commercial application development -- it would well need to be provably applicable in a commercial domain, in every feature of such a framework.

Still, such a matter may seem trivial, at the outset -- and well, there are so many novel things to take to attention, otherwise?

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.

An Introduction to the MetaCommunity.info fork of McCLIM (Overview - Initial Outline)

Ed. Note: This article represents a preliminary outline for an overview about the MetCommunity.info fork of McCLIM, focusing primarily on the YouTrack InCloud instance presently applied for management of the same fork project.

Pending subsequent revisions of this article,  this initial revision of the article may serve to provide, at least: Some web references onto task lists as created for and of the same project; an overview about YouTrack, in basic outline format; an overview towards the structure of a meta-IDE project developed under the MetaCommunity.info domain.

Items denoted wit {Bracketed Text} will be subject to revision, in subsequent versions of this article.

Overview

{i.e. topical introduction}

{GUI Domain in Common Lisp Application Development}

{McCLIM development}

{MetaCommunity.info (MCi)} {work journal}

{MetaCommunity.info fork of McCLIM}

{Sidebars: Traditional CLtL HCI APIs including: McCLIM; Garnet; Cells GTK; Graphic Forms}

{Sidebar: McCLIM' gtkairo backend; FirefoxOS}

{Projects Management Domain in Common Lisp Application Development}

{Concepts for which there are some exacting, conventional "web service bundles"}

• Repository management (Github; GitLab; ...)
• Continuous Integration (TeamCity; Travis CI; Jenkins; ...)
• Issue Tracking (Gnus; RT; Bugzilla; YouTrack; ...)

{Concepts for which there are assorted tools - applied at project managers' own discretion}

• Documentation development {authoring, editing, publishing, maintenance}
• Release management {develop=>test=>release=>maintain}
• Distribution management {binary distributions - archives/packages/installers by platform and version; source distribution available via repository management service}
• Web presence management {social networking; documentation; resource distribution}
• {For web hosting, alternatives include}
• Static-Content Web Site
• Hybrid Static/Dynamic Content Site
• PHP
• Python
• JSP
• ...
• Web Site Published via Java Archive (formats; JAR, WAR, EAR, ... varying by container)
• Variation of hybrid static/dynamic content site 
• {JSR-... - Java servlets}
• Web Portal
• {In Java} A variation of Web Site Published via Java Archive
• {JSR-..., formal portal request/response cycle}
• Alternatives
• JetSpeed {static portal}
• ...
• Liferay
• {In Other: In programming languages other than Java, portal implementations include Drupal (Python), ...}

 Ed. note: In a sense, "Issue tracking" presents a "Meta-concern," applicable at all phases of a project's formal duration.

{YouTrack} {Stand-alone} {InCloud}

{YouTrack InCloud} {Documentation} {Qiuck Start} {Presently, InCloud is backed by YouTrack 5 [xref]}

{YouTrack License Model}. {10 user limit for 'Free' editions, in stand-alone or InCloud installation}

{MCi instance at YouTrack InCloud (Guest login enabled)}

{An Outline Onto Concepts Implemented in YouTrack}

{Project information structure at YouTrack}

• Projects
• Items
• Swimlanes
• Issues
• Tasks

{Conceptual View}

• Colloquially, Agile Project Management Concepts
• Scrum
• Sprints
• ...
• ...
• Project Life Cycle
• ...
• ...

{YouTrack Web Interface}

Items of note in MCi McCLIM YouTrack InCloud service:

• Dashboard (configurable by users)
• Agile Boards
• Example: Agile Board for Issues noted to initial 0.9.7.1 sprint
• Example: Agile Board for Issues not scheduled to a sprint
• Task List
• Example: All Swimlanes, Tasks, and Issues
• Task Searches
• Example: Unresolved, Unscheduled issues related to MCi McCLIM Fork 

Article Metadata

Revision History

• 1.0 (20 Nov 2014) - Basic Outline
• 1.1 (20 Nov 2014) - Web and Metadata
• Add details onto web presence management , focusing on web hosting models
• Add Article Metadata Section
• Add initial tags to article: MetaCommunity, McCLIM, CLIM, ANSI CL, CLtL2, YouTrack

Towards an IDE Model for McCLIM (Draft 2)

Outline:

• McCLIM
• implements the Common Lisp Interface Manager (CLIM) within a free/open source software licensing model
• available with an "adapter", formally a "graft" for a number of window systems and GUI platforms, including X11 (CLX) and Cairo UI (GTK Cairo) 
• CLIM defines the class, application-frame
• The class clim:application-frame may be extended to define a class, ide-frame
• The class ide-frame may be defined such as to provide a convenient baseline for development of graphical IDE view elements
• A configuration parser  may be defined as associated with the class, ide-frame
• IDE view elements may be defined in a manner reminiscent of graphical application interface elements as defined within popular IDE tools, such as:
• Filesystem view
• parameter: Root filesystem pathname (pathname directory)
• parameter: Filesystem element filter function 
• arg: filesystem pathname
• return: boolean "display-p" value
• File view
• parameter: File pathname
• associated concept: File view controller
• define as a CLOS class, file-view-controller
• dispatch on filesystem type, e.g. (defgeneric get-file-view (file controller))
• initialize class and bind to *default-file-view-controller*
• reference class of file view controller within IDE configuration data
• Workspace view
• Extend on workspace definitions created by Eclipse IDE
• define parsers for workspace metadata as created by the Eclipse IDE 
• include "check" for "workspace in use", preventing access to files within a "workspace in use", to minimize concurrency conflicts during file editing
• Workspace URI, index, and structure -- CORBA (TO DO: IDL Interfaces)
• SCCM views
• SCCM local source tree view, and SCCM repository view
• dispatch SCCM view selection per type of SCCM system in use within a root SCCM directory
• incorporate with an interface (FFI, shell commands, or Lisp) onto each supported SCCM model (cf. Emacs VC Mode)
• Observe that a local source tree for an SCCM system such as Git would be, simultaneously, a local source tree and an SCCM repository 
• SCCM repository URI and index system -- CORBA (TO DO: IDL Interfaces)
• Toolchain views
• Reminiscent of Eclipse IDE perspective definitions (???) but focused on discrete classes of toolchain elements
• Toolchain category: GCC
• Tooclhain category: Lisp interpreter
• ...
• To do: Prototype sometime after defining a CLIM adapter i.e. "graft" and/or CLIM widget layer onto CommonQt (?)
• Requirement: Suitable HCI responsiveness
• Alternate consideration: Native XLib FFI interface (CFFI)
• Implement: X11 SHM interfaces
• Limitation: Further complexity in CLIM HCI model on Microsoft Windows platforms
• The Microsoft Windows Explorer Desktop Shell is not X11R6
• cf. XMing and/or Cygwin
• Limitation: Applicability of Shared Memory models in Common Lisp applications
• Objects referencing shared memory
• Shared memory references should remain immutable (?)
• Alterate consideration: Use GTK Cairo interface on Microsoft Windows Platforms
• GTK Cairo integration for mobile OSes?
• Firefox OS (?)

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.

Towards a Multiple Value SETF in ECL

Today, I've started working on a fork of McCLIM, for adding support for ECL in McCLIM --  nothing too ostentatious, perhaps simply towards implementing CLIM on thin client architectures such as BeagleBoard Black (BBB) and Raspberry Pi (RPi) with the respective TFT display implementations. (Those two platforms, BBB and RPi, those use ARM MCUs. So does my Samsung Chromebook)

As ever, it's proving to be an invaluable learning experience. This evening, in particular, I've been studying the specifications about SETF forms for ANSI CL, and moreso the implementation of the same, in ECL. I've discovered that in ECL 11.1.1 -- broadly -- a multiple value SETF implementation is possible via DEFINE-SETF-EXPANDER, such that a message in the c.l..l newsgroup had once denoted.

The following form may serve to demonstrate something towards how a multiple value SETF may be implemented, in ECL 11.1.1

(in-package #:cl-user)

(defun foo* (x)
  (values (1+ x)
   (1- x)))

;; (foo* 5)

(define-setf-expander foo*  (x &environment env)
  (multiple-value-bind (dx vx nvx sx gx)
      (get-setf-expansion x env)
    (let ((misc-x (gensym "X-"))
          (misc-y (gensym "Y-")))
      (values
       (list misc-x misc-y)
       (list x)
       (list misc-x misc-y)
       ;;  ^ KEY. The third return value is where
       ;;   to specify the multiple value bindings
       ;;   for a multiple-value setf in ECL 11.1.1.
       ;;
       ;; Those bindings may then be utilized in the
       ;; Lisp form specified in the fourth retv :
       `(progn (setf ,gx (1+ ,misc-x))
               (values ,gx ,misc-x ,misc-y))
       `(foo* ,gx)))))


(let ((a 1) (b 2) (c 3))
  (get-setf-expansion
   '(foo* a)))


(let ((a 1) (b 2) (c 3))
  (setf (foo* a) (values b c))
  #+NIL a)
=> 3, 2, 3

Towards implementing multiple-value-setf in McCLIM + ECL, it seems that the main "Work area," for that, is in the  McCLIM source file, `setf-star.lisp`, namely in regards to the implementation of the CLIM specification's defgeneric*  and defmethod* macros. Those macros are then used in the McCLIM source file, `region.lisp`

Certainly, such an application of the third return value for DEFINE-SETF-EXPANDER, it would serve to sort of obviate the application of the setf-expander's lambda list -- perhaps, it introducing, in effect, another variable binding, within the closure of the setf expander, such that the variable to which the binding is made would not be indicated in the explicit lambda list for the setf expander.

Though not explicitly prevented in ANSI CL (as per the CLHS), it is neither  explicitly supported nor specified by the same. Inasmuch, that methodology may or may not be applicable in every ANSI CL implementation, and might not be consistently applicable, in any singular ANSI CL implementation.

As towards the CLIM + ECL regards: "More to follow," perhaps, after a pause -- as towards a "Second wind" -- so to speak -- and then implementing CLIM:DEFGENERIC* and CLIM:DEFMETHOD* in ECL, onto McCLIM. Then perhaps, towards developing some regression tests for the same implementation -- there's an "RT" in a CXML+Contribs toolchain, at that. In a "Blue sky" timeline, perhaps something towards defining a CLIM graft for a direct TFT display (not using X.org or framebuffers, though of course using an interface in the Linux kernel) on the single board computer platform, BeagleBone Black, ostensibly in ECL.