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))
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 (
      • 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 (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 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 checkout cldoc
  • Anaphora also uses CVS
    cvs 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
  • The projects (Stefil, serializer, etc) also use Darcs
    darcs get
    darcs get
  • Iterate also uses Darcs
    darcs get

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 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 There is not, as yet, a 501(C)(3) or other non-profit registration for the development of 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 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 is a web resource still under development. My own initial idea for the development of 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, 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 - 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 (MCi) fork of McCLIM, whereas the project comprised of the fork does not yet "Fit" into any specific heading within the two main 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 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

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.

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

Sunday, November 30, 2014

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>
    #<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">
    #<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)
            • 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?

Saturday, November 29, 2014

Centripetal Force, Spherical Flattening, and the Electrodynamic Sun

This was my response to a discussion forum item, this evening. Regrettably, my response -- presently -- lacks any calculus equations. I'm re-publishing my response, here -- personally -- for later reference as in regards to the physics of electrodynamics. Perhaps it may seem novel to anyone else, as well.

At the north and south geographic poles of the earth -- effectively, the two points on the surface of the earth, located at the earth's rotational axis -- there, the angular momentum due to the earth's rotation would be zero. Gravity would nonetheless provide a force of gravity, at the earth's geographic poles -- there, nothing counteracted by angular momentum as due to the earth's rotation.

Thus, in regards to the geological material of the earth, the earth is not a perfect sphere. Near and at the geographic equator of the earth, the earth's continuous geological mass has a greater angular momentum than the mass at the poles of the earth, but not much less of a force of gravity, there. So, in an offhand calculation of forces created by angular momentum, at the equator -- considering force due to angular momentum, such that, in a circular pendulum, would be counteracted by the centripetal force contributed to the arm of the pendulum -- but insofar as when the only effective "arm of the pendulum" is imposed by the net mass of the earth, then the force due to that angular momentum is of more of a magnitude at the equator -- thus, to a greater difference unto force of gravity, at the equator. Therefore -- albeit, without any lengthy calculation for exact magnitude of difference, at any latitude of the earth's surface -- as due to the earth's rotation, the geological material of the earth undergoes more of a radial expansion, near and at the equatorial latitude.

Certainly, there would be a similar effect encountered by any object with a non-point mass, in rotation along any single axis of rotation. The earth, perhaps -- as in a view towards the geological material of the earth, of the earth beneath the atmosphere of the earth and the earth's entire hydrosphere -- as in regards to the essentially geological qualities of the earth, the earth might be viewed as a large, rock-surfaced mass with a liquid mantle and possibly a solid core -- as towards a certain average viscosity of the earth's mantle, contrasted to the average viscosity of the material of any gaseous planet, or of any planet having experienced a certainly very-long-term geological cooling.

The spherical flattening of a rotating planetary body perhaps may be more evident in observation of the shape of the planet, Saturn -- perhaps less so, of a by-in-large geologically inert planet, such as Mars.

Considering the material of the nearest solar neighbor, the sun, I'm not certain if the "Sphere flattening effect" could be described so easily about the sun's mass. Certainly, there would be more forces than centripetal force and gravity, affecting the sun's own mass  -- including forces resulting of solar convection, and the net electrodynamic force of the magnetic field of the sun, such as would affect the plasma mass of the sun. Perhaps the sun might also be shaped like a flattened sphere, nonetheless.

Student Discovers a Light for a Fading History, Adds Dimmer Circuit

This evening, through careful study, I have learned how to emulate my grandfather's light-sensitive shop-light -- pretty neat, one might say.

Personally, I would use a solid-state relay (SSR) in the mains-facing part of the circuit -- perhaps, in a circuit similar to that illus. p. 3 of the data sheet for the Sunrom LDR 5 mm, in which the current across a photoresistor provides -- in inverse proportion to the intensity of the light source -- a current to the base of an NPN transistor. In the circuit as described in the data sheet: When during the daylight hours, the sun's light would be of a greater intensity, then the photo-resistance would be lower, in the circuit, and the transistor would have a base current. With an NPN transistor in the circuit, the circuit to the base of the transistor effectively activates a relay, namely when the photoresistance of the photoresistor reaches below a certain value, in an inverse proportion to the intensity of the light source. There's to a theory of operation of the item.

As far as an implementation of the manufacturer's original circuit design: If the variable resistor was to be implemented with a dial, then a variable resistor might be selected with an "Inverse slope" for the gradient of the variable resistor -- for the dial's setting, then, to appear to be in direct proportion to the light sensitivity of the circuit, in the original construction?

Substituting a PNP transistor into the circuit -- with a small translation of the schematic, for the current pathway, in the PNP construction -- the current to the base of the transistor would have a functionally opposite effect, contrasted to the design as in the schematic.  With base current to the PNP transistor, the relay would be deactivated. With photoresistance at a maximum, then -- as when sunlight, as at light source, would be at a minimum -- then the base current would be at a minimum, and the relay would be activated, in the alternate PNP circuit.

If the variable-resistor was implemented as a dial, comparatively in the PNP construction, then perhaps it should rather be placed on the collector, along with a similar, static-value resistor there -- that circuit branch, then replaced by a ground wire, in the schematic -- and likewise implemented with an "inverse gradient."

Insofar as type of relay, an SSR would certainly allow the relay portion of the switching circuit to last for a while -- as contrasted to a circuit with, instead, a mechanical relay. If there would be an SSR element of sufficiently compact design, then perhaps it could be implemented all within a base for a light bulb -- or alternately, in a grounded enclosure, with a two-wire cable leading to the base of the light bulb, perhaps to something cleanly done for a residential application ... if only that could all be done in an AC circuit, without any further translation of the manufacturer's original design.

In an AC implementation: The relay would provide an interface to control the AC portion of the circuit. Secondly, there would need to be a DC current source for the switching component of the circuit -- perhaps, something that could be made with a simple, full-wave bridge rectifier -- between the relay's switching component and the rest of the circuit -- with capacitors sufficient to smooth the rectifier's output waveform to a nearly linear current. If that would be all patented-up, already, one could put an Arduino into it, wire it for IoT, and call it "Public Domain," or optionally under some kind of a formal license. "DIY engineering," the poor engineer's alternative to patent litigation. 

I'm sure it's all been done more efficiently, already, but there's a thought to how it could be done, nonetheless. Schematics might ever appear, here, if there's ever a place one would put such a thing.

What one might also say: If I had a shop or a house to emulate it unto, that would be even more nice? If my parents even had a house of their own ... then that would be different than how this year has been, in my family's life. But now, I can emulate a light-sensitive light switch for a disappearing history, for however long the light switch would last. How novel. The things I might make if I was an electrical engineer could outlast my family's own rustic pre-consumer heritage, until it's all been consumed by the consumerist "Modern". What good would that be?

That someone later could put it into a museum and say it was not how it was? That I myself could try to paint any too bold picture of our simple, rustic origins, to entertain any too-bold "old west" romanticism going by? Or that it could just dwindle after the shop light burns out -- that's how I imagine it'll go.

I had seen one of something like the Sunrom LDR 5 mm, once upon a time. I will not ever again see the house I was raised in, and neither the house in which was my grandfather's family. This is the life I know.

Notes - Cadence OrCAD

Ed. Note: The following page comprises a series of short notes about using Cadence OrCAD Capture, an electronic design automation (EDA) tool

Placing Generic Components  and Sources
  • PSpice Component
  • 'DISCRETE' Component Library - Generic Library Items
    • Sources (Generic)
      • BATTERY
    • Cutoffs (Generic)
      • FUSE
      • Switches: SW ____
      • Relays: (TBD) 
        • Mechanical Relays (TBD)
        • Solid State Relays (TBD)
    • Transformers (Generic)
      • TRNSFRMR ______
    • Semiconductors (Generic)
      • DIODE
      • Transistors (Generic) (NPN, PNP)
        • MOSFET N
        • MOSFET P
        • JFET N
        • JFET P
        • BJT: Listed by part number ?
    • ...


See also: Introductory book

Sideabar: Scripting OrCAD Capture with TCL/Tk

OrCAD Capture is bundled with an interpreter for the TCL scripting language.

The TCL interpreter bundled with OrCAD Capture can be accessed from within the OrCAD Capture main window, via the "right-click" context menu on the OrCAD Capture menu bar.

  • TCL Version (OrCAD Capture 16.6)
    • puts $tcl_version
    • => 8.4
  • Object Models
    • OrCAD Database Object Model (Dbo*)
      • Reference: Tcl/Tk Extensions in OrCAD Capture [documentation] s. 3
      • Subsets:
        • Design Database Object Model
        • Library Database Object Model
      • See also: Class Hierarchy, s. in Tcl/Tk Extensions in OrCAD Capture [documentation]
  • Commands
    • Menu Commands
    • Page Editor Commands
    • Project Manager Commands
    • Database TCL Commands (see also: Object Models)
  • Journaling
    • SetOptionBool Journaling TRUE
    • SetOptionBool DisplayCommands TRUE
    • The command journaling feature in OrCAD Capture allows for a certain approach to script debugging or alternately, API exploration, by displaying TCL API commands as applicable for duplication of existing GUI actions (e.g. place wire, place component, ...) 

Developing Interfaces to TCL from Other Programming Language Platforms
  • FFI in TCL 
    • (TBD)
  • SWIG 
  • Common Lisp (ANSI CLtL)
    • Overview
      • Interface tools for CLtL are mostly GUI-focused
      • Some (?) allow embedding of TCL scripts
      • TCL is not CORBA IDL
    • Selected Projects
  • Reflection in TCL
    • (TBD)
Extending OrCAD TCL

  • Load-time initialization file for the OrCAD TCL interpreter
    •  path [cygwin$(cygpath -u $CDSROOT)/tools/capture/tclscripts/capinit.tcl
  • Load-time initialization directory for the OrCAD TCL interpreter
    • path [cygwin$(cygpath -u $CDSROOT)/tools/capture/tclscripts/capAutoLoad/
Project Concept: Integrating OrCAD With CORBA Service Networks

  • Resource: Tclblend [tclers wiki] 
    • Java + TCL
  • Resource: JacORB
    • CORBA ORB in Java
    • Support for Kerberos, SSL
  • Development Procedure (Outline)
    • Develop IDL interface
    • Document IDL inteface
    • Develop Java implementation of IDL interface (JacORB)
    • Develop "other" implementation of IDL interface (e.g. CLORB)
    • Functional Unit Testing
    • Beta Application
    • Application in Usage Case
    • Release
    • Maintenance
  • Application Procedure (outline)
    1. Initialize OrCAD
    2. Initialize ORB, via JacORB, via Tclblend
    3. Connect to ORB, via "other" CORBA implementation
    4. Conduct procedures of IDL interface, via ORB-to-ORB connection
    5. Disconnect ORB from within "other language" CORBA implementation
  • Concepts (outline)
    • Why CORBA?
      • OrCAD as service provider
        • Schematic capture service (GUI)
        • Schematic modeling service (API)
        • Schematic simulation service (GUI) (API?)
      • Independent process control for service provider appliations
      • CORBA provides a language-agnostic interface definition language, CORBA IDL
    • Integration with operating system virtualization services
      • CORBA and SDN
    • Integration with on-site parts databases
      • Bill of Materials
      • Parts Inventories
      • Purchase Orders
    • Integration with on-site parts library servers
      • Schematic models
        • Schematic Models Demonstrating Recommended Practice
        • Schematic Models of In-House Products
        • Schematic Models of Third-Party Products
    • Usage Cases:
    • Some duplication of functionality available within other OrCAD platform components


Additional Resources