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 Break for When Lisp Does or Does Not Make Error - Notes

I was working on some of the documentation for AFFTA, this morning, when I arrived at a concern concerning non-local exit of control within Common Lisp software programs.

The following Common Lisp software code does not result in the warn form being evaluated:

(handler-case (break) (condition (e) (warn "Got ~S" e)))

As would be indicated within the interactive debugger, the evaluation of break creates a condition object, but that cannot be retrieved by way of handler-case. Neither can it be retrieved with handler-bind

(labels ((condition-warn (e) (warn "Got ~s" e)))
  (handler-bind ((condition #'condition-warn))
    (break)))

In either instance, the break form results in a non-local exit of control. Moreover, a condition object is created during evaluation of the break form, and that condition object cannot be accessed via either of handler-case or handler-bind.

Reviewing the CLHS entry for break, it's apparent that the continue restart can be bound, such that may allow for a program to define an arbitrary "Break  handler" -- but more broadly, that may be applied in instance of break or cerror, if the restart would be "Reached" in either instance, from within the call-tree of the executing program.

Presently, I'll take note here at my DSP42 blog that a concept of a call tree may permit for some further explanation, to a level of detail concerning any specific operating system. While developing documentation for the illustriously named dobelle-app source tree, I had discovered some documentation about process and thread implementation specifically in the Linux kernel. I would summarize the same documentation, briefly: That in a sense like established of the Linux kernel: A single thread allows for exactly one flow of execution; a process serves effectively as a container for one or more threads, and would have at least one thread representative of the process. In LinuxThreads, one thread would be the controlling thread of the process. The concept, thread groups, would be orthogonal to the differentiation of such definitions of process and thread. I'd made a more formal reference to that documentation, in the README file for the dobelle-app source tree.

Returning to the item of documentation that I was developing, this morning, for the AFFTA source tree: In that matter, the concept of a call tree occurs if simply in addressing a design goal, that the AFFTA test executor should be  able to capture a condition object for representing any non-local exit of control from within an object of test, within a Common Lisp software program. The function, break, would present a specific concern towards that goal, as that it then requires a definition of a specific continue restart, to appropriately handle the non-local exit of control from break. In that sense, an "Appropriate handling" would entail: That the test executor for a test object, in testing a specific object of test via a specific function, would denote that the continue restart was reached from within the same function.

With regards to restarts in Common Lisp, a subset of items denoted in the CLHS Conditions Dictionary:

• restart-bind
• Allows for definition of a primary restart function, as well as optional, separate interactive function, report function, and test function
• Concerning the primary restart function
• See also: invoke-restart
• Concerning the report function
• Function must accept a single argument, namely a stream
• This function will be applied by the Lisp printer, when a restart is reported and the value of *print-escape* is nil 
• May seem semantically similar to the :report feature of a condition class. 
• An application for controlled interaction with a Lisp environment may provide a single class of object such that an interface for condition handling may inherit -- as may be applied in systems development -- as well as an interface for restart handling, such as may be applied by a desktop environment, for managed interaction within the debugger -- viz a viz *debugger-hook*.
• Concerning the interactive function
• Function must accept zero arguments
• Concerning how this function may be applied, refer to invoke-restart-interactively
• Concerning the test function
• Function must accept a single argument, namely a condition object
• This function allows for an application to determine whether a restart is visible
• Concerning how this function will be applied, refer to restart-bind and implementation-specific source code.
• Possible applications may include, hypothetically:
• Within an application within a graphical desktop environment, the test function may be applied as to to determine whether a specific restart is visible, as per whether a device is active for interaction with/via the graphical desktop environment.
• For application within a remote server environment: Similar, albeit with some small complication in regards to interaction
• restart-case
• See also: invoke-restart and invoke-restart-interactively
• find-restart
• Caveat: find-restart must be provided with either a restart or a non-nil symbol.
• Consequently: find-restart cannot be applied as to locate a restart that is not a named restart. 
• See also: compute-restarts 
• invoke-restart and invoke-restart-interactively
• Essential concepts: 
• A function is assigned to a restart
• A function may be assigned to a restart, with either restart-bind -- in which a function is implicitly assigned to a restart, prior to the evaluation of a form -- or with restart-case, in which a lambda form is provided, though not explicitly to a definition of a function, in assignment to a named restart or a restart not a named restart. With either form, compute-restarts should compute the list of restarts specified in the form, including those restarts effectively shadowing any restarts otherwise established within the active lexical environment.
• Related concept: Not all restarts are named restarts
• For a restart that is not a named restart, the function restart-name returns nil
• with-simple-restart
• Allows for definition of a single, named restart, within the lexical environment of a form to be evaluated
• The Examples section for this macro,  in the CLHS, provides a further demonstration of how multiple restarts may be defined with the same name, within differing lexical environments, essentially for differing applications of a single restart. In the first example in the CLHS Examples section for this macro: A restart function is bound for the abort restart, first and immediately within the lexical environment of a simple, example REPL function, then secondly within the loop form defined within the REPL function. The two bindings for the abort restart are different, then, as to where control will exit to, when the restart is invoked. 
• Also in the Examples section in the CLHS, for this macro's reference page, there is a further example as to the relevance of the debugger as an interface for selecting a single restart, interactively
• with-condition-restarts
• compute-restarts
• Conventional restarts
• continue
• may be used in break and cerror
• Corresponds to the function: continue
• abort
• CLHS: "The intent of the abort restart is to allow return to the innermost ``command level.'' Implementors are encouraged to make sure that there is always a restart named abort around any user code so that user code can call abort at any time and expect something reasonable to happen; exactly what the reasonable thing is may vary somewhat."
• Corresponds to the function: abort
• store-value
• CLHS: "generally used by handlers trying to recover from errors of types such as cell-error or type-error, which may wish to supply a replacement datum to be stored permanently"
• Corresponds to the function: store-value
• Concerning application for handling errors of types cell-error and type-error, see also: handler-bind and handler-case
• use-value
• CLHS: "generally used by handlers trying to recover from errors of types such as cell-error, where the handler may wish to supply a replacement datum for one-time use."
• Corresponds to the function: use-value
• Concerning application for handling errors of types cell-error and type-error, see also: handler-bind and handler-case
• Implementation specific concept: Restart as object, moreover an instance of the system class cl:restart
• As per CLHS [CLtL2], the system class cl:restart has an effective accessor, restart-name. Other accessors may be defined, extensionally, per each implementation, though such extensions -- if venturing beyond the design of any single implementation -- may appear to exceed the limitations for portable software exclusively under the CLHS
• SBCL: cl:restart is implemented as a structure class
• Other implementations: Likewise, an implementation-specific feature

Of course, this simple study would bear some relevance towards the development of the dobelle-app source tree, as well as its initial relevance with regards to the AFFTA source tree. Certainly, CLtL restarts would be among the features that a Dobelle application may provide an additional interface for, ostensibly towards more of convenience for application development in the Common Lisp programming environment.

A few of initial ideas, towards debugger support in Dobelle:

• The extent to which the debugger may provide any useful information to a developer will be affected by the extent to which the software -- specifically, as in the lexical environment of each function call in the backtrace of function calls leading to entry to the debugger -- was compiled with any support for debugging
• The debug optimization in Common Lisp allows for at least three specific levels of debugging
• The amount of debugging information retained within compiled software may also be affected by other optimization settings, such as for speed, safety and space
• Concerning applications of Common Lisp on interactive mobile platforms: It may be assumed that an average mobile phone user may not typically be equipped or willing to make sense of a debugger interface. 
• The debugger interface is represented primarily in any single implementations of ANSI Common Lisp. Extensionally, a debubber interface may also be defined in some applications of Common Lisp, such as the McCLIM debugger application of the SLIME deubger interface for Emacs
• A Common Lisp debugger interface -- as defined in any single Common Lisp programming environment -- would represent something of a unique, distinguishing feature, contrasted to other application programming platforms -- such as of a platform defined, effectively, of a C toolchain, or a platform -- cf. Intel XDK  -- available for web-based mobile application development, primarily for developing applications as typically implementing all of HTML5, Cascading Stylesheets, JavaScript and more specifically, jQuery  
• If a mobile phone platform and/or a desktop platform may be defined for developers, certainly it may behoove a scientific interest, if that platform would be supportive not exclusively of any single programming environment. Insofar as that a computer architecture may be defined of a discrete set of known components,  in software and in hardware, generically: Whatever language an operating system's kernel may be implemented in, at any practical level of abstraction, but if a Common Lisp programming environment would be providing a significant number of features to such a platform, it may behoove the platform developer to ensure that some consideration will be made about how the debugger will be presented, when the debugger would be presented to a user. As denoted in the previous, such consideration may be limited not only to the interface toolkit, but may be applied about the entire software toolchain as well.
• The Common Lisp debugger is for debugging Common Lisp software
• GDB can be applied to debug software not developed in Common Lisp
• One may observe that GDB can be applied onto a core file.
• A concept similar to a core file may be developed, as of Common Lisp implementation and application toolchain such that would allow for a Lisp image to be written to permanent storage, if on event of entry to the debugger.
• Such an implementation may be developed as either to fork before writing the image in a background process, or alternately to write the image in the foreground process -- and if in the foreground, then likely to terminate after the image is written to disk.
• Such process -- of writing the image file to disk, whether in foreground or as a background process -- it may affect the arrangement of objects in memory space, however, and may therefore affect the debugging of the initial backtrace.
• The initial backtrace should be stored separate to any subsequent data files as may be written consequent to the entry to the debugger -- i.e. program diagnostic files, etc.
• A machine-readable format should be developed for a portable serialization of backtrade information within the debugger
• See also: Details of SLIME/SWANK implementation 
• An exact selection o diagnostic files may be made by a developer or by an end user, as far as entry to the debugger and subsequent diagnostic procedures. 
• If the reader may be of any question as to whether this would describe a free/open source system, the reader might be kindly advised that this is being written within a Chromium browser, within a Linux distribution.
• That the same Linux distribution is installed as a virtual machine appliance:
• In one part, that may be mostly a matter of convenience.
• In another part, it may seem  to describe an architecture for an open source meta-IDE. 
• "First things first... &REST arbitrary"
• Concerning the dignostic file set denoted previously in this single outline:
• Existing work, in free/open source software platforms - See also KDE and GNOME desktop environments
• Primary concern: User data security
• A developer may or may not be excessively concerned about "Own data", when the developer is to be the only person viewing or reviwing any "Own data" contained in a backtrace or other diagnostic data produced by a software application, in any known procedure of the same.
• Insofar as ethics and legal responsibilities: A developer may be aware, furthermore, that the set of "Own data" may  include "Third party" data.
• If an application is configured to store and/or send its diagnostic file set in any manner as that it may be encountered by anyone not the single, individual developer
1. Question: What information will be allowed to be stored in the diagnostic file set? The application itself should have full control as per the data security requirements of the respective application user.
2. Question: How will that information be stored? Need it be encrypted, in storage? If so, that may require an application of such as PGP
3. Question: How will that information be transmitted? It should be transmitted only via encrypted channel
4. Question: Where will that information be transmitted to? There should be a public key infrastructure provided of the respective development office, to ensure safe transmittal of the diagnostic file set and any private user data contained within the diagnostic file set.
5. Question: What liabilities are then presented to the recipient of the diagnostic file set? There might seem to be not a broad body of legal discourse, in regards to such a question, but it must be derived of legal precedent -- in all of regional and ethical regards, and for each region in which an application would be made available.
6. Question: Concerning applications of existing issue tracking systems -- such as YouTrack, Bugzilla, etc -- and tools and frameworks such as the bug reporting infrastructure developed of the K Desktop Environment (KDE) namely: How would the application environment be developed as to integrate with an upstream issue tracking system? The matters of secure storage and transmittal of the diagnostic file set should be taken to consideration, in addressing this question. Furthermore, there may be a question as with regards to upgrade channels, insofar as addressing this of question.
• Sidebar - Existing Work: One may observe the architecture of the Debian reportbug system, in all of its free and open source design.
• Also a primary concern: Developers' legal rights and legal and ethical responsibilities

Offhand sketch for object model of unspecific quality

Ed. Note: The web-based "WYSIWYG" editor for Google's Blogger service does not handle "angle brackets" very well. One must enter the character entities "&<" and "&>" manually. So, here is edition 3 of this article. now partially un-mangled via the "WYSIWYG" editor. The "WYSIWYG" blog entry editor had nearly destroyed this item, when its first edition was published.

Object: #<document "μA741x General-Purpose Operational Amplifiers">
Type: "pdf"
Format: #<media "pdf">
Source: #<uri http://www.ti.com/lit/ds/symlink/ua741.pdf>
Annotations:
    #<annotation metadata:annotation "Op-Amp" @ spchamp 15:30 MST>
    #<annotation media:application "Data sheet" @ spchamp 15:30 MST>
    #<annotation inv:part "UA741CP" @ spchamp 15:35 MST>


Object: #<inv:part "UA741CP">
Annotations:
    #<annotation inv:mfgr "Texas Instruments" @ spchamp 15:42 MST>


Use cases (article):

• Whiteboard
• Notes

Use cases (data model)

• Document Management
• Parts inventory management
• CIIDR Project
• Student's own notes
• Project Management (Content Development)
• Dissertation Development
• Bibliography 
• White-board
• e.g. To sometime answer a question, perhaps: "Why is 'op-amp' just denoted as an annotation, there?"
• GUI
• Desktop Applications
• Mobile/Thin Client Applications
• "Workshop" Applications

Why this is just in an outline format:

• This article is presently a sidebar beside some fairly tedious "Lab work".
• in which exactly one UA741CP is applied, together with a total of four ratings of resistor, one linear potentiometer, a DC power supply, and the inevitable LED
• Why "So unspecific"
• Because it's an unspecific design, presently
• But really not to be presented for easy rip-off by touring entertainers.
• Unpublished "Previous work"
• Annotation object model for Common Lisp (design sketch)
• One may as well develop some kind of a SLIME-contrib extension for it, one supposes 
• to "hide the angle brackets," for instance, 
• instead, to display the annotations for, each, their "Preferred label"
• with annotation-of-annotation, namely for purpose of recording:
• author of annotation
• time when annotation was created
• time when annotation was last edited (linked with object/annotation edit history)
• author of last edit (linked with object/annotation edit history)
• ...in a database of sufficient extensibility to be able to record such things, in a generic regards, and with a free-open source platform in the same -- noting that Java's community process is probably an important part how Java has survived the acquisition by Oracle, the acquisition of Sun Microsystems.
• integrating with SKOS
• in Common Lisp
• for "Such as this" and not only "Such as this"
• also because literature
• and language
• and does one mention, language?

Notes - Towards developing a Circuit Modeling and Circuit Analysis Platform in Common Lisp

Though further delaying of the weekend time as I'd set aside for some student work, I would like to make a couple of quick notes, presently, with regards to developing a circuit design and analysis platform in Common Lisp. This is partly in referencing XCircuit, also partly in referencing the approach I'm trying to develop for such de rigeur analysis of AC circuits as I observe is represented in one course of DeVry University Online.

Things a circuit design platform may need:

• A library of circuit components
• XCircuit has such a thing organized in a unique regards.
• Fritzing uses SVG
• KiCAD - I'm unable to find any "simple" analog circuit components of its component library, however there's clearly a lot of digital components in the KiCAD circuit component library
• A circuit analysis model
• Common: Derivatives of the original Berkeley SPICE
• PSPICE - Commercially licensed by Cadence, as a part of the Cadence OrCAD platform. It's an extensible platform, however within its commercial and academic license models.
• NGSPICE - free/open source software.
• ...
• A desktop environment
• With either GTK, QT, or even Microsoft Windows "widgets," a desktop environment would be assumed to be available complimentary to the respective GUI toolkit -- namely, GNOME in any edition, KDE, or the Microsoft Windows Explorer shell.
• Author is not sure what there may be towards such a matter, if in "state of the art" of developments in Common Lisp
• Lisp Machines and "The state of the art" for desktop computing
• cf. MIT CADR, Symbolics, XEROX, Texas Instruments, ...
• cf. NeXT ...

'Fin'