ABSOLUTE POWER A film review by Edwin Jahiel Copyright 1997 Edwin Jahiel
ABSOLUTE POWER ** Directed by Clint Eastwood. Written by William Goldman from the novel of David Baldacci. Photography, Jack N. Green. Editing, Joel Cox. Production design, Henry Bumstead. Music, Lennie Niehaus. Cast: Clint Eastwood (Luther Whitney),Gene Hackman (President Alan Richmond), Ed Harris (Detective Seth Frank), Laura Linney (Kate Whitney), Judy Davis (Gloria Russell), Scott Glenn (Bill Burton), Dennis Haysbert (Tim Collin), E.G. Marshall (Walter Sullivan), Melora Hardin (Christy Sullivan). A Sony release from Columbia Pictures of a Castle Rock presentation of a Malpaso production. 120 min. R (violence)
The historian John Emerich Edward Dalberg Acton (1834-1902), who became Lord Acton of Aldenham in 1869, was the first great modern philosopher of resistance to the evil state. He stressed morality above all. Though known mostly to specialists today, millions (mis)quote his aphorism, from a letter he wrote to Bishop Mandell Creighton in 1887: "Power tends to corrupt, and absolute power corrupts absolutely."
In theory it is hard to resist a political thriller with the explicit title "Absolute Power," especially when it is by and with Clint Eastwood in his familiar persona as an enemy of misused and abusive authority. Enticing too is that Clint plays an master cat burglar, an avocation beloved by readers and moviegoers --vide Cary Grant in "To Catch a Thief" or The Saint.
Yet, except for one dud ("The Rookie") the film is not in the league of Eastwood-directed works since 1990: the shamefully neglected "White Hunter, Black Heart," "Unforgiven," the acceptable "A Perfect World,""The Bridges of Madison County." In spite of changes by sometimes excellent screenwriter William Goldman, "Absolute Power" does not raise the shabby source novel to any heights, or add anything to the spate of pictures about US. Presidents. Though the actors and techniques are very good and polished, the plot is a salad of incoherences, disconnections and non sequiturs, arbitrary moves, laughable incredibilities, improbabilities and impossibilites, coincidences and plot craters. Over those ingredients is poured a sauce of movie cliches.
The story centers around aging, much decorated Army veteran and veteran thief Luther Whitney, played with the steely nerves, the cool, the tongue-in-cheek humor expected of Eastwood. One night, he burglarizes a mansion to end all mansions, defeating in ho-hum seconds state-of-the art locks and security systems.  As he moves carefully in semi-darkness, he glimpses paintings by masters and other art treasures. The sequence has good tension but is stretched out, as if the filmmakers wanted to get their money's worth for their elaborate movie set.
Luther fills his bag with millions in jewelry, coins and cash. Sudden noises force him to retreat behind a most convenient two-way mirror.  These turn violent. As the man seems ready to strangle his companion, she stabs his leg with a letter-opener. In a flash,two men materialize and shoot her dead.They're Secret Service men who guard U.S. President Alan Richmond.
 His flushed complexion speaks of illness or alcohol. He is a king-maker, a very good FOA (Friend Of Alan's). "I gave him the Presidency" he says later.
A cover-up follows, led by Chief of Staff Gloria Russell, played by Judy Davis with campy black humor. The hunt for the killer is on. Luther is a major suspect because, as per the old cliche "there are only seven men" who can burglarize so well.
That Clint can be very likable is a given. But he allows his film to grow exponentially absurd. To flesh it out, newish widower Luther has an estranged daughter, Kate. She is cute, unattached, and of all things, a prosecutor. You can sniff instantly the reconciliation to come. Or the mutual attraction between Kate and chief investigating detective Seth Frank (Ed Harris). He too is conveniently unattached."I live by myself" is his leitmotif to Kate. Frank is nice, decent, well-mannered, simpatico. Eastwood and Harris have by far the best scene as they lunch together, play wittily cat-and-mouse, and like each other.
In a baffling scene, Luther, about to catch a plane and disappear abroad, is at the airport. He sees on TV the President delivering a piously hypocritical declaration concerning his "like-a-father-to-me" mentor Sullivan. Instantly Luther decides to stick around and do the right thing. Had he not realized that the man he had watched through the mirror was the President? Go figure.
Try also to make sense of the many appearances of key people in places where they couldn't possibly be. Or how they get to their desinations in mere minutes. Or how quick-change artist Luther disguises himself so fast.
I have a weakness for disguises. My first publications, in a children's magazine, were signed "Detective X" after my pulp fiction hero in stories by Brand House. "X" had a stupendous ability for instant transformations that made him a clone of anyone he wished to impersonate. Still, to quote Corinthians: "When I was a child, I spake as child, I understood as a child, I thought as child; but when I became a man, I put away childish things." Like suspension of outrageous disbelief.
In another mega-silly sequence, for reasons hard to fathom, a cafe meeting is set up between Kate and her dad. Dozens of Washington, D.C. cops, sharpshooters and marked cars skulk around --but no Army tanks or rocket launchers. Yet no one seems to notice. There's also a gunman hired by old man Sullivan. How he knew eluded me.Clint appears in a beard, hat and designer long coat. He escapes a fracas in a flash, because under the coat he wore a policeman's uniform and a cop's cap.Try it. D.C. becomes DC comics.
One more item among many. Kate is now in danger. "Good news," Harris tells Eastwood on the phone "the Secret Service is taking over surveillance." It's like saying"Great, the foxes will protect the chickens." How much better did Alfred Hitchcock's "The 39 Steps" manage when the hero tells his new host in Scotland that the archvillain is unknown but has a finger missing. "Like this?" says the host, showing his hand.
No character is dimensional, nothing is thoughtful or thought through or cerebral. The "exposes" of the Washington establishment are nullified by caricature. In spite of occasional good moments, the film is merely a tabloid, the screen equivalent of the National Enquirer. =========================== This review and others can be found at : http://www.prairienet.org/ejahiel/
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Jacob Mattingley, Ph.D.
() |
Automatic code generation for embedded convex optimization
Computer modeling of convex problems
CVXGEN, an online tool for creating extremely fast solvers
CVXMOD, a Python tool for convex optimization
jemdoc, a light, \(\mbox{\LaTeX}\) equation supporting, text-based markup language for creating websites
CVXGEN: A Code Generator for Embedded Convex Optimization, J. Mattingley and S. Boyd, Optimization and Engineering, 13(1):1–27, 2012
Code Generation for Receding Horizon Control, J. Mattingley, Y. Wang and S. Boyd, Proceedings IEEE Multi-Conference on Systems and Control, pages 985–992, Yokohama, Japan, September 2010
Real-Time Convex Optimization in Signal Processing, J. Mattingley and S. Boyd, IEEE Signal Processing Magazine, 27(3):50–61, May 2010
Automatic Code Generation for Real-Time Convex Optimization, J. Mattingley and S. Boyd, chapter in Convex Optimization in Signal Processing and Communications, Y. Eldar and D. Palomar, Eds., Cambridge University Press, 2009
Code Generation for Embedded Convex Optimization, given at Stanford University in October 2010, and NASA JPL and Caltech in November 2010.
Code Generation for Receding Horizon Control, given at IEEE MSC in Yokohama, Japan, September 2010
Embedded Convex Optimization, given at UC Berkeley and at KU Leuven, March 2010
CVXMOD: Convex Optimization in Python, given at the INFORMS Annual Meeting in Washington DC, 2008
Instructor for:
Introduction to Linear Dynamical Systems (EE263s), Stanford University, Summer 2009
Embedded and Convex Optimization for Control, one week course, KU Leuven, Belgium, March 2010
Teaching assistant at Stanford University for:
Introduction to Linear Dynamical Systems (EE263), Autumn 2006, 2007 and 2008
Linear Dynamical Systems (EE363), Winter 2009
Convex Optimization I (EE364a), Winter 2008
Convex Optimization II (EE364b), Winter 2007 and Spring 2008
Ph.D., Electrical Engineering, Stanford University, March 2011
M.S., Electrical Engineering, Stanford University, June 2007
B.E. (Hons) (First class), Electrical and Computer Engineering, Canterbury University, April 2005
Extremely short Matlab LP solvers (fewer than 80 characters per solver)
vim:essentials, a short page describing some of the essential features of the vim text editor
Various computation speeds in C


The Git plug-in git flow implements a generalized Driessen branching model. This document describes the basic feature of the model and how git flow and its high-level commands can be applied to EPICS V4 development repositories.
This document is accompanied by a shell script that executes all procedures mentioned. The script itself can be used as a reference, the sample repository is a nice disposable sandbox.
This document describes the suggested git flow procedures for EPICS V4 development as of 2015-03-09. It is not complete, and is intended to be a background for informed discussion and decision.
describe working with hotfix branches.
Describe working with support branches.
Describe procedures for multiple master trunks, i.e., parallel development of several versions.
Since modern distributed revision control systems have gained popularity within software developers, many branching and workflow models have been developed, which differ in features and grade of adoption.
A particular model that has gained wide-spread popularity is the workflow developed and described 2010 by Vincent Driessen, originally for the Git version control system, referred to as the Driessen branching model.
This document uses the original illustrations by Vincent Driessen.
For larger projects with many developers, a model based on one development line in a central repository is not working well. Processes like large feature developments (with multiple developers involved) and the preparation of a new release (going through phases of pre-releases and release candidates) can take weeks and would block the development of other features or important bugfixes. Support of older versions is hard. Tracking bugfixes across releases is tedious.
Vincent Driessen published a branched development model for Git in a blog article in January 2010. His original model was later extended with the addition of support branches allowing long-term support of older releases. The stream generalization allows to group branches in a directory-like fashion.
There are two main trunks with an infinite lifetime (i.e., created at initialization and never closed):
develop
. Small developments needing only one or two
commits can happen directly on develop
trunk, larger features
or features for a future release (i.e., not the next release) should be
developed in feature branches.master
is a release, and should be tagged accordingly.There are four additional streams (groups of branches), which carry a varying number of branches (i.e., branches are created and closed as part of the workflow):
master
), and
carries bugfix releases for that parent release. It is similar to the
master trunk: every commit is a release, and it is never closed.develop
(either off develop trunk or off
a develop branch), and are merged back into their parent.develop
(trunk or branch) when the releasing process starts.
It collects all changes necessary for that particular release (bugfixes,
tags), but no feature developments. When the release process is done, the
release branch gets merged into master
(creating the release),
and into its parent (feeding back the changes into the development
stream).master
(or a support branch). It
collects all changes necessary for fixing a bug and for a possibly
shortened release process. When the fix is tested and can be released, the
hotfix branch gets merged into its parent (creating the release), and often
into develop
trunk (feeding back the changes into the
development stream).Sub-streams of develop
and feature
can be created
in a directory-like hierarchy, to collect branches that belong together. E.g.,
the developments during a certain code sprint or codeathon could go into a
develop sub-stream, or different parts of a complex feature could be developed
in a feature sub-stream.
The following table lists the different types of branches in the Driessen model, with their most important properties.
| Name | Purpose | Properties | Created from | Merged into |
| develop trunk | main line "next release" development | minor features (~2 commits or less) are done directly on
develop , major features or developments for a future
version are done on a feature branch |
- | - |
| master trunk | main line of releases | every commit is a release | - | - |
| support branches | support releases (for older releases) | long term support (e.g., bugfixes) for older releases, every commit is a release | master trunk (at the appropriate release) | - |
| develop branches | grouping developments | developments for a specific release, or during a specific sprint/codeathon | develop trunk (or develop branch) | (its parent branch and) develop trunk, closing creates a release branch |
| feature branches | feature development | each major feature uses a dedicated feature branch for development | develop trunk (or develop branch) | (its parent branch and) develop trunk |
| release branches | release preparation | contains all changes that are necessary for a specific release, between first pre-release and the final release | development trunk (or develop branch) | master trunk and (its parent branch and) develop trunk |
| hotfix branches | fixing bugs | fixes for urgent bugs in released versions | master trunk, or support branch | master trunk and develop trunk, or support branch |
Within the context of git flow, the term stream is used for either a set of related branches, either at the top level or at the branch level, or for an individual branch. Some git flow operations can be applied as well to an individual branch as to a stream, i.e. to all individual branches that belong to that stream.
Features of this branched development model that might or might not be present in other models:
The develop and feature streams only contain development commits (and merges). The release stream only contains commits and tags from the releasing process. The master stream only contains public releases. The hotfix stream only contains bugfix commits.
master
is a public release, it is easy to
connect CI publishing jobs to it.The full Driessen model seems too complicated for use in V4 development. Only a small subset of the described features and streams is needed to support the current workflow. If streams and features are considered useful at a later time, they can be added as needed.
EPICS development does not follow the idea of one strict release branch that all releases can be created from. Usually, any EPICS release has long-time support and receives bugfixes as well as bugfix releases, each of which may or may not undergo a releasing procedure with multiple tagged pre-release versions.
To support this approach, the functionalities of release, master, hotfix, and support branches are combined in the release branches, which are not closed/merged, but left open to receive bugfixes and provide bugfix releases.
| Name | Purpose | Properties | Created from | Merged into |
| develop trunk | main line "next release" development | minor features (~2 commits or less) are done directly on
develop , major features or developments for a future
version are done on a feature branch |
- | - |
| feature branches | feature development | each major feature uses a dedicated feature branch for development | develop trunk | develop trunk |
| release branches | release preparation, bugfixes, bugfix releases | contains all changes that are necessary for a specific release, through the release process, bugfixes, bug fix releases, long term support | develop trunk | - |
This maps nicely onto the current workflow:
develop
trunk or on feature
branches (for larger developments), that are merged back into the
develop
trunk.develop
trunk (release/4.4). The release
process (tagging, bug fixing, pre-releasing, release candidates) and the
final release (4.4.0) are done on this branch. This branch stays open, and
further bugfix releases (4.4.1, 4.4.2, ...) are done as needed.develop
trunk as appropriate.Advantages:
develop
trunk at all,
so that development can immediately continue.develop
trunk.After explaining the installation and setup of
the git flow plugin, the Basic
Procedures section covers the initial workflow operations. These include
the mandatory develop
trunk, developing on feature branches, and
releasing on release
branches.
The Advanced Features section describes operations on that can be introduced as needed. This section is not complete.
You can execute the sample script, which will create a repository in a subdirectory called sample, and run all described operations using a small set of text files.
Use of the git flow plugin is not mandatory.
Install git flow (>= 0.4.1) according to the installation instructions
The tables containing the command examples always show the basic git commands (without using the git flow plugin) in the left column, while the git flow commands are shown in the right column.
Branched development is no picnic. Be aware of structures and procedures.
Back up your repository (local copy using cp -a
) before complex
operations.
Use the built-in help function: git flow help
will get you
started.
The EPICS V4 repositories will have an existing development history in the
develop
branch when being initialized for use with git flow.
In the top level of your repository, run the git flow init
command:
> git init |
> git init |
> git flow init -d |
You can switch to any branch or trunk using the git checkout
<stream>
command:
> git checkout develop Switched to branch 'develop' |
> git checkout develop Switched to branch 'develop' |
> git checkout feature/addFile3 Switched to branch 'feature/addFile3' |
> git checkout feature/addFile3 Switched to branch 'feature/addFile3' |
Switch to the develop
trunk:
> git checkout develop Switched to branch 'develop' |
> git checkout develop Switched to branch 'develop' |
Edit and commit as usual.
Create a feature branch off develop
trunk:
> git checkout develop Switched to branch 'develop' > git branch feature/addFile3 > git checkout feature/addFile3 Switched to branch 'feature/addFile3' |
> git flow feature start addFile3 Switched to a new branch 'feature/addFile3' Summary of actions: - A new branch 'feature/addFile3' was created, based on 'develop' - You are now on branch 'feature/addFile3' Now, start committing on your feature. When done, use: git flow feature finish addFile3 |
Edit and commit as usual.
When feature development is complete, finish the branch (first you might have to navigate to the branch you want to finish):
> git checkout feature/addFile3 Switched to branch 'feature/addFile3' |
> git checkout feature/addFile3 Switched to branch 'feature/addFile3' |
> git checkout develop Switched to branch 'develop' > git merge --no-ff feature/addFile3 Merge made by the 'recursive' strategy. file3 | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 file3 > git branch -d feature/addFile3 Deleted branch feature/addFile3 (was 6686eab). |
> git flow feature finish addFile3 Switched to branch 'develop' Merge made by the 'recursive' strategy. file3 | 3 +++ 1 file changed, 3 insertions(+) create mode 100644 file3 Deleted branch feature/addFile3 (was 6686eab). Summary of actions: - The feature branch 'feature/addFile3' was merged into 'develop' - Feature branch 'feature/addFile3' has been removed - You are now on branch 'develop' |
The feature branch is closed, and merged back into the develop
trunk.
Create the release branch off develop
trunk:
> git checkout develop Switched to branch 'develop' > git branch release/1.0 > git checkout release/1.0 Switched to branch 'release/1.0' |
> git flow release start 1.0 Switched to a new branch 'release/1.0' Summary of actions: - A new branch 'release/1.0' was created, based on 'develop' - You are now on branch 'release/1.0' Follow-up actions: - Bump the version number now! - Start committing last-minute fixes in preparing your release - When done, run: git flow release finish '1.0' |
Change, commit and tag preparing for the release on the newly created
release branch. This includes all changes necessary for pre-release and
release-candidate stages, up to preparing the final release. At any point,
changes and/or bugfixes on the release branch can be merged back into
develop
:
> git checkout develop Switched to branch 'develop' > git merge release/1.0 Fast-forward file1 | 2 +- file2 | 2 +- file3 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) > git checkout release/1.0 Switched to branch 'release/1.0' |
> git checkout develop Switched to branch 'develop' > git merge release/1.0 Fast-forward file1 | 2 +- file2 | 2 +- file3 | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) > git checkout release/1.0 Switched to branch 'release/1.0' |
The release branch is never closed, and works as a bugfix and support branch for this release. I.e., in this example it will carry the releases 1.0.0, 1.0.1, 1.0.2, ...
This section is not complete.


wo driven jocks help fax my big quiz. Quick, Baz, get my woven flax jodhpurs! "Now fax quiz Jack!" my brave ghost pled. Five quacking zephyrs jolt my wax bed. Flummoxed by job, kvetching W. zaps Iraq. Cozy sphinx waves quart jug of bad milk.
Obi-Wan Kenobi - A very bad quack might jinx zippy fowls. Few quips galvanized the mock jury box.  The jay, pig, fox, zebra, and my wolves quack! Blowzy red vixens fight for a quick jump. Joaquin Phoenix was gazed by MTV for luck
Few quips galvanized the mock jury box.  The jay, pig, fox, zebra, and my wolves quack! Blowzy red vixens fight for a quick jump. Joaquin Phoenix was gazed by MTV for luck.
Foxy parsons quiz and cajole the lovably dim wiki-girl. Have a pick: twenty six letters - no forcing a jumbled quiz! Crazy Fredericka bought many very exquisite opal jewels.
Quick wafting zephyrs vex bold Jim. Quick zephyrs blow, vexing daft Jim. Sex-charged fop blew my junk TV quiz. How quickly daft jumping zebras vex. Two driven jocks help fax my big quiz. Quick, Baz, get my woven flax jodhpurs! "Now fax quiz Jack! " my brave ghost pled.
Alex Trebek's fun TV quiz game. Woven silk pyjamas exchanged for blue quartz. Brawny gods just flocked up to quiz and vex him. Adjusting quiver and bow, Zompyc[1] killed the fox.
All questions asked by five watch experts amazed the judge. Jack quietly moved up front and seized the big ball of wax. The quick, brown fox jumps over a lazy dog. DJs flock by when MTV ax quiz prog. Junk MTV quiz graced by fox whelps.
Flummoxed by job, kvetching W. zaps Iraq. Cozy sphinx waves quart jug of bad milk. A very bad quack might jinx zippy fowls. Few quips galvanized the mock jury box.
Brawny gods just flocked up to quiz and vex him. Adjusting quiver and bow, Zompyc[1] killed the fox. My faxed joke won a pager in the cable TV quiz show. Amazingly few discotheques provide jukeboxes.
Foxy parsons quiz and cajole the lovably dim wiki-girl. Have a pick: twenty six letters - no forcing a jumbled quiz! Crazy Fredericka bought many very exquisite opal jewels. Sixty zippers were quickly picked from the woven jute bag. A quick movement of the enemy will jeopardize six gunboats.
Quick zephyrs blow, vexing daft Jim. Sex-charged fop blew my junk TV quiz. How quickly daft jumping zebras vex. Two driven jocks help fax my big quiz. Quick, Baz, get my woven flax jodhpurs! "Now fax quiz Jack! " my brave ghost pled.
© Daphne Economou | 05/02/2018.


| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Commands are first read from /etc/zshenv; this cannot be overridden. Subsequent behaviour is modified by the RCS and GLOBAL_RCS options; the former affects all startup files, while the second only affects global startup files (those shown here with an path starting with a /). If one of the options is unset at any point, any subsequent startup file(s) of the corresponding type will not be read. It is also possible for a file in $ZDOTDIR to re-enable GLOBAL_RCS. Both RCS and GLOBAL_RCS are set by default.
Commands are then read from $ZDOTDIR/.zshenv. If the shell is a login shell, commands are read from /etc/zprofile and then $ZDOTDIR/.zprofile. Then, if the shell is interactive, commands are read from /etc/zshrc and then $ZDOTDIR/.zshrc. Finally, if the shell is a login shell, /etc/zlogin and $ZDOTDIR/.zlogin are read.
When a login shell exits, the files $ZDOTDIR/.zlogout and then /etc/zlogout are read. This happens with either an explicit exit via the exit or logout commands, or an implicit exit by reading end-of-file from the terminal. However, if the shell terminates due to exec’ing another process, the logout files are not read. These are also affected by the RCS and GLOBAL_RCS options. Note also that the RCS option affects the saving of history files, i.e. if RCS is unset when the shell exits, no history file will be saved.
If ZDOTDIR is unset, HOME is used instead. Files listed above as being in /etc may be in another directory, depending on the installation.
As /etc/zshenv is run for all instances of zsh, it is important that it be kept as small as possible. In particular, it is a good idea to put code that does not need to be run for every single shell behind a test of the form ‘if [[ -o rcs ]]; then ...’ so that it will not be executed when zsh is invoked with the ‘-f’ option.
| [ << ] | [ < ] | [ Up ] | [ > ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Any of these files may be pre-compiled with the zcompile builtin command (Shell Builtin Commands). If a compiled file exists (named for the original file plus the .zwc extension) and it is newer than the original file, the compiled file will be used instead.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated on April 26, 2019 using texi2html 5.0.
Zsh version 5.7.1, released on February 3, 2019.


While TAR files and segments are a coarse-grained mechanism to divide the repository content in more manageable pieces, the real information is stored inside the segments as finer-grained records. This page details the structure of segments and show the binary representation of data stored by Oak.
Segments are not created equal. Oak, in fact, distinguishes data and bulk segments, where the former is used to store structured data (e.g. information about node and properties), while the latter contains unstructured data (e.g. the value of binary properties or of very long strings).
It is possible to tell apart a bulk segment from a data segment by just looking at its identifier. A segment identifier is a randomly generated UUID. Segment identifiers are 16 bytes long, but Oak uses 4 bits to set apart bulk segments from data segments. The following bit patterns are used (each x represents four random bits):
(This encoding makes segment UUIDs appear as syntactically valid version 4 random UUIDs specified in RFC 4122.)
Bulk segments contain raw binary data, interpreted simply as a sequence of block records with no headers or other extra metadata:
[block 1] [block 2] ... [block N]
A bulk segment whose length is n bytes consists of n div 4096 block records of 4KiB each followed possibly a block record of n mod 4096 bytes, if there still are remaining bytes in the segment. The structure of a bulk segment can thus be determined based only on the segment length.
A data segment can be roughly divided in two parts, a header and a data section. The header contains management information about the segment itself, while the data section stores the actual repository data.
Repository data is split into records of different types. Every type is specialized for storing a specific piece of information: node records, template records, map records, list records, etc.
A record is a contiguous sequence of bytes stored at a specific offset inside a segment. A record can have references to other records, where the referenced records can be stored in the same segment or not. Since records can reference each other, a segment actually stores a graph of records.
The segment header also maintains a set of references to root records: those records that are not referenced from any other records in the segment.
The overall structure of a data segment is:
[segment header] [record 1] [record 2] ... [record N]
The segment header and each record is zero-padded to make their size a multiple of four bytes and to align the next record at a four-byte boundary.
The segment header consists of the following fields. All integers are stored in big endian format.
+---------+---------+---------+---------+---------+---------+---------+---------+ | magic bytes: "0aK" | version | reserved +---------+---------+---------+---------+---------+---------+---------+---------+ reserved | generation | segrefcount +---------+---------+---------+---------+---------+---------+---------+---------+ segrefcount | reccount | reserved +---------+---------+---------+---------+---------+---------+---------+---------+ reserved | +---------+---------+---------+---------+---------+---------+---------+---------+ | Referenced segment identifiers (segrefcount x 16 bytes) | | | | ...... | | | +---------+---------+---------+---------+---------+---------+---------+---------+ | Record headers (reccount x 9 bytes) | | | | ...... +---------+---------+---------+ | | padding (set to 0) | +---------+---------+---------+---------+---------+---------+---------+---------+
The first three bytes of a segment always contain the ASCII string “0aK”, which is intended to make the binary segment data format easily detectable. The next byte indicates the version of the segment format and is currently set to 12.
The generation field indicates the segment’s generation wrt. to garbage collection. This field is used by the garbage collector to determine whether a segment needs to be retained or can be collected.
The segrefcount field indicates how many other segments are referenced by records within this segment. The identifiers of those segments are listed starting at offset 32 of the segment header. This lookup table is used to optimize garbage collection and to avoid having to repeat the 16-byte UUIDs whenever references to records in other segments are made.
The reccount field indicates the number of records in this segment. Record headers for each record follow after the segment identifier lookup table. Each header consists of a record number (4 bytes), a record type (1 byte) and a record offset (4 bytes) from the end of the segment.
Records need a mechanism to reference each other, both from inside the same segment and across different segments. The mechanism used to reference a record is (unsurprisingly) a record identifier.
A record identifier is composed of a segment field and a record number field. The segment field is two-bytes short integer that identifies the segment where the referenced record is stored. The record number field is the number of the record inside the segment identified by the segment field. There are some peculiarities in both the segment and the position field that may not be immediately obvious. The picture below shows how a segment looks like.
The segment field is two bytes long, but a segment identifier is 16 bytes long. To bridge the gap, the segment header contains an array of segment identifiers that is used as a look-up table. The array can store up to Integer.MAX_VALUE entries, but two bytes are enough to access every element in the array in practice. In fact, the segment field in a record identifier is just an index in the array of segment identifiers that is used as a look-up table. The segment field can have the special value of 0. If the segment field is 0, the referenced record is stored in the current segment.
The record number field is a logical identifier for the record. The logical identifier is used as a lookup key in the record references table in the segment identified by the segment field. Once the correct row in the record references table is found, the record offset can be used to locate the position of the record in the segment.
The offset is relative to the beginning of a theoretical segment which is defined to be 256 KiB. Since records are added from the bottom of a segment to the top (i.e. from higher to lower offsets), and since segments could be shrunk down to be smaller than 256 KiB, the offset has to be normalized with to the following formula.
SIZE - 256 KiB + OFFSET
SIZE is the actual size of the segment under inspection, and OFFSET is the offset looked up from the record references table. The normalized offset can be used to locate the position of the record in the current segment.
The content inside a segment is divided in records of different types: blocks, lists, maps, values, templates and nodes. These record types and their internal structures are described in subsections below.
A block record is the simplest form of record, because it is just a plain sequence of bytes up to 4kB. It doesn’t even contain a length: it is up to the writer of this record to store the length elsewhere. The only adjustment performed to the data is the alignment. The implementation makes sure that the written sequence of bytes is stored at a position that is a multiple of four.
Block records are used as building blocks of large binary and string values. They are the only record type that can’t contain references to other records. Block records are typically stored in bulk segments that consist only of block records and are thus easily identifiable as containing zero references to other segments.
Value records have more structure than block records and store data with an additional length and optional references to other records.
The implementation represents value records in different ways depending on the length of the data to be written. If the data is short enough, the record can be written in the simplest way possible: a length field and the data inlined directly in the record.
When the data is too big, instead, it is split into block records written into block segments. The reference to these block records are stored into a list record (see next section), whose identifier is stored inside the value record.
This means that value record represent a good compromise when writing binary or string data. If the data is short enough, it is written in such a way that can be used straight away without further reads in the segment. If the data is too long, instead, it is stored separated from the repository content not to impact the performance of the readers of the segment.
Value records are used for storing names and values of the content tree. Since item names can be thought of as name values and since all JCR and Oak values can be expressed in binary form (strings encoded in UTF-8), it is easiest to simply use that form for storing all values. The size overhead of such a form for small value types like booleans or dates is amortized by the facts that those types are used only for a minority of values in typical content trees and that repeating copies of a value can be stored just once.
There are four types of value records: small, medium, long and external. The small- and medium-sized values are stored in inline form, prepended by one or two bytes that indicate the length of the value. Long values of up to two exabytes (2^61) are stored as a list of block records. Finally an external value record contains the length of the value and a string reference (up to 4kB in length) to some external storage location.
The type of a value record is encoded in the high-order bits of the first byte of the record. These bit patterns are:
List records represent a general-purpose list of record identifiers. They are used as building blocks for other types of records, as we saw for value records and as we will see for template records and node records.
The list record is a logical record using two different types of physical records to represent itself:
bucket record: this is a recursive record representing a list of at most 255 references. A bucket record can reference other bucket records, hierarchically, or the record identifiers of the elements to be stored in the list. A bucket record doesn’t maintain any other information exception record identifiers.
list record: this is a top-level record that maintains the size of the list in an integer field and a record identifier pointing to a bucket.
+--------+--------+--------+-----+ | sub-list ID 1 | ... | +--------+--------+--------+-----+ | v +--------+--------+--------+-----+--------+--------+--------+ | record ID 1 | ... | record ID 255 | +--------+--------+--------+-----+--------+--------+--------+
The result is a hierarchically stored immutable list where each element can be accessed in O(log N) time and the size overhead of updating or appending list elements (and thus creating a new immutable list) is also O(log N).
List records are useful to store a list of references to other records. If the list is too big, it is split into different bucket records that may be stored in the same segment or across segments. This guarantees good performance for small lists, without loosing the capability to store lists with a big number of elements.
Map records implement a general-purpose unordered map of strings to record identifiers. They are used for nodes with a large number of properties or child nodes. As lists they are represented using two types of physical record:
leaf record: if the number of elements in the map is small, they are all stored in a leaf record. This covers the simplest case for small maps.
branch record: if the number of elements in the map is too big, the original map is split into smaller maps based on a hash function applied to the keys of the map. A branch record is recursive, because it can reference other branch records if the sub-maps are too big and need to be split again.
Maps are stored using the hash array mapped trie (HAMT) data structure. The hash code of each key is split into pieces of 5 bits each and the keys are sorted into 32 (2^5) buckets based on the first 5 bits. If a bucket contains less than 32 entries, then it is stored directly as a list of key-value pairs. Otherwise the keys are split into sub-buckets based on the next 5 bits of their hash codes. When all buckets are stored, the list of top-level bucket references gets stored along with the total number of entries in the map.
The result is a hierarchically stored immutable map where each element can be accessed in O(log N) time and the size overhead of updating or inserting list elements is also O(log N).
Map records are also optimized for small changes. In example, if only one element of a previously stored map is modified, and the map is stored again, only a “diff” of the map is stored. This prevents the full storage of the modified map, which can save a considerable amount of space if the original map was big.
A template record stores metadata about nodes that, on average, don’t change so often. A template record stores information like the primary type, the mixin types, the property names and the property types of a node. Having this information stored away from the node itself prevents to write them over and over again if they don’t change when the node changes.
In example, on average, a node is created with a certain primary type and, optionally, with some mixin types. Usually, because of its primary type, a node is already created with a set of initial properties. After that, only the value of the properties change, but not the structure of the node itself.
The template record allows Oak to handle simple modifications to nodes in the most efficient way possible.
As such a template record describes the common structure of a family of related nodes. Since the structures of most nodes in a typical content tree fall into a small set of common templates, it makes sense to store such templates separately instead of repeating that information separately for each node. For example, the property names and types as well as child node names of all nt:file nodes are typically the same. The presence of mixins and different subtypes increases the number of different templates, but they’re typically still far fewer than nodes in the repository.
A template record consists of a set of up to N (exact size TBD, N ~ 256) property name and type pairs. Additionally, since nodes that are empty or contain just a single child node are most common, a template record also contains information whether the node has zero, one or many child nodes. In case of a single child node, the template also contains the name of that node. For example, the template for typical mix:versionable nt:file nodes would be (using CND-like notation):
- jcr:primaryType (NAME) - jcr:mixinTypes (NAME) multiple - jcr:created (DATE) - jcr:uuid (STRING) - jcr:versionHistory (REFERENCE) - jcr:predecessors (REFERENCE) multiple - jcr:baseVersion (REFERENCE) + jcr:content
The names used in a template are stored as separate value records and included by reference. This way multiple templates that for example all contain the “jcr:primaryType” property name don’t need to repeatedly store it.
The node record is the single most important type of record, capable of storing both the data associated to the node and the structure of the content tree.
A node record always maintains a reference to a template record. As stated before, a template record defines the overall structure of the node, while the variable part of it is maintained in the node record itself.
The variable part of the node is represented by a list of property values and a map of child nodes.
The list of property values is implemented as a list of record identifiers. For each property in the node, its value is written in the segment. The record identifiers referencing the values of the properties are then packed together in a list record. The identifier of the list record is stored as part of the node record. If the value of some properties didn’t change, the previous record identifier is just reused.
The map of child nodes is implemented as a map of record identifiers. For every child node, its node record identifier is stored in a map indexed by name. The map is persisted in a map record, and its identifier is stored in the node record. Thanks to the optimizations implemented by the map record, small changes to the map of children node don’t create a lot of overhead in the segment.


If you don't read Javascript, please get someone who can to double check it.
`integrity` ensures that the JavaScript which is loaded into the browser hasn't been tampered with


{% extends 'default_layout.html' %} {% block content %}
| This is a sample application for the ArrowJs Framework. We expect to implement as many features as possible to show how the framework works and its potential. Please write us if you have any feedback or comments. Feel free to clone the code of this application here. The purpose of this application is merely academic. Thanks!. |


abstract class Program<TData, TOutput : Output<TData>> : Module
An LGP program that is composed of instructions that operate on registers.
TData
- Type of data the programs instructions operate on.
TOutput
- The type of the program output(s).
Program()
An LGP program that is composed of instructions that operate on registers. |
open var effectiveInstructions: MutableList<Instruction<TData>>
The instructions in this Program that are effective. |
|
var fitness: Double
Represents the fitness of this Program. |
|
abstract var instructions: MutableList<Instruction<TData>>
The instructions in this Program. |
|
abstract val outputRegisterIndices: List<RegisterIndex>
The indices of register(s) that the program uses as output. |
|
abstract val registers: RegisterSet<TData>
The set of registers that this Program runs against. |
abstract val information: ModuleInformation
Provides information about the module. |
abstract fun copy(): Program<TData, TOutput>
Creates a clone of the given program. |
|
abstract fun execute(): Unit
Executes the program. |
|
abstract fun findEffectiveProgram(): Unit
Provides a way to find an LGP programs effective set of instructions. |
|
abstract fun output(): TOutput
Retrieves the program output. |


{% load staticfiles %}
Archetype is built on prior intellectual property funded by the European Union Seventh Framework Programme (FP7) under Grant Agreement no. 263751 (DigiPal), and the Arts and Humanities Research Council (AHRC) under Grant Reference n° AH/L008041/1 (Models of Authority) and AH/L013975/1 (Exon Domesday). This site uses Cookies. For further details see our Privacy and cookie policy.
{% now 'Y' %} © Archetype
Designed, developed and maintained by King's Digital Lab