Tuesday, May 6, 2014

Notes: Towards developing with ECL on a Samsung Chromebook

Overview: The Samsung Chromebook
  • Samsung Chromebook model XE303C12-A01US
    • Available at BestBuy
  • Affordable PC platform, running ChromeOS 
    • ChromeOS: Branded edition of ChromiumOS
    • Linux kernel
    • X.org display server
    • Chromium OS security model
  • CPU: Samsung Exynos 5 Dual  SoC (ARM Cortex A15 / armv7l) 
  • Minimal power consumption on DC power supply 
    • may provide up to 9 hours PC runtime with wifi disabled and no USB devices connected
    • may provide aprpox. 6 hours PC runtime with wifi activated and no USB devices connected 
    • approx 2 hour charge time (YMMV)
  • Ultrathin notebook
  • SSD internal storage (16 GB) (eMMC interface may be available via Linux kernel)
  • Internal storage extensible via built-in SD card reader and USB
  • Supports USB 3.0 "SuperSpeed" devices 
  • In Chromebook "developer mode," a Chromebook can run an individual Linux chroot environment, on top of ChromeOS
Overview: ANSI Common Lisp (CLtL2) on ARM
  • CCL
    • Uses CCL's FFIGEN4 (fork of FFIGEN) in developing CCL interfaces onto OS machine code
    • Does not run "out of the box" on Samsung Chromebook
      • "CPU doesn't support required features"
      • Patch available (?), must be cross-compiled
        • Cross Compiling, CCL Wiki
          • Alternate representation:
            ;; arm-xcompile.lisp
            
            (in-package #:ccl)
            
            ;; referencing lib/compile-ccl.lisp
            (eval-when (:compile-toplevel :load-toplevel :execute)
               (defparameter *arm-compiler-modules*
                  '(arm-arch
                      armenv
                      arm-asm
                      arm-lap
                      ))
            
               (defparameter *arm-compiler-backend-modules*
                  '(arm-backend arm-vinsns arm2))
            
               (defparameter *arm-xdev-modules* '(arm-lapmacros ))
            
               )
            
            
            
            ;; referencing
            ;; http://trac.clozure.com/ccl/wiki/CrossCompiling
            
            (require-update-modules *arm-compiler-modules* t)
            (require-update-modules *arm-compiler-backend-modules* t)
            (require-update-modules *arm-xdev-modules* t)
            (defpackage "ARM-LINUX")
            (load "ccl:lib;ffi-linuxarm")
            (require-update-modules *arm-xload-modules* t)
            (setup-arm-ftd (find-backend :linuxarm))
            
            
            (defun cl-user::do-xcompile ()
              (cross-xload-level-0 :linuxarm :force)
              (cross-compile-ccl :linuxarm t))
            
            
          • CCL, in successfully evaluating the lisp form
            (cross-compile-ccl :linuxarm t)
            will generate a file, arm-boot (How to build into armcl* ?)
  • SBCL
    • ARM ports available
    • Must be cross-compiled
  • GCL
    • Available via Ubuntu ports repository for armel
  • ECL
    • Available via Ubuntu ports repository for armel
    • ABI / FFI interface (host OS): libffi 
      • documentation available in TeXinfo format: 
        • libffi source code, doc subdirectory
        • published as HTML documentation in Debian package libffi-dev (Ubuntu  12.04 armel architecture)
    • For documentation about the Lisp interface to FFI in ECL, see also:
      •  ECL Manual, Section II, Chapter, 3, Foreign Function Interface
        • Static FFI and Dynamic FFI
        • For developing Static FFI interfaces, assistance is available for the developer, via the function FFI:C-INLINE
    • For portable FFI, see also: 
    • McCLIM fork for ECL, Github
      • Current status: "No multiple-value SETF" (Multiple-value SETF developed locally, using define-setf-expander.  Regression testing framework needed -- therefore, a substantial design decision onto the fork.)
Overview: Developing ECL for multiple hardware architectures, on the Linux platform
  • Recommendation: Build ECL distribution packages from Ubuntu repository source packages 
    • Possible relevance / use cases:
      • Context: Software distribution and OS imaging
        • Develop an ECL "back-port" for a single Debian-based Linux OS distribution 
        • Distribute ECL development packages, while developing ECL
      • Context: ECL development
        • Install build-dependencies for ECL
        • Cross-compile ECL
    • Shell command (without cross-compile)
      export V=13.5.1+dfsg2 &&
          export DV=ecl-${V} &&
          export PV=ecl_${V}-4.1ubuntu1_i386 &&
          apt-get source ecl && 
          sudo aptitude build-dep ecl &&
          cd ${DV} &&
          debuild -uc -us -b &&
          sudo dpkg -i ../${PV}.deb
      
  • Multi-architecture development in Debian GNU Linux and Debian-based Linux distributions


"YMMV"

Sunday, May 4, 2014

Sharing some simple notes about Maxima

Maxima
  • Formally, Maxima is a computer algebra system
  • Derived after MIT Macsyma -- see also, A Brief History Of
  • In a sense, An extensive mathematics platform in Common Lisp
  • Maxima and CLOS?
    • CLOS and CLIM?
    • CLOS and OWL?
      • OWL, RDFS+OWL inference, SWRL, and mathematical interpolation?
    • CLOS and data processing tools onto ...
      • the Sloan Digital Sky Survey? 
        • Autonomous navigation in "Outer space"?
      • FFT, signal domain transformations, Planetary Data System, and asteroids
    • Three uses of CL:DEFCLASS, all in numeric.lisp
    • Numerous uses of CL:DEFSTRUCT
      • Some ANSI CL implementations use CLOS implementations derived from PCL
        • PCL, CL:STRUCTURE-CLASS, and CL:STANDARD-CLASS
        • MOP and FUNCALLABLE-STANDARD-OBJECT (sidebar)
  • Maxima and "not directly Lisp"
    • Maxima 'mac' and 'dem' files - see subdirs of 'share'
      • Documentation?
  • Maxima GUI
  • Serialization, integration with other computer algebra systems

Simple notes are simple.

Towards a Multiple Value SETF in ECL

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

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

The following form may serve to demonstrate something towards how a multiple value SETF may be implemented, in ECL 11.1.1
(in-package #:cl-user)

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

;; (foo* 5)

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


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


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

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

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

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

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