Showing posts with label Eclipse IDE. Show all posts
Showing posts with label Eclipse IDE. Show all posts

Friday, June 20, 2014

Towards an IDE Model for McCLIM (Draft 2)

Outline:

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

Monday, June 16, 2014

Notes - Developing with Clozure Common Lisp on Microsoft Windows Platforms, using the Eclipse IDE

Essential Outline, Overview

I. Install IDE

II. Install toolchain components

III. Install software components

  1. Install precompiled components
  2. Build source-code components

IV. "Write new lines of code"

V. "Release new lines of code"

VI. "Release party"

VII. "Maintain released code"

VIII. IPO

Note: This outline proposes an alternative to to crowd-sourced economic models.

IX. ....?


Practical Outline, Current Draft

  1. Install GNU C/C++ Toolchain via Cygwin. 
    • Supporting documentation resources may include:
    • Observe that there are two distinct C/C++ compiler toolchains available for installation via Cygwin: The GNU Compiler Collection (GCC) and the Minimialist GNU for Windows (MinGW) toolchain
      • Additionally, a 64 bit edition of the GCC toolchain is available via cygwin64-gcc 
      • Alternately, a 64 bit edition of the MinGW toolchain is available in two editions:
        • mingw64-i686-gcc 
        • mingw64-x86_64-gcc
        • Referencing the mingw-w64 General Usage Instructions, the mingw-w64 i686 toolchain would be used for compiling 32 bit binaries on a 64 bit host platform, whereas the x86_64 toolchain would be used exclusively for compiling 64 bit binaries
        • For compiling CCL for Microsoft Windows platforms, mingw64 is the recommended toolchain. For a complete Microsoft Windows build of CCL -- for Windows 32 bit and Windows 64 bit target platforms -- both of the MinGW-w64 i686 and x86_64 toolchains should be installed, for compiling the CCL Lisp kernel respectively for 32 bit and 64 bit Microsoft Windows platforms. 
        • Observe the advice denoted in the following source files, and the Cygwin packages recommended in the same:
          • Makefile for CCL 1.9 on Win32, recommending the following Cygwin packages:
            • make
            • m4
            • mingw64-i686-binutils
            • mingw64-i686-gcc-core
            • mingw64-i686-headers
            • mingw64-i686-pthreads
            • mingw64-i686-runtime
          • Makefile for CCL 1.9 on Win64, recommending Cygwin software packages:
            • make
            • m4
            • mingw64-x86_64-binutils
            • mingw64-x86_64-gcc-core
            • mingw64-x86_64-headers
            • mingw64-x86_64-pthreads
            • mingw64-x86_64-runtime
          • Using the Eclipse IDE C Development Tools (CDT) in an Eclipse CDT C/C++ project, each toolchain may be defined seperately, in an individual toolchain configuration, via the project properties dialogue window for the respective project.
  2. Install Eclipse IDE (Kepler)
  3. Install additional extensions for the Eclipse IDE:
    • Collaboration // Subversive (SVN) team provider 
    • Programming Languages // C/C++  Development Tools
  4. Download the CCL 1.9 distribution for Microsoft Windows Platforms (source and binaries). 
    • See Getting Closure CL
    • SVN URL http://svn.clozure.com/publicsvn/openmcl/release/1.9/windows/ccl
    • Create as Generic Project
      • After download: Convert to C Project, referring to Eclipse IDE online help documentation
        • Select C Project
        • Select Project Type: Makefile Project (Cygwin GCC)
          • NOTE: Ensure that the Cygwin GCC installed and that the user's PATH environment variable is appropriately configured, within the Eclipse IDE session -- e.g PATH should contain an entry  c:\cygwin\usr\bin at the end of the PATH environment variable value (refer to later outline entries, here)
        • Observe that the primary makefile is located under the directory lisp-kernel/{architecture}, for each supported {architecture} within the CCL source tree (e.g. win32, win64)
        • After converting the project containing the CCL source tree into a C project, then right click on the project, in the Eclipse IDE Project Explorer view, and select the Properties entry, in the project context menu
          • Observe the project properties, C/C++ Build and C/C++ General. 
          • Specifically, under the C/C++ Build property, as to ensure that Cygwin is available on the system PATH at build time
            1. Select the Build Variables entry
            2. Select ADD
            3. Enter PATH as the variable name
            4. Add the entry: ${CYGWIN_HOME}\usr\bin and select OK
            5. Select ADD, again
            6. Optionally, in the Build Variables dialogue window, select Show system variables to review the full list of environment variables that will be defined in the build environment.
          • Select the root C/C++ Build property, and append the appropriate CCL lisp-kernel makefile location to the Build Command, e.g substituting the appropriate project name (in this configuration, ccl-1.9-windows-ms)  the build command  for building CCL for 64 bit Microsoft Windows platforms:  make -f ${workspace_loc:/ccl-1.9-windows-ms}/lisp-kernel/win64/Makefile
          • TO DO: One or more of:
            • Define an "add on" central makefile for both of win32 and win64, such that the central makefile would permit for specification of which target platform to select, at build time
            • Configure the Eclipse project for the CCL build, such that an environment variable may be used to select which target platform to compile for, e.g to a Build Command:  make -f ${workspace_loc:/ccl-1.9-windows-ms}/lisp-kernel/${target.arch}/Makefile
            • Define a separate Eclipse CDT make target for each respective target runtime platform. See also: Creating a make target, in the Eclipse CDT Online Help Documentation
  5. Refer to CCL manual, Chapter 3: Building Clozure CL from its Source Code, specifically section 3.5, Using "make" to build the lisp kernel
  6. ... #YMMV
To do:
  • Developing with McCLIM
    • UI Concepts in CLIM
    • Contrast: 
      • Geometric GUI design / view
        • CLIM
      • Structural GUI design / view
        • Qt, GTK, Eclipse Standard Widget Toolkit, ...
    • Observations:
      • CLIM was designed for integration with window systems
      • CLIM was developed at a time before the widespread development and adoption of standard GUI component toolkits, as available in contemporary editions of the Microsoft Windows, OS X, and Linux/X11 desktop platforms
        • Sidebar: Toolkits and Desktop Environments -- primarily on Linux/X11 platforms
          • GTK, GNOME
          • Qt, K Desktop Environment (KDE)
      • The design of the CLIM GUI architecture effectively requires that the Common Lisp implementation will perform in a role as layout manager, on the graphical desktop platform
      • Standard GUI component toolkits such as Qt would be defined with, in each, their own respective layout managers
        • Functionally dependent on available interfaces, the toolkit's own layout manager may be interfaced via FFI
  • Developing with Qt and McCLIM
    • Qt 5 on Microsoft Windows (Windows 8, WinRT, Metro UI ) -- Resources
      • Qt for Windows (Qt 5)
        • Download Qt
          • Observe that the Qt WinRT 5.3.0 binary edition is compiled for a 32 bit architecture, and therefore would require a 32 bit Lisp image for FFI
          • Note that CommonQt does not presently support Qt 5
          • Observe that Qt 4.8 (4.8.6) is available in an edition compiled with MinGW
            • The exact toolchain edition, as mentioned in the text of a a dialogue window, at installation time: MinGW GCC 4.8.2 i686, POSIX threads, Dwarf exception handling. A corresponding edition is available via the MinGW-w64 project, as hosted at SourceForge.net. 
            • Observe that CommonQt makes reference to the Qt 4 edition compiled with Microsoft Visual Studio / Visual Studio Express
      • Qt 5 on Windows 8 and Metro UI (ca. 2012)
      • Introduction to jom 
        • jom - parallel alternative to nmake, Microsoft Windows platforms
      • Qt 5 on Windows ANGLE and OpenGL
        • OpenGL ES 2.0 for embedded systems
        • QtMultimedia
        • Microsoft Windows RDP
    • Qt, Qt Smoke interfaces, and CLtL
  • A survey of free/open source software distribution models
    • Debian
      • Feature: Standardized, extensible packaging system
      • Feature: Command-line package management tools
      • Feature: Package signing
      • Feature: GUI package management tools available
      • Feature: OS-wide package management for Debian GNU/Linux and Debian-based GNU Linux distributions
      • Feature: Package dependency management specifications may include information about direct build dependencies
      • Feature: Repository structure delimited according to release objects, e.g. "Woody"
      • Feature: Allows convenient backporting of source packages, between individual release sets
    • Cygwin
      • Feature: Central repository of free/open source software (FOSS) for Microsoft Windows platforms
      • Feature: GUI package management tool
    • Eclipse Update Sites
      • Feature: GUI package management for Eclipse IDE extensions
      • Feature: Licensing notification, previous to installation time
      • Feature: XML format for repository metadata
      • Feature: Some extensions provide their source code in separate extension packages
    • Maven Repositories
      • Feature: Extensible model for public/private distribution of Java archives
      • Feature: Package metadata is defined in an XML POM (Project Object Model) file
      • Feature: Allows for distribution of source archives in parallel to compiled source archives
    • Emerge (KDE edition)
      • ....
    • See also: ChromiumOS source code repositories
      • ...

Backtrack Log

Errors were encountered when installing the following packages via Cygwin 
  • libcom_err2-1.42.10-1 (package libcom_err2, located under 'e2fsprogs' directory in the local package downloads cache)
    • "Unable to extract /usr/bin/cygcom_err-2.dll [...]"
  • libintl8-0.18.3.2.2-2 (package libintl8, located under the 'gettext' directory)
    • "Unable to extract /usr/bin/cygintl-8.dll [...]"
  • Apparent cause: Files "In use" within another process; unable to overwrite, due to process file-locking.
The package installation process proceeded otherwise normally, despite those errors.

 Recommended resolution: Delete the downloaded package archives  for those packages, (Note: Possibly not necessary in this instance, but advised) and reinstall those packages, via Cygwin Setup.exe, after all of the packages are installed.

Those errors were repeatable. The errors were a result of there being a Squid HTTP proxy service running in background, during the installation of those software packages.

Recommended resolution (Updated): When encountering a similar error message, shut down the Microsoft Windows Service for Squid HTTP proxy and select "Retry," in the dialogue window displaying the error message. After the installation completes, restart the proxy service -- observing that any access to the local HTTP proxy service will be interrupted, during the installation.

Posted by at No comments:
Labels: , , , , , , , ,

Thursday, June 12, 2014

Workspaces, Source Trees, and Working Sets - Towards an Abstract View Of Baseline Project Resource Container Models (Draft 7)


Brief Exposition

Earlier this year, I'd purchased a Chromebook. I'd made an extensive effort of detailing my "First boot," albeit as something of a "Chromebook Fanboy" then -- that, before I began to try to comprehend the ChromiumOS source code repository, a task that remains "Incomplete," to this day.

A couple of months after that "fist boot," my Chromebook became my primary development platform. That was around when my old/newest Toshiba laptop became unbootable from its internal hard drive -- as was certainly due to the hard shutdowns that that PC was so apt at making, when running MS Windows, and the corresponding filesystem corruption during the hard shutdowns, corruption apparently not only on the NTFS partition but also on the boot sector.  That laptop, with that internal hard drive, now cannot boot from the internal hard drive. I've certainly tried to recover that other laptop's internal hard drive, using SystemRescueCD, but to no avail. I can use SystemRescueCD on a DVD-ROM drive, to boot the PC and to chroot to the existing Linux partition on that PC, and from that chroot, I can even 'mount' the primary NTFS partition on the hard drive, and any of the two NTFS-format rescue partitions. I've tried to use TestDisk to recover the MBR and make the internal hard drive bootable again, but to no avail. At some future time, I might endeavor to install an SSD drive into the laptop, and to image the old hard drive onto that SSD, across the "swap."

When I was using my Chromebook as my primary development platform -- granted, absent some features such as SBCL, Virtualbox, and QEMU, it being a Samsung Chromebook, and therefore an ARM Chromebook -- first, I'd installed a KDE chroot using Crouton. Using that chroot environment, I'd begun to make use of an SD card that I had around, a little 16GB media card, to store the files of the chroot desktop workspaces.

An ad hoc Workspace Model

In regards to how I had developed workspaces on that SD card, it was essentially similar to how the Eclipse IDE manages workspaces  in the Eclipse IDE. Sure, though, the approach I had developed was distinctly ad hoc. In a personal regards, I was using only Emacs as an IDE -- Eclipse Kepler not being available via the Ubuntu ARM ports, at that time. In the approach I'd developed for ad hoc workspace development on that SD card, I basically had made one workspace per each specific task area such as I could endeavor to collect and to develop source code resources within.  For instance, I'd made an a workspace for working with McCLIM, on that platform -- ultimately, porting McCLIM to ECL and CCL,  The last workspace that I'd made, on that platform, it was essentially for building an Eclipse Kepler edition for ARM, using the Ubuntu Eclipse source package. I'd left that aside, however, when I discovered that as well as I would also to backport Jetty for that, I'd also have to backport Apache Tomcat 7. I wasn't certain of how much further the backport list would expand from there, so I left that backport project aside, in its workspace.

Presently, I have a great, new, remarkably well featured and furthermore remarkably student budget friendly HP Pavilion 15" TouchSmart PC. In the process of making it "My PC," I've since made a TAR archive of my workspaces set on the Chromebook, transferred it to the Pavilion PC using SSH, then configured the Cygwin environment on the Pavilion PC to create native MS Windows Shortcuts in lieu of Symbolic Links, and then unpacked the archive as transferred. 

Presently, before finishing that workspace migration, I would like to take some time to reconsider how I've organized the workspaces of the same -- considering that in the Eclipse IDE, I could use project groups, alternate to filesystem directories, for creating something like my Chroebook's ad hoc workspaces, namely for organizing source trees into task groups, insofar as in metadata created and applied by the Eclipse IDE.

The tangential idea that -- in regards to this article -- that I am "looking for," I think, is to create a portability layer for working with Eclipse IDE workspaces in a development environment in Common Lisp.

There is a pragmatic concern, also. As a case in point, there's my CCL workspace from my Chromebook, in which I've cloned a source tree for each of:
  • CCL Linux ARM, release 1.9
  • CCL Linux ARM Trunk
  • CLX, as in portable CLX
  • FFIGEN4, as forked by CCL
Presently, I'll need to add a CCL Windows Trunk source tree to that short list. I would like to be able to keep that short list consistent, of course, for synch back to the Chromebook -- and that, in developing not any sort of hack in tools development, around this task.

Migrating the SCCM Repositories

When I was migrating the Chromebook's workspaces onto my Windows 8 laptop, I observed that I might have to update the Git config for each Git repository now on the latter, to ensure that each Git repository is using a desired semantics for text file line endings on the Microsoft platform, as well as with  specify settings with regards to symlink handling, file permissions, pathnames, and for using SourceGear DiffMerge as a tool for the diff and merge commands in Git. 

Sure, I've used git config to specify some site-specific default settings for those configuration items, however I'm concerned that I should have to ensure that all of those configuration items will override any current repository-specific configuration settings as such, for those configuration items, and onto those source tree items that I've now migrated from an Ext4 filesystem.

Of course, there are also some SVN and CVS managed source trees in that set of workspaces. I think, it calls for a development of an abstract model for SCCM tools and interfaces

Workspace as Concept

Presently, I would like to begin a tangent about ISO topic maps and/or SKOS and/or CORBA. Briefly:

  • A workspace -- in a sense of a container of digital file source trees and changesets -- can be modeled as a SKOS Concept
    • ...regardless of the SCCM tool used for each respective soucre tree and changesets
    • ...and in such a manner a that the SKOS Model thusly defined may be applied by developer tools within an integrated desktop environment, as for a purpose of "checking out" a sort of broader "thing" than a Git repository with submodules  -- namely and rather, for "checking out" or "cloning" such a workspace as would be defined in such a SKOS model
  • SKOS 2 is implemented in OWL
    • OWL is supported with the ODM metamodel published by the OMG
    • MOF2I, published by the OMG, provides a means for transforming an MOF metamodel into a set of IDL interface definitions, though of course the practical details of the transformation may seem however obscure in all of the the rhetorical statements in the MOF2I specification
  • A CORBA-backed distributable service could be developed for checking out workspaces, in using a model derived of the SKOS model -- possibly, integrating persistent CORBA IOR URI into the OWL+SKOS metamodel, furtermore
    • Such a network service could be userfully implemented on a thin client platform, or on a PC

Workspace as Filesystem Resource

An Eclipse IDE workspace may contain an indefinite number of source trees -- literally, filesystem resources -- each, loaded as an Eclipse project, with corresponding Eclipse IDE project metadata.

Each source tree may be categorized, within the Eclipse IDE, within zero or more working set items. Those working set items would, in each, be local to the Eclipse IDE workspace that is being visited in the Eclipse IDE. (An Eclipse IDE working set would be similar to the concept of ad hoc filesystem workspace, as I'd made when developing on my Chromebook)

The set of working set items in a single Eclipse IDE workspace is listed in the workspace metadata created by the Eclipse IDE, in each specific Eclipse IDE workspace. However, rather than editing the metadata external to the metadata controller application -- in this situation, the Eclipse IDE -- it would be more advantageous to use an interface within the Eclipse IDE -- such an interfaces as may be available, hypothetically, for a sort of provisioning of project resources in the Eclipse IDE.

Workspace as CORBA IDL Interface

Hypothetically, it is possible to share working sets between individual desktop platforms -- ostensibly, in an extension to the Eclipse IDE, as well as in extensions to other desktop applications such as Emacs SLIME, and mobile applications such as Textastic. A CORBA architecture may be developed, for such an extension -- implementing sort of a peer to peer CORBA architecture for authorized workspace sharing between individual desktop PCs and thin client platform applications, or alternately, for sharing workspaces and project information in synchronization with a central project management server, the later also using CORBA .

In CORBA IDL, the interface definitions for the source-tree/working-set association model would be essentially trivial -- such as to define an IDL interface SourceTree (container, contained), and an interface, WorkingSet (container), with a few simple operations in each respective IDL interface definition for managing a doubly-linked list associating zero or more SourceTree items with each WorkingSet.

 Of course, the WorkingSet interface would, in itself, need a convenient, additional interface available -- such as may be defined with a name, WorkspaceManager -- for listing a set of WorkingSet instances registered within a CORBA ORB. The WorkspaceManager and Workspace interfaces could then be defined as to contain similar operations for operating on a doubly-linked-list associating zero or more WorkingSet objects with a single WorkspaceManager

Applications for a CORBA Workspace Manager

  • Central management of user/team workspaces, working sets, and working-set/project associations
    • Towards an abstract concept similar to Git submodules and SVN externals
      • May be defined in such a manner as to be applicable not exclusively onto a single SCCM service, but rather, as to be portable onto multiple SCCM services (Git, SVN, Hg, Darcs, CVS, ...) 
      • May be designed as to allow for team synchronization of workspaces, across a heterogeneous SCCM service mix
      • Might provide some features such as may be functionally analogous to some features provided in the Eclipse IDE, primarily in the Eclipse Team extensions
    • May be applied as effectively a component for a team SCCM application framework, for LAN-local developer teams and for distributed developer teams
    • May be utilized within centalized workflows for distribution management and reporting for projects
  • May be utilized within mobile development applications, essentially as a sort of distributed project model

Commensurate Dependency: Multi-User Model in CORBA

To define a multi-user WorkspaceManager as an application of CORBA network service technologies, it would require a definition of a set of CORBA IDL interface definitions, for defining a user model in CORBA IDL.
  • Goals:
    • to support user authentication in CORBA interface implementations
    • to provide interfaces for user identity management, for application within user authorization procedures, in extensional implementations of CORBA interfaces
    • for application in the Project WorkspaceManager design and its implementation
    • for application within other CORBA application designs entailing multi-user access and authorization models and corresponding procedures applied onto digital resources, within a CORBA services network
  • References for a central user model interface library, in free/open standards and free/open source software models, may include:
    • Liferay. Security and Permissions, in manual: Liferay Portal 6.2 Developer's Guide
      • The Liferay Portal Permissions DRAC model extends on the JSR 286 Portal Resource model, and JSR 286 Principal Security model
      • Refer to the following sections of JSR 286 (PDF):
        • Section PLT.21, User Information -- referencing JSR 286 user attributes
        • Section PLT.24, Security -- noting section PLT.24.2, Roles, and the corresponding section SRV.12.4 of the Servlet Specification as referenced in JSR 286, namely JSR 154, Java Servlettm 2.4
    • Picketlink IDM -- as used in GateIn and the eXo Platform
    • OpenLDAP
      • Note that the Liferay, GateIn and eXo Platform portal frameworks, when installed, can each be configured to use an LDAP service for principal authentication and principal metadata within the web portal
      • Furthermore, a Linux host can be configured to use an LDAP service for host-level principal authentication
      • Therefore, LDAP might be preferred as a a central principal information service for networked applications
      • Observe the features of OpenLDAP's functional model -- as detailed in the OpenLDAP Administrator Guide 2.4  (alternate editions)-- including:
        • Central, selective LDAP directory replication, using OpenLDAP slurpd
        • OpenLDAP backend service interfaces
          • BerkeleyDB
          • SQL
          • Others
      • Alternatives: On the Java platform, Apache DS provides a Java-based LDAP server implementation. On Microsoft Windows host networks, consult documentation about Microsoft Active Directory.
    • PAM, NSS on Linux
      • Note configurations for using an LDAP service as a principal authentication service on a Linux host, using PAM and NSS
    • Kerberos
      • Note, specifically, the concept of a domain in Kerberos
    • X.509 (PKI/PMI) -- referencing:
      • X.509 article at Wikipedia, the Free Encyclopedia
        • Note, specifically, the concept of certificate revocation lists
      • strongSwan -- free/open source VPN service application
      • EJBCA -- Java-based X.509 Certificate Authority (CA) service
      • OpenSSL -- free/open source X.509/SSL toolkit
      • CORBA 3.3, module CSI

Implementation Proposal

CORBA ORB Implementations
  • JacORB, 
    • Contexts
      • Eclipse IDE plugins
      • Liferay 'ext' plugins
        • JacORB CORBA service for Liferay 
          • Observe that a "new" JacORB service installation would collide with the CORBA services provided by some enterprise application containers such as Glassfish, but would provide necessary functionality lacking from a "Bare bones" Liferay installation onto Tomcat 7
        • Implementation of CORBA user model onto Liferay
        • Implementation of additional IDL interfaces onto JSR 286 (comprehensive)
      • Liferay 'portlet' plugins
        • Workspace view (project resource list)
        • WorkspaceManager porlet (workspace list)
        • configuration dashboard component for WorkspaceManager
    • Observe that JacORB supports authentication with Kerberos (LAN, etc)
  • CLORB, in the Common Lisp components

Posted by at No comments:
Labels: , , , , , , , , , , , , , , ,

Friday, May 23, 2014

Notes - Towards an Eclipse Kepler Distribution in Debian Packages, a Domain Model for Computer Operating Systms, and CCL for FIrefox OS

At a time earlier, this week, I'd installed Eclipse IDE via the Ubuntu 12.04 "Precise" package repository,  under the chroot environment installed on my Samsung Chromebook, which runs Linux on an ARM architecture -- as I'd noted in a blog entry, along with a convenient Eclipse platform versions/names table excerpted from Wikipedia, the Free Encyclopedia
My having observed that the Eclipse IDE, in its version as available via the Ubuntu package repository --  correspondingly, via the Debian source package, eclipse -- that it is not the latest release version of the Eclipse IDE, moreover that that entails that some plugins such as of the Eclipse Papyrus modeling tools project will not be available to the user, in their newest versions, when  installing the Eclipse IDE via the Ubuntu package repository, I've begun looking into the question: How to build Eclipse 4.3, "Kepler", for Ubuntu on Linux ARM?

 Of course, although a Linux ARM build of the Eclipse IDE is available via both Debian and Ubuntu, however the Eclipse.org web site does not provide an Eclipse build for that architecture. Eclipse.org does provide downloads compiled for Linux x86, in 32 bit and 64 bit architectures, but nothing for running the Eclipse platform on ARM.

The Debian source package, eclipse, publishes a convenient Git repository, in a sense of both browsable (HTTP) and cloneable (GIT URI) repository services. There's also a convenient, moreover exhaustive list of build dependencies, published at the page for the Debian source package, eclipse. So, with that great level of developer convenience being available, about the Debian eclipse source package, and with my being interested in effectively updating the Debian eclipse source package to provide Eclipse 4.3 -- at least, in a local prototype build --  I've cloned the Git repository for the Debian eclipse source package.

When taking a look at files under the 'debian/' directory of the cloned source tree, I've found the file, 'debian/README.Source', in which some core features of the architecture of the source package are described, including:
  • The Eclipse Build component of the Eclipse Linux Tools project
  • A platform source archive, eclipse-${VERSION}-src.tar.bz2
Alternately, one may follow the Eclipse Linux Tools Project' Eclipse Build instructions unadordned, to the latest Eclipse source code, on ARM, albeit without the additional Debian packaging for redistribution -- substituting a Debian package dependency management command line tool such as aptititude instead of yum.

.... and that would be fine, except for the dependency on Jetty. Ubuntu 12.04 "Precise" does not provide a jetty-server.jar file. There is, however, a jetty8-server.jar available in the libjetty8-java package, in the "Trusty" edition (file list)

 So, for backporting Jetty 8.1 from "Trusty" to "Precise" (source-package jetty8, "Trusty" edition) some of the build dependencies for jetty8 must also be backported from "Trusty", namely:
  • libgnumail-java (>= 1.1.2-7) source package libgnumail-java
  • libtomcat7-java (>= 7.0.28) source package tomcat7 
  • glassfish-jmac-api (>= 1:2.1.1-b31g-2) source package glassfish
Of course, one might expect that a backport of each of Apache Tomcat 7 and Glassfish  might require, in each, a further set of additional backport builds. 

 Failing the availability of a an ARM port of "Trusty", this would be one approach towards building Eclipse 4.2 "Kepler" on the Ubuntu "Presice" release, in the ARM architecture of that release of the Ubuntu GNU/Linux distribution.

Towards a Domain Model for Operating Systems and OS Distros


This backporting task, it may be further facilitated with the development of some additional software tools. Specifically, if developing a Common Lisp program to facilitate this package backporting process, one could begin by developing an abstract domain model out of this generic software task, in Common Lisp, such as:
  • Class: Architecture
  • Class: Release
  • Class: Distribution
One could then extend that abstract domain model into an instance-specific model, such as for an application of that msamodel onto the Ubuntu GNU/Linux distribution. Of course, one might be aware of that the Ubuntu GNU/Linux distribution derives from the Debian GNU/Linux distribution, and uses the same essential software dependency management and software distribution tools, in the same as Debian GNU/Linux and most distributions deriving from Debian. 

That would be to the definition of a toolchain disjunct to that of the Red Hat and Fedora GNU/Linux distributions -- such as  Red Hat's commercially-supported enterprise edition distros like RHEL, or a Fedora Spin distribution, such as the Fedora Electronics Lab.
In a modeling sense, one may define the domain model such that the class, "Linux Distro" would be defined as to extend "Distribution", a class, and that each of "Redhat Distro" and "Debian Distro" would be defined as to extend the class, "Linux Distro".  

Subset of Domain Model: Non-Linux RTOS Distros

Furthermore, though it might diverge from the set of operating system platforms ostensibly compatible with the Debian Free Software Guidelines (DFSG) in any core portion, one could consider defining a class, "QNXNeutrino" as an extension of the class, "Distribution," as when the class "Distribution" would represent a broad sense of an "Operating System Distribution", if not specifically "Realtime Operating System (RTOS)  Distribution". 

In the RTOS domain, there's also FreeRTOS, itself a free/open source platform with commercial support available (summary of FreeRTOS licensing)

RTOS Linux

Sure, it may be viable to apply Linux as an RTOS. However, it might yet be difficult to find exact commercial support for RTOS applications of Linux. Certainly, there's commercial support available for Linux in server applications, and for Linux in desktop applications. However, as far as Linux in industrial automation systems, automotive passenger device systems, and other ostensible applications for RTOS frameworks, one might wonder if there is any commercial support available for such application, of Linux "as yet." In conducting one's research, then, one might find that there are a number of inactive projects for RTOS Linux, including:

In a contemporary regards, there's Xenomai and the corresponding RTAI interface for timing-restricted applications, ostensibly with an XML-based server/RPC compliment, RTAI-XML, perhaps as an alternative to Realtime CORBA.

So, indeed, there's RTOS support of a kind, available for applications of the Linux platform. Sure, it might not meet with the most immediate demands of the world's boldest Ringworld engineers -- with apologies to fans of Larry Niven. However, with some patience and effort, it could turn out to be all of a commercially viable RTOS platform -- among things that one would not be able to add to a formal academic thesis.

Subset of Domain Model: Lisp Machine Operating Systems

Sidebar: Common Lisp is not BASIC is not a Horse Race

The reader might not be familiar with the author's position about the Common Lisp platform. Sure, in a personal regards, it's been nothing short of a long, rough road to the author, in studying the Common Lisp programming language and its applications, thus far, and certainly it's a none too commercially common platform, in the industry of the epoch. As a programming language, Common Lisp is certainly a more developed programming language than BASIC, though. For instance, the BASIC language -- at least in its Tandy Color Computer 3 edition -- doesn't feature, in itself, any sort of an object-oriented programming model such as in ANSI Common Lisp (CLtL2), let alone anything to compare to the full metaobject protocol (MOP) in Common Lisp. GOSUB is still pretty cool, though, at least for "that kind of software programming" -- such as of virtual horse races on a console screen, or a financial break-even analysis for a small/home office, and so on, mechanically.

The reader would be even less likely to have been familiar with either of the author's grandfathers. Some things would go unknown, in life, for a period of time.

'Boston Beans', the Gazebo Hub Lisp History Project Edition 1

If every project needs a novel name to denote it by, I'd choose a practical name for the beginning of a history of the Common Lisp programming language and its implementation in computing machines -- nothing too ostentatious, a humble can of Boston Baked Beans, the inspiration (via Amazon.com Prime Pantry, in a pinch.)

So, then, but how does one set out, practically, to begin to define a history of the Common Lisp programming language and its applications in computing machines? Would it require anything short of the expeditious skill of the discoverers of the Elephant computer, if not  the mathematical and mechanical skills of her original engineers? (Heritage Universe, Wikipedia) 

Sure, a can of baked beans suffices, in such an extensive endeavor -- nutritious food, sugary but kind, good foodstuff extended with a few items of bread, beside.

To begin to define a model subset of an Operating Systems model, for Lisp Operating Systems, one might begin at such a practical beginning as one would know, and by that I am referring to a private, ongoing study -- albeit, a study of only some few months' duration, "thus far" -- of the design of the CADR Lisp Machine.

Though the author of this item understand that CADR was neither the first nor the ultimate Lisp Machine -- in itself, was preceded by the CONS Lisp Machine, and succeeded by the Symbolics Lisp Machines -- there is simply the practical concern that there are schematics and manuals available, all of legally and ethically, as public domain resources -- books detailing the design and operations of the CADR Lisp Machine and its corresponding operating system, items originally published by MIT's AI Lab. Ostensibly, those same schematics could be studied and redesigned for application in developing a Lisp Machine prototype onto an FPGA platform -- as whether or not one may  have applied oneself to schoolwork and furthermore, well enough for one to be a student of MIT, as the author of this item is not, albeit with regrets.

In that much, such a study would not serve to explain any of how a contemporary Common Lisp implementation may be effectively interfaced with a contemporary host operating system, such as Debian GNU Linux. In a senser, there might even be a sort of "Crossover" determined between definitions of "Lisp Implementation" and "Operating system", in which the original Lisp Machines would have provided both "Lisp Implementation" and "Operating System," in any single, complete "software package," as one might presume.

Of course, a history of Common Lisp might represent likewise a history of software, hardware, and engineering, so far as conducted to the development of Lisp Machines and Lisp programming platforms with, in each, a user interface of some kind.

That, in itself, might not insomuch represent a history of the development of multi-user networked operating systems and industry specifications such as POSIX and the X/Open Portability Guide (XPG). Sure, it's not a monopoly, computer history, whether by way of Lisp Machine, or CP/M, or UNIX, or NeXT, or otherwise.

...and sure, there is history in computing, and there are contemporary models, in computing. It's unlikely that the later could have developed without the former -- it being not like any matter of the lucky turnip or the spontaneous "theory" undeveloped of practical application. One might choose to study either and both, then, in developing a contemporary application of computing, in a generic sense. Alternately, one might wonder: Of whence would new applications be developed, except of existing work?

Towards a "State" of the Turnip - Principia "Turnip" Milestone

Sidebar untold, momentarily: The Principia Project, and the Gazebo Hub.

With regards to the question of "Existing work," but presently, leaving aside the epistemological discussion with regards to patent guidelines -- i.e patent laws -- such as might exist in any single world nation of somesuch commercial development, there's still the question of how to define a subset of a model for operating systems, if specifically about Lisp Operating Systems -- considering not only that the history of Lisp Machines might be scarcely known, in the contemporary industry, but furthermore that there may be a hybrid model defined, of a Lisp/Linux system. Certainly, the a project for development of a hybrid Lisp/Linux system, such a projecxt could be conducted towards a more immediate commercial interest, in contemporary computer platform development, broadly, "The Industry." If it could seem to be a platform seeking of a sense of relevance for popular interest, one could sketch out a few ideas, at that -- all of which might seem more geared toward crowdsourcing than towards any manner of a conventional corporate model:

  • At a server tier: Definition of a parallel computing model for parallel logical and statistical calculations onto the Amazon Elastic Compute Cloud (EC2) and affiliated components published by Amazon Web Services (AWS), using Lisp on Linux
  • At a desktop tier: Definition of a data flow model  for Common Lisp programs, and a corresponding graphical interface, inspired by National Insturments (NI) LabVIEW(TM), using Lisp on Linux, with extensions specifically for using interfaces available in single-board computing platforms such as BeagleBone Black and  the PRU-ICSS  module in the TI Sitara MCU on the BeagleBone Black, for data-flow programming onto I2C device networks, inspired by NI LabVIEW(TM). 
  • At a device tier, in a long term effort: The lovely project of transcribing the CADR schematics into an EDA format, revising that same schematic for a single device platform's memory, clock, and other interfaces, ostensibly using the Papilio FPGA platform, and then implementing something like a Lisp operating system onto that same platform (viability unknown). 
  • Alternately, at a device tier, for defining a further computing platform, though without designing a "new OS", initially: Linux as RTOS, and Lisp, "Various projects", many of which might be ad hoc, in a sense, no doubt (recommended focuses: CORBA, I2C, parallel computing, ostensibly towards the definition of a realtime computing supercluster using Linux and single board computers having  I2C interfaces). See also: Liu, B., Y. Wen, F. Liu, Y. Ahn, and A. Cheng. "EcoMobile: Energy-aware Real-time Framework for Multicore Mobile Systems." (2011).
  • Alternately, at a device tier, using only existing computing platforms without further interfaces and extensions: An investigative study of Clozure Common Lisp (CCL) and McCLIM extended for Cairo on the FirefoxOS platform. See also:


(This is 'blog entry draft 6, 2 June 2014)
Posted by at No comments:
Labels: , , , , , ,

Tuesday, May 20, 2014

Eclipse IDE - Versions / Version Names Table

In the interest of having a UML tool available on my Chromebook's Crouton Chroot (KDE) I've installed the Eclipse IDE.

My Chromebook is a Samsung Chromebook, and it uses an ARM microcontroller unit. I've installed the Eclipse platform from the Ubuntu 12.04, "Precise" repository. The Eclipse Platform edition available via "Precise" is at version 3.7.2, i.e Indigo.

In the interest of disambiguation, I've found a convenient table of version number/name pairs, at the Eclipse (software) page at Wikipedia, the Free Encyclopedia. With reference denoted directly to that resource, for the following direct copy of that table, here is the version/names table, "to date".


Version NameDatePlatform versionProjects
N/A21 June 20043.0[14]
N/A28 June 20053.1
Callisto30 June 20063.2Callisto projects[15]
Europa29 June 20073.3Europa projects[16]
Ganymede25 June 20083.4Ganymede projects[17]
Galileo24 June 20093.5Galileo projects[18]
Helios23 June 20103.6Helios projects[19]
Indigo22 June 20113.7Indigo projects[20]
Juno27 June 20123.8 and 4.2[21]
Juno projects[24]
Kepler26 June 20134.3Kepler projects[25]
Luna25 June 2014 (planned)4.4Luna projects[26]
Mars24 June 2015 (planned)4.5Mars projects[27]

The formatting and footnotes from the original Wikipedia article are preserved, here, respectively in the interests of brevity and informativeness.

The Ubuntu Debian source package for the Eclipse platform is eclipse. The source package is currently available at Eclipse Platform version 3.8, i.e Juno

I'm not sure why the Ubnut Ubuntu eclipse package is not keeping up with Eclipse IDE platforms releases. Kepler would be the preferred edition, certainly.

So, alternately, I can try to open up such a proverbial can of worms as would entail compiling Eclipse 4.3 "From scratch." For some reason, I'm unable to download an edition compiled for Linux ARM, if directly from Eclipse.org, and the edition at Ubuntu.com is not "Up to latest" The Ubuntu edition does, however, match the version of the edition available via the Debian eclipse source package , currently available at 3.8.1-5.1 in Debian Jessie and the "continuous" Sid edition.

Presently, I think I'll just rely on the IDE's built-in package upgrades system. If there have been any changes in the SWT binding or the JVM interface since Eclipse Platform 3.7, then in a word, "Darn," those won't be available on my Chromebook, unless I can figure out how to compile Eclipse 4.3 directly from source, either on my Chromebook, or (more complex) on another platform, with cross-compile.

I think I'll just use the built-in Eclipse plugin uprgades feature, "for now", and so inasmuch I'll have to use the  Indigo edition of the Eclipse Papryus plugins.  "Good times...."
Posted by at No comments:
Labels:
Subscribe to: Posts (Atom)