Wednesday, December 31, 2014

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

Sunday, December 28, 2014

More Cypher-Like Notes about Common Lisp...

Minimalist Overview for the "tl;dr" Weary

  • Exists: Fork of de.setf.xml
  • Issues (Present revision)
    • "Not ___"
      •  (xmlp:document-parser "<foo bar='quux'/>")
        • Incomplete Parse
        • Backtrace provides limited information
        • Some functions were compiled with (optimize (speed 3) (safety 0))
  • ATN parser
  • Other source code generation
  • Manual optimize settings within function lambda forms
  • Goals
    • Allow for selection of one of: production-mode optimization or debug-mode optimization prior to compiling source code
  • Alternatives - Including
    • Option "The First One"
      • Specify non-nil :debug value in asdf:operate
      • Within a method specialized on asdf:operate, ensure that the value provided to the  :debug initarg will be accessed from the operation object provided to the method, cf. asdf/operation:operation-original-initargs
      • From the value of that initarg (if non-nil), select either production-mode optimization or debug-mode optimization, setting exactly one as the value of a variable *default-optimization*
        • User may specify values for production-mode optimization and debug-mode optimization, such that would be applied within the function lambda form for the respective method instance
        • This does not specify how the user would specify those configuration values
        • Option: Configuration via implementation init file
          • Arbitrary Things
          • Concern: If only to present the respective optimization settings to the respective method form, for binding to the specified special variable, it should not require definition of two more special variables, in addition to *default-optimization*
          • Concern: GUI Integration (Hypothetically)
            • MCcLIM Listener application
            • Climacs
            • ...
          • Existing things
            • Emacs Custom
            • GNOME gconf
            • CORBA
              • (read "/dev/arbitrary")
            • XML
              • (read "/dev/arbitrary")
            • JSON
              • (read "/dev/arbitrary")
            • Sidebar: mknod /dev/arbitrary c 1 3
            • CORBA IDL
              • Interface application
            • Shameless Promotion of Design Component: Dobelle-App
      • Within a macro form, using cl:locally, apply the value of *default-optimization* as for the optimization of code evaluated within the macroexpansion of the macro form 
        • This provides a portable alternative to using cl:with-compilation-unit to specify the optimization setting
      • To compile and load a system M for debug compilation
        1. Short technique for recompilation: Remove any existing output files as may have been generated for the system M 
        2. Typically, (asdf:operate 'asdf:load-op M :debug t)
        3. For a backtrace list as may be produced in any unexpected situations generated by the recompiled software code: The debug mode optimization  may have allowed for the compiler to collect more details from the compiled source code, such that might diminish system performance in a small regards, but would allow for further systematic reflection on event of "error"
      • Integrate with "the IDE in the blue sky"
    • or other
  • Concerns
    • The specified method definition onto ASDF, the definition of the variable *default-optimization*  and the specified macro containing the locally form, must be provided as to be accessible to both of:
      • The system definition
      • The source code denoted in the system definition
    • Yet Another Common Lisp utility system (YACLUS, or "Yak-less")
    • Policy: For any thing defined within a Common Lisp system M, to not define things within M as within the package CL-User
    • ANSI Common Lisp the Language Unlike the Java Development Platform (ACLtLUTJDP.example.com)
      • Accessing Software
        • Java: Class Loader (Transparent / Encapsulated within JVM)
        • Lisp
          • Direct access to source files via CL:LOAD
          • Component-oriented system definitions via e.g. ASDF, or MK:DEFSYSTEM
          • Extensible
      • Producing Secure, Stable, Reliable, Manageable, and Reproducible Software Systems
        • Java
          • Visibility of Classes, Fields, and Methods
          • Security Policies
            • May affect behaviors of class loader
            • May be defined within specific levels of security context
          • Thread Safety
            • ...
        • Common Lisp
          • Source control
          • Thread Safety
            • ...
      • Configuration
        • Java
          • Java properties files
          • Spring XML
          • Maven
          • Host Environment
        • Common Lisp
          • Arbitrary Extensions to ASDF 
          • Arbitrary configuration data structures and configuration syntax definitions, typically specializing type CL:LIST
          • #:YMMV
      • Testing Things Thoroughly
        • Functional Unit Testing
        • Integration Testing
        • Regression Testing
        • Test Testing
        • Test Test Testing (ETC)
      • Publishing Software
        • Java
          • JARs
          • Maven Repostories
          • ...
        • Linux
          • Debian packages
          • RPM packages
          • Gentoo portage
          • ...
        • Files (Generic)
          • Source code repository
          • Archive (GZip, etc)
          • Installer (Platform-specific)
        • "Suits" Things
          • Policies
          • Requirements
          • License Fulfillment
          • Administration
      • Debugging things
        • Issue trackers
          • Bugzzilla, YouTrack, etc
          • ...
      • An economy of things
        • ?

Saturday, December 27, 2014

Quip of 2014

I was going to write something in an article, here, and then I found something to read instead.

Friday, December 26, 2014

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 propertiesskos: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

Wednesday, December 17, 2014

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?

A succinct index onto dependencies of Dan Lentz' cl-ctrie

A succinct index onto dependencies of Dan Lentz' cl-ctrie

[To Do: Insert, here, a lengthy doctoral overview about data structures for indexing and search within digital object systems. Include a very length bibliography. No too far sidebars about RDF, OWL, and so on. "Keep it within the lane"]

Ed. Note: These may be available via quicklisp. Alternately, one may apply an SCCM tool manually, to download the newest source trees representing each respective project.
  • nibblesA Common Lisp library for accessing octet-addressed blocks of data
  • ironclad - A cryptographic toolkit written in Common Lisp
  • cldoc -  documentation tool; alternate to Albert
  • unicly - UUID implementation [RFC 4122]
  • uuid - (and another) (code alignment?)
    • Shared dependency: ironclad
    • Additional dep: trivial-utf-8 (see also: Closer-Common, cf. the illustrious 'rune' data type, towards code alignment)
  • split-sequence - "self explanatory"
  • Informatimago Public Common Lisp Libraries - namely Informatigo 'heap' system)
  • cl-irregsexp - regular expressions, alternate to cl-ppcre's Perl-like syntax (code alignment?)
  • Stefil - testing framework  [old homepage][new homepage - refer to 'Repository', 'User Guide' other tabs on page]
    • Also needs hu.dwim.asdf
  • :hu.dwim.serializer - as with the Stefil project, refer to 'Repository' and other tabs on page.
    • Likewise hu.dwim.common
      • Likewise, Anaphora
      • Likewise, hu.dwim.common-lisp (code alignment?)
      • Likewise, metabang-bind (but what kind of an SCCM system does this project use?)
    • Likewise, hw.dwim.def
    • Likewise, hw.dwim.syntax-sugar (with a grain of salt)
    • Likewise, hw.dwim.util (code alignment among utility systems?)
    • ... :hu.dwim.defclass-star
  • CL-STORE - also an object serialization system
  • Osicat - compatibility layer onto OSI/POSIX/.... May be common (code alignment)
  • CL-PPCRE - Regular expressions in a syntax resembling of perlre (PERL). May be common (code alignment)
  • iterate - Extensible alternative to CL:LOOP and other iterative forms defined in CLtL2. May be common (code alignment) 
  • Alexandria - a popular bundle of utility forms, in Common Lisp
  • Selected subprojects of the Closer Project
    • Closer-MOP - common
    • ContextL - Towards context-oriented programming in Common Lisp
....and that's all for the dependencies, at that level of study.

Most of those projects are available via Git. Exceptions:
  • CLDOC may be downloaded in its source code, with CVS:
    cvs -d:pserver:anonymous:anonymous@common-lisp.net:/project/cldoc/cvsroot checkout cldoc
  • Anaphora also uses CVS
    cvs -d:pserver:anonymous:anonymous@common-lisp.net:/project/anaphora/cvsroot checkout -d anaphora src
  •  UUID is available as a gzipped tape archive (i.e. *.tar.gz) (see UUID homepage)
  • The Trivial UTF-8 project uses Darcs:
    darcs get http://common-lisp.net/project/trivial-utf-8/darcs/trivial-utf-8
  • The DWIM.hu projects (Stefil, serializer, etc) also use Darcs
    darcs get http://dwim.hu/live/hu.dwim.stefil/
    darcs get http://dwim.hu/live/hu.dwim.serializer/
    
  • Iterate also uses Darcs
    darcs get http://common-lisp.net/project/iterate/darcs/iterate

Optionally, Darcs can be applied with the '--lazy' argument to 'darcs get', as to create a Darcs repository applying a copy on demand methodology for changeset data. Applying this argument, the net time required for the 'darcs get' command may be minimized.

Wednesday, December 10, 2014

Introducing the Mercantile Store of the MetaCommunity Project

I've developed a small aStore storefront at Amazon.com Associates -- the  Mercantile Store of the MetaCommunity Project (presently in its edition 1) -- including a small list of accessories I personally would trust for application in outdoor environments, such as for conservationism or the simple recreations of camping out, if not furthermore for day hikes and so-on.

Of course, with regards to camping stoves, it should be noted: That the same regulations would apply as with regards to campfires. In the US forests, one may consult the nearest, official US Forest Service Ranger Station for more information. Typically, the permits are available for free, and would be accompanied with a wealth of useful information for campfire safety. There are also some digital resources about campfire safety, such as published by the US Forest Service, in California's Sequoia National Forest.

Proceeds from the Mercantile Store will be applied for continued development and maintenance of web resources of MetaCommunity.info There is not, as yet, a 501(C)(3) or other non-profit registration for the development of MetaCommunity.info. Candidly, it may be difficult to register it as a non-profit organization, under any exact specifications in US tax code, though it is essentially a not for profit organization. Pending any further, formal development of the MetaCommunity.info organizational architecture, the author personally will see to it that any proceeds from the aStore will be applied for continued development and maintenance of web resources of MetaCommunity.info.

MetaCommunity.info is a web resource still under development. My own initial idea for the development of MetaCommunity.info was that it may serve as a sort of meta-resource for knowledge sharing, as with regards to concerns of life and lifestyle -- none too aligned to any single social networking platform, however, thus existing as a sort of "Meta-Community." Unfortunately, the development of the web resource has been stalled, pending further resolutions in certain nationalist and quasi-national concerns in the world. Furthermore, the initial design concept has undergone some moderate evolution, in this year.

In the outlook, presently, MetaCommunity.info would be -- in one part -- a projects hub for selected projects about math and engineering, and furthermore a hub for projects developed as towards some humanitarian concerns, and conservationism, and tourism. I've begun to develop a design for a single portal under each such concern. However, I am presently unable to develop any single schedule for such projects. The ink is just dry, on the outline itself, and -- myself -- it seems that I must certainly search for another place of residence, before I may be able to begin to focus about anything so technical and involving.

So, but that's what there is so far, for it --  a web store and a resource for campfire safety.

Please, Tread lightly.

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.

Saturday, December 6, 2014

Towards a Design of a Parallel AC/DC Mains System for Single Residential Application

On a "research lark" about solar energy systems, today, I've found a resource published by Emerson Network Power, such that I would like to make a small note about, here in my DSP42 web log.

 Considering:
  • Solar energy systems produce DC signal -- as before any conversion to AC via diodes, inductors, transistor driven voltage regulators, etc -- as possibly before any conversion back to DC, then, as when for driving digital electronics and DC appliances
  • DC electrical signals may be suitable for decentralized applications not requiring any unspecific number of long-distance electrical transmission lines
  • That towards a design for a residential DC/AC parallel lines system, insofar as the DC line system, there may be an analogy found in data center architectures

Found Resources:
  • Murrill Mark  and B.J. Sonnenberg. "Evaluating the Opportunity for DC Power in the Data Center" Emerson. 2010
    • Notes
      • Modular Design
        • 480 V AC mains (common)
          • Step-downs to 208 V AC
        • Cooling system (p. 7)
        • PDUs, BDBC systems
          • Topology of power distribution network
          • Switched-mode power supplies may introduce harmonics of signals on AC lines (p. 6)
            • Affects accumulate in neutral line
              • Mechanical model: TBD
            • Desultory effects:
              • Power loss
              • Source of heat energy within data center/components
            • Related concept: Total harmonic distortion within power distribution network
          • Variations in system load 
            • At interfaces onto three-phase AC systems: Timing/scheduling of load changes within data center, onto phases of three-phase AC system (noted, p. 6) (?) ideal, to minimize power loss and generation of heat energy
              • Mechanical model: TBD (Three-phase AC)
            • See also: Phase Balancing: The Last Few Inches of a High-Efficiency Power System (referenced, p. 7)
            • Scheduable load changes (macro model):
              • Instance: Current loads induced for battery charging within uninterruptable power supply (UPS) systems
              • Instance: Current loads induced due to computing loads, in application of computing resources within batch computing models
            • Unschedulable load changes (macro model):
              • Instance: Computing loads resulting of direct user agent interactions
              • Mitigating concern: Interactive network services can be localized to individual data center elements
        • Energy consumption
          • Data center components - Digital computing
          • Battery charging in UPS systems
      • DC voltages
      • Safety and standards

Resources at a beginning of this research arc:
  • News article Worlds Largest Solar Plant Goes Online Using 9 Million Solar Panels
    • A large scale, grid-centric solar energy system recently developed by PG&E
  • Concepts towards applicability (residential energy systems): 
    • Concept: DC motors
      • (TBD)
      • Industrial applications
        • ShurFlo DC centrifugal pump, from ShuFlo industrial
          • Possible applications in decentralized solar/battery systems for agriculture, industry, and recreational maritime systems
      • Residential/Utility applications
        • Battery-operated/cordless home utility equipment and construction tools
    • Concept: DC appliances
      • (TBD)
      • Common:
        • Residential air conditioning and heating systems
          • Consdenser and motor in air conditioning systems
          • Heating coils
          • Swamp coolers (humidity)
        • Residential air circulation (e.g. ceiling fans)
        • Food refrigeration
        • Lighting appliances
          • Filaments (AC lighting)
          • "Warmth" of lighting model
    • Concept: DC power supplies within/for home entertainment systems
      • Video
      • Audio
      • (TBD)
  • Previous article in solar electrical series, here at my DSP42 web log

Wednesday, December 3, 2014

Free Book about Op-Amp Applications, from Texas Instruments

I was looking for a solid reference resource, this evening, as with regards to design of frequency-domain active filters in audio and signaling applications. I found the following the eBook. It seemed that it would be fit to share a note about, here at my DSP42 web log. Published by Texas Instruments in 2002, the eBook is titled, Op-Amps for Everyone.

Across all of 464 pages of PDF format text, the eBook provides a comprehensive introduction to op-amps -- now available in free, PDF eBook format. The eBook is published by Texas Instruments, but provides a vendor-agnostic, essentially non-proprietary view with regards to op-amp applications.

This eBook provides introductions to concepts and applications of op-amps, with corresponding mathematical formulas throughout. As a small sampling of the topics addressed in the eBook:
  • Chapter 3 of the eBook addresses op-amp applications in a generic sense, focusing on methods for applications of op-amps within common kinds of amplifier circuit, including: Inverting amplifiers; non-inverting amplifiers; differential amplifiers; video amplifiers; etc. 
  • Chapter 4 of the eBook provides a contrast between single-supply and dual-supply applications of op-amps. Chapter 15 of the eBook is dedicated to oscillator designs, for generating sinusoidal waveforms. 
  • Chapter 16 of the eBook is dedicated to discussions of active filter designs. 
The eBook addresses a number of concepts that might be addressed, in parallel, in the course material of the DeVry University Online ECT-246 course. The eBook also provides some information about some additional concepts, such that may be encountered -- broadly -- within a context of design and analysis of op-amp circuits.

To the aspiring software programmer, perhaps the eBook may serve to provide a convenient, singular reference model for design of an electronic design automation (EDA) tool for amplifier design and analysis in frequency-domain applications.