The Mars 2020 SPICE Data Archive
========================================================================
Last update: August 20, 2021
Introduction
============
This document describes the Mars 2020 SPICE archive, containing
observation geometry and other ancillary data in the form of SPICE
System kernel files for the Mars 2020 rover and its instruments and
structures. It describes the archive directory structure, kernels
included in the archive, their naming conventions, and provides
pointers to the SPICE software and documentation.
Table of Contents
=================
Introduction
Table of Contents
Overview
Errata
Archive Contents
Kernel Types
Archived Kernel Details
SPK Files
PCK Files
IK Files
CK Files
LSK Files
SCLK Files
FK Files
MK Files
Miscellaneous Files
Checksum Files
File Formats
SPICE Software and Documentation
Contact Information
Cognizant Persons
Overview
========
This archive includes the complete set of the Mars 2020 Perseverance
Rover Mission data files (kernel files), which can be accessed using
SPICE software. The SPICE data contain geometric and other ancillary
information needed to recover the full value of science instrument
data. In particular SPICE kernels provide spacecraft and planetary
ephemerides, spacecraft and instrument orientation, instrument
mounting alignments, and data needed for relevant time conversions.
Data in the SPICE kernel files must be accessed using the software
called the SPICE Toolkit produced and distributed by the Navigation
and Ancillary Information Facility (NAIF) Node of the Planetary Data
System.
This archive includes data covering from Mars 2020 launch, 2020-07-30,
through the end time of the latest rover surface traverse position SPK
file supplied in the archive. Until the end of the spacecraft lifespan
this archive will be accumulating with new data added according to the
project archiving plan.
Back to Table of Contents
Errata
======
1. This document is a simple HTML document. Providing documents in a
simple mark-up format was allowed by earlier versions of the PDS4
Standards but became prohibited in later versions starting summer
2015. Since using HTML documents was compliant at the time when a
similar document was first provided in the MAVEN PDS4 archive and
since NAIF strives to make bundle description document format and
style consistent across all archives, this document continues
to exist in this archive as an HTML document.
2. The XML labels of the ancillary products have the reference_type
attribute of the Internal_Reference association within the
Reference_List class of the Context_Area class pointing to the latest
archive description document set to "ancillary_to_data" which is not
correct. The correct value "ancillary_to_document" could not be used
in these labels because it is not available in the PDS4 information
model (IM) <IP_ADDRESS> used by this archive. This value was added to IM
only in the version <IP_ADDRESS>.
3. Only a partial structures IK with a few antenna FOVs is included.
IKs for other instruments may be added in a future release.
4. The Mars 2020 FK does not define frames for majority of instruments.
A more complete FK may be added in a future release.
5. RSM and RA orientation CKs have sparse coverage. CKs with more
complete coverage may be added in a future release.
6. No HGA CK is included. HGA CK for initial 90 Sols may be added in a
future release.
7. No Helicopter Technology Demonstration Ingenuity kernels are included.
SPK, CKs, IKs, and FK updates for the helicopter may be added in a
future release.
Back to Table of Contents
Archive Contents
================
Files in this archive are organized into a set of subdirectories
below the top-level directory. The following diagram shows the
structure and content of these directories. The directory names are
enclosed in square brackets ([]).
[top-level-directory]
|
|- bundle_mars2020_spice_v*.xml Bundle PDS4 label, one or more versions.
|- readme.txt Bundle top-level readme file.
|
|-[spice_kernels] Directory containing SPICE kernels.
| |
| |- collection_spice_kernels_v*.xml PDS4 labels for Spice Kernels collections.
| |- collection_spice_kernels_inventory_v*.tab
| | Spice Kernels collections' inventories.
| |
| |-[ck] Directory containing CK files.
| | |
| | |-- *.bc Binary CK files.
| | +-- *.xml PDS4 labels for CK files.
| |
| |-[fk] Directory containing FK files.
| | |
| | |-- *.tf Text FK files.
| | +-- *.xml PDS4 labels for FK files.
| |
| |-[ik] Directory containing IK files.
| | |
| | |-- *.ti Text IK files.
| | +-- *.xml PDS4 labels for IK files.
| |
| |-[lsk] Directory containing LSK files.
| | |
| | |-- *.tls Text LSK files.
| | +-- *.xml PDS4 labels for LSK files.
| |
| |--[mk] Directory containing MK files.
| | |
| | |-- *.tm Text Meta-kernel files.
| | +-- *.xml PDS4 labels for MK files.
| |
| |-[pck] Directory containing PCK files.
| | |
| | |-- *.tpc Text PCK files.
| | +-- *.xml PDS4 labels for PCK files.
| |
| |-[sclk] Directory containing SCLK files.
| | |
| | |-- *.tsc Text SCLK files.
| | +-- *.xml PDS4 labels for SCLK files.
| |
| +-[spk] Directory containing SPK files.
| |
| |-- *.bsp Binary SPK files.
| +-- *.xml PDS4 labels for SPK files.
|
|-+-[miscellaneous] Directory miscellaneous files.
| |
| |- collection_miscellaneous_v*.xml PDS4 labels for miscellaneous collections.
| |- collection_miscellaneous_inventory_v*.tab
| | Miscellaneous collections' inventories.
| |
| +-[checksum] Directory containing checksum files.
| |
| |-- *.tab Text checksum files.
| +-- *.xml PDS4 labels for checksum files.
|
+-[document] Directory containing documents.
|
|- collection_document_v*.xml PDS4 labels for document collections.
|- collection_document_inventory_v*.tab
| Document collections' inventories.
|
|- spiceds_v*.html This file and its earlier versions.
+- spiceds_v*.xml PDS4 labels for this file and its earlier versions.
Back to Table of Contents
Kernel Types
============
Different SPICE kernel types are used to store different kinds of
ancillary data.
SPK (Spacecraft Planet Kernel) files contain ephemerides (position
and velocity) for spacecraft, planets, satellites, comets and
asteroids as well as for moving or fixed spacecraft and instrument
structures. SPK files are located under the spice_kernels/spk
directory of this archive.
PCK (Planetary Constants Kernel) files contain certain physical,
dynamical and cartographic constants for target bodies, such as size
and shape specifications, and orientation of the spin axis and prime
meridian. PCK files are located under the spice_kernels/pck
directory of this archive.
IK (Instrument Kernel) files contain instrument parameters relevant
for computing an instrument's geometry such as field-of-view
definitions, CCD and optical distortion characteristics, and internal
timing parameters. IK files are located under the spice_kernels/ik
directory of this archive.
CK (C-matrix Kernel) files contain time varying orientations for
spacecraft, spacecraft structures, and articulating science
instruments. CK files are located under the spice_kernels/ck
directory of this archive.
LSK (Leapseconds Kernel) files contain the leapseconds and the
values of other constants required to perform a transformation
between Universal Time Coordinated (UTC) and Ephemeris time (ET),
which is also known as Barycentric Dynamical Time (TDB). LSK
files are located under the spice_kernels/lsk directory of
this archive.
SCLK (Spacecraft Clock Kernel) files contain on-board clock
calibration data required to perform a transformation between
Ephemeris time (ET) and spacecraft on-board time (SCLK). SCLK files
are located under the spice_kernels/sclk directory of this
archive.
FK (Frame definitions Kernel) files contain information required to
define reference frames, sources of frame orientation data and
connections between these frames and other frames supported within
the SPICE system. The science instrument frame definitions provided
in the FK files include mounting alignment information for the
instruments. FK files are located under the spice_kernels/fk
directory of this archive.
MK (Meta-Kernel) files list sets of related SPICE kernels that
should be used together, providing an easy way to make data from
these kernel sets available to a SPICE-based application by loading
meta-kernels into the program using the high level SPICE data loader
routine FURNSH. MK files are located the spice_kernels/mk
directory of this archive.
Archived Kernel Details
=======================
The subsections below provide details, such as file naming
conventions and specific details, for each of the kernel types
included in this archive.
Back to Table of Contents
SPK Files
SPK (Spacecraft Planet Kernel) files contain ephemerides (position
and velocity) for spacecraft, planets, satellites, comets and
asteroids as well as for moving or fixed spacecraft and instrument
structures.
This archive includes binary SPK files containing the following
kinds of ephemeris data:
- planetary ephemeris SPKs
These SPKs contain ephemeris data for the Solar System
planet barycenters, and Sun, Mercury, Venus, Earth, and
Moon, determined by the JPL Solar System Dynamics group and
are named DEXXX, e.g. DE430.
- Martian satellite ephemeris SPKs
These SPKs contain ephemeris data for Mars, Phobos, Deimos,
Sun, Earth barycenter, and Earth, determined by the
JPL Solar System Dynamics group and are named MARXXX, e.g.
MAR097.
- reconstructed spacecraft cruise trajectory SPKs
These SPKs contain the reconstructed Mars 2020 spacecraft
trajectory for cruise determined by the Mars 2020 Navigation
(NAV) team, JPL.
- reconstructed spacecraft EDL trajectory SPKs
These SPKs contain the reconstructed Mars 2020 spacecraft
trajectory during Entry Descent Landing (EDL) determined by
the Mars 2020 EDL Team, JPL.
- actual landing site position SPKs
These SPKs contain the actual location of the Mars 2020
landing site in the Mars body-fixed frame (IAU_MARS,
based on IAU 2000 Mars rotation constants), determined by
the Mars 2020 EDL Team, JPL.
- rover at landing site position SPKs
These SPKs contain the position of the Mars 2020 rover
fixed at the landing site. These files were used during
operations by CHRONOS and other applications that were not
sensitive to the local rover movements.
- structures SPKs
These SPKs contain fixed locations of of selected rover
structures and instruments such as Remote Sensing Mast (RSM),
Robotic Arm (RA), and cameras. The data included in the file
are based of dimensions from the spacecraft engineering drawings.
- localized rover path and site locations SPKs
These SPKs contain the locations of the sites along the path
relative to the center of Mars and the location of the rover
relative to the center of Mars, created by the NAIF, JPL.
These SPKs were created using localized data available in the
PLACES server developed and maintained by the Mars 2020 Operations
Product Generation Subsystem (OPGS) Team. The set of localized
data in the PLACES server included rover and site location data
for a limited set of localization points determined by tracing
the rover traverse on high resolution maps, combined a subset
of telemetry products to create a more complete set of location
points. Because the telemetry products used in this process
included only image headers and mobility summaries, containing
rover location during non-motion periods, and did not include
data from the high-rate mobility history products containing
rover location during motion periods, these SPKs do not provide
real data during motion but instead provide interpolated
values.
In global context the data provided in these SPKs is
significantly more accurate than telemetered rover position
estimated on-board. Because of this these SPKs should be
preferred to the telemetry-based rover path SPKs.
- telemetry-tased rover path and site locations SPKs
These SPKs contain the locations of the sites along the path
relative to the landing site and location of the rover relative
to these sites.
These SPKs were created using telemetry data available in the
PLACES server developed and maintained by the Mars 2020 Operations
Product Generation Subsystem (OPGS) Team. The set of telemetry
data in the PLACES server included rover and site location data
from only a subset of telemetry products containing such
information. Specifically, it included data from the product
and image headers and mobility summaries, containing rover
location during non-motion periods, and did not include data
from the high-rate mobility history products containing rover
location during motion periods. For this reason, these SPKs do
not provide real data during motion but instead provide
interpolated values.
Because data provided in these SPKs is based on telemetered
rover position estimated on-board, these SPKs are only as
accurate as that estimate, which, depending on the traverse
distances, slippage and sliding, can off by meters.
The SPK files are provided under the spice_kernels/spk
directory and are named according to the following schemes:
- planetary ephemeris SPKs
deVVVs.bsp
where
VVV is the ephemeris version.
s (optional) indicates that the original file
coverage was shortened to reduce the file
size.
- Martian satellite ephemeris SPKs
marVVVs.bsp
where
VVV is the ephemeris version.
s (optional) indicates that the original file
coverage was shortened to reduce the file
size.
- reconstructed spacecraft cruise trajectory SPKs
m2020_cruise_odSSS_vV.bsp
where
SSS is the orbit determination solution number.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- reconstructed spacecraft EDL trajectory SPKs
m2020_edl_vVV.bsp
where
VV is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- actual landing site position SPKs
m2020_ls_opsYYMMDD_iauYYYY_vV.bsp
where
YYMMDD is the date when the landing site location
stored in the file was determined or
released.
YYYY is the publication year of the IAU Mars
rotation model, with which this SPK should be
used.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- rover at landing site position SPKs
m2020_atls_opsYYMMDD_vV.bsp
where
YYMMDD is the date consistent with the corresponding
landing site position SPK.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- structures SPKs
m2020_struct_vVV.bsp
where
VV is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- localized rover path and site locations SPKs
m2020_surf_rover_loc_SSSS_ssss_vV.bsp
where
SSSS is the file coverage start SOL.
ssss is the file coverage end SOL.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- telemetry-tased rover path and site locations SPKs
m2020_surf_rover_tlm_SSSS_ssss_vV.bsp
where
SSSS is the file coverage start SOL.
ssss is the file coverage end SOL.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
The most detailed description of the data in each SPK file is
provided in metadata included inside the comment area of the file.
This information can be viewed using the utility program COMMNT
included in the NAIF Toolkit.
Back to Table of Contents
PCK Files
PCK (Planetary Constants Kernel) files contain certain physical,
dynamical, and cartographic constants for target bodies, such as
size and shape specifications, and orientation of the spin axis and
prime meridian.
This archive includes generic text PCK files produced by NAIF,
containing data from the reports of the IAU Working Group on
Cartographic Coordinates and Rotational Elements. The generic text
PCK version 00010 contains data from the 2009 report.
The PCK files are provided under the spice_kernels/pck
directory and are named according to the following scheme:
- generic text PCKs
pckVVVVV.tpc
where
VVVVV is the version; the file with the largest
number is the latest, but the user of PCK
data must decide if the latest version,
or an earlier version, is appropriate
for his/her analysis task.
The most detailed description of the data in a text PCK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
IK Files
IK (Instrument Kernel) files contain instrument parameters relevant
for computing an instrument's observation geometry such
field-of-view definitions, CCD and optical distortion
characteristics, and internal timing parameters.
This archive includes text IK files for Mars 2020 instruments, for
which common instrument geometric parameters normally stored in IKs
are applicable, such as the rover cameras, a few other rover-mounted
instruments and rover mounted antennas.
The IK files are provided under the spice_kernels/ik
directory and are named according to the following scheme:
- instruments and antennae IK files
m2020_NAME_vVV.ti
where
NAME is the instrument acronym:
struct (for miscellaneous structures,
e.g. antennae)
VV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
The most detailed description of the data in a text IK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
CK Files
CK (C-matrix Kernel) files contain time varying orientations for
spacecraft, articulating spacecraft structures, and articulating
science instruments.
This archive includes binary CK files containing the following kinds
of orientation data:
- reconstructed spacecraft cruise orientation CKs
These CKs contain the reconstructed Mars 2020 spacecraft
cruise attitude determined on-board and downlinked in
spacecraft telemetry, determined by the Mars 2020 Attitude
Control System (ACS) Team, JPL.
The set of CKs provided by the Mars 2020 ACS Team includes a CK
with complete cruise orientation based on H-vector direction
without modeling spin, a CK with fully reconstructed orientation
based on real-time quaternions covering only communication periods,
a CK with high-rate high-accuracy orientation covering only a few
very short periods during certain events sugh as: attitude
maneuvers, ACS calibration activities, or thruster firing events.
- reconstructed spacecraft EDL orientation CKs
These CKs contain the reconstructed Mars 2020 spacecraft EDL
attitude, from the EDL entry point to landing, determined
by Mars 2020 EDL team, JPL.
- reconstructed rover surface orientation CKs
These CKs contain the orientation of the rover relative to the
local level frame, created by NAIF, JPL.
These CKs were created using telemetry data available in the
PLACES server developed and maintained by the Mars 2020 OPGS Team.
The set of telemetry data in the PLACES server included rover
orientation data only from a subset of telemetry products
containing such information. Specifically, it included data
from the product and image headers and mobility summaries,
containing rover orientation during non-motion periods, and did
not include data from the high-rate mobility history products,
containing rover orientation during motion periods. For this
reason, these CKs do not provide real data during motion but
instead provide interpolated values.
Due to incomplete source data these CKs have gaps in coverage,
which can be closed, if needed, using the CKSPANIT utility
program.
- reconstructed articulating structures orientation CKs
These CKs contain the orientation of the Remote Sensing Mast
(RSM), Robotic Arm (RA), and High Gain Antenna (HGA) relative
to the rover frame, created by NAIF, JPL.
These CKs were created using telemetry data available in the
PLACES server developed and maintained by the Mars 2020 OPGS Team.
The set of telemetry data in the PLACES server included
structure articulation angle data from only a subset of
telemetry products containing such information. Specifically,
it included data from the product and image headers and
articulation summaries, containing structure articulation
angles during non-articulation periods, and did not include
data from the high-rate articulation history products,
containing structure articulation angles during articulation
periods. For this reason, these CKs do not provide real data
during articulation but instead provide interpolated values.
The sets of CKs for RSM and RA include CKs based on encoder
angles (less accurate but more complete) and CKs based on
resolver angles (more accurate but less complete).
While RSM and HGA CKs based on resolver angles provide accurate
orientation matching that computed in the flight software, the
RA CKs do not because the simple forward kinematics approach
implemented using these CKs and corresponding frame chains does
not model flexing of the RA which can lead to end point
orientation errors of a degree or more for some RA
configurations.
Due to incomplete source data these CKs have gaps in coverage,
which can be closed, if needed, using the CKSPANIT utility
program.
The CK files are provided under the spice_kernels/ck
directory and are named according to the following scheme:
- reconstructed spacecraft cruise orientation CKs
m2020_cruise_recon_TYPE_vV.bc
where
TYPE specifies the basis of the orientation
nospin (for H-vector direction without spin)
rawrt (for real-time quaternions during comms)
raweng (for high-rate quaternions during events)
VV is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- reconstructed spacecraft EDL orientation CKs
m2020_edl_rec_vVV.bc
where
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- reconstructed rover surface orientation CKs
m2020_surf_rover_tlm_SSSS_ssss_vV.bc
where
SSSS is the file coverage start SOL.
ssss is the file coverage end SOL.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
- reconstructed articulating structures orientation CKs
m2020_surf_STRUC_TYPE_SSSS_ssss_vV.bc
where
STRUC is the articulating structure
hga (for High Gain Antenna)
ra (for Robotic Arm)
rsm (for Remote Sensing Mast)
TYPE specifies the basis of the orientation
tlmenc (for encoder-based orientation)
tlmres (for resolver-based orientation)
SSSS is the file coverage start SOL.
ssss is the file coverage end SOL.
V is the version; the file with the latest
version supersedes all similarly named files
with earlier versions.
The most detailed description of the data in each CK file is
provided in metadata included inside the comment area of the file.
This information can be viewed using the utility program COMMNT
included in the NAIF Toolkit.
Back to Table of Contents
LSK Files
LSK (Leapseconds Kernel) files contain the leapseconds and the
values of other constants required to perform a transformation
between Universal Time Coordinated (UTC) and Ephemeris time (ET),
also known as Barycentric Dynamical Time (TDB).
This archive includes generic text LSK files produced by NAIF,
containing leapsecond information based on the IERS announcements.
The generic text LSK version 0012 contains leap second data up to
and including the January 1, 2017 leapsecond.
The LSK files are provided under the spice_kernels/lsk
directory and are named according to the following scheme:
- generic text LSKs
naifVVVV.tls
where
VVVV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
The most detailed description of the data in a text LSK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
SCLK Files
SCLK (Spacecraft Clock Kernel) files contain on-board clock
calibration data required to perform a mapping between Ephemeris
time (ET) and spacecraft on-board time (SCLK).
This archive includes text SCLK files containing the following kinds of
data:
- official Mars 2020 on-board clock correlation SCLKs
These SCLKs contain a tabulation of data needed for converting
time measurements between ephemeris time (ET) and Mars 2020
spacecraft clock time (SCLK). They are made from similar
files -- SCLK/SCET file, or SCLKvSCET file -- produced by
mission Time Correlation Subsystem (TCS) team.
The official on-board correlation SCLK files used in operations
and included in this data set provide correlation that is
incorrect in an absolute sense by as much as 3 seconds during
surface operations. The main reason for this error is the loose
time correlation requirement for surface operations intended
to keep backward compatibility between correlation versions
and minimize the impact of deployment of the new correlation
across the ground data system.
- improved Mars 2020 on-board clock correlation SCLKs
These improved SCLK files contain on-board clock correlation
accurate to a few tens of milliseconds or better, made
specifically for archiving to fix large correlation errors
present in the official SCLKs.
- Local Mean Solar Time (LMST) SCLKs
These SCLK files provide a way of converting between the Local
Mean Solar Time (LMST) time system used during surface
operations and other time systems. LMST was introduced as a
replacement of the Local True Solar Time (LTST) because a time
system with a constant duration of a second was needed for use
in the planning and sequencing processes. The LMST is
essentially a linear approximation of the local true solar time
with the rate set equal to the mean Mars local second duration
and the initial reference point set to LMST midnight of the
landing SOL. Due to ellipticity of the Mars orbit this
approximation is periodic and deviates from the LTST by as much
as 50 minutes during Martian year.
The SCLK files are provided under the spice_kernels/sclk
directory and are named according to the following scheme:
- official Mars 2020 on-board clock correlation SCLKs
m2020_168_sclkscet_VVVVV.tsc
where
VVVVV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
- improved Mars 2020 on-board clock correlation SCLKs
m2020_168_sclkscet_refit_vVV.tsc
where
VV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
- Local Mean Solar Time (LMST) SCLKs
m2020_lmst_opsYYMMDD_vV.tsc
where
YYMMDD is the date consistent with the corresponding
landing site position SPK.
V is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
The most detailed description of the data in a text SCLK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
FK Files
FK (Frame definitions Kernel) files contain information required to
define reference frames, sources of frame orientation data and
connections between these frames and other frames supported within
the SPICE system. The science instrument frame definitions provided
in the FK files include mounting alignment information for the
instruments.
This archive includes text FK files defining reference frames for
the Mars 2020 rover, its structures, and science instruments.
These FKs were produced by NAIF using the spacecraft and instrument
design documentation as well as actual instrument alignment values
determined pre-launch and as the result of in-flight calibrations.
The FK files are provided under the spice_kernels/fk
directory and are named according to the following scheme:
- Mars 2020 mission FK files
m2020_vVV.tf
where
VV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
The most detailed description of the data in a text FK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
MK Files
Meta-kernel (MK) files (a.k.a 'furnsh' files) provide lists of the
archived kernels included in this archive suitable for loading into
a SPICE-based application via the high level SPICE data loader
routine FURNSH. Using meta-kernels makes it easy to load with
one call a comprehensive SPICE data collection for a given period.
This archive includes the following kinds of MK files:
- whole mission MK files
These MKs with provide the complete sets of best available
kernels.
- CHRONOS MK files
These MKs provide only kernels needed for the SPICE CHRONOS
time-conversion program and include the CHRONOS configuration
parameters (spacecraft ID, planet ID, landing UTC, landing SOL
index, and Sun GM).
These MKs provide the same sets of kernels as they provided during
OPS except for the cruise and EDL SPKs.
The text MK files are provided under the spice_kernels/mk
directory and are named according to the following scheme:
- whole mission MK files
m2020_vVV.tm
when
VV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
- CHRONOS MK files
m2020_chronos_vVV.tm
when
VV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions.
Although the meta-kernels were created such that on a UNIX
workstation they can be loaded into a SPICE-based application
directly from the directory in which they reside -- because the
PATH_VALUES keyword is set to '..' and '/' is used as the path
delimiter -- it is recommended that users make local copies of these
files and update the PATH_VALUES keyword in each of them to point to
the actual location of the archive's 'spice_kernels' directory on
their system. Additional changes including replacing '/' and '\' in
all path specifications and converting UNIX line terminators to
terminators native to the user's system may be required to use these
meta-kernels on non-UNIX workstation.
The following guidelines were followed to pick and set priority --
determined by the order in which the kernel files are listed, with
the latest one taking precedence -- for the kernel files included in
these meta-kernels:
- the latest archived versions of LSK, PCK, on-board clock and
LMST SCLKs, IKs, FK, planetary ephemeris SPK, satellite
ephemeris SPK, cruise SPK, EDL SPK and CK, landing site SPK,
localized rover surface path SPK, and rover, RSM, RA, and HGA
CKs were included
- only the reconstructed cruise CK based on real-time telemetry
during communication periods was included.
Additional description of the kernels sets listed in a text MK file is
provided in metadata included inside the description area of the
file. This information can be viewed using any text editor program.
Back to Table of Contents
Miscellaneous Files
===================
Miscellaneous files provide value added elements that are outside the
scope of the PDS archive requirements. Miscellaneous files included in
this archive are currently limited to checksum files.
The subsection below provides details for these files.
Back to Table of Contents
Checksum Files
A checksum file provides a table of MD5 checksums for all files in the
archive as of a particular archive (bundle) version, including
checksums for all previous checksums files and their labels but
excluding the checksum for the checksum file itself and its label.
The checksum files are provided under the miscellaneous/checksum
directory and are named according to the following scheme:
- Mars 2020 checksum files
checksum_vVVV.tab
where
VVV is the version; the file with the latest
version supersedes all similarly named
files with earlier versions and can be
used to validate the archive in its
entirety.
Back to Table of Contents
File Formats
============
All text documents, checksum files, and other meta information files
such as descriptions, detached PDS4 labels, and inventory tables, are
stream format files, with a carriage return (ASCII 13) and a line feed
character (ASCII 10) at the end of the records. This allows the files
to be read by most operating systems.
The text kernel files in this archive -- LSKs, PCKs, SCLKs, IKs, FKs,
and MKs -- are UNIX text files, with a line feed character (ASCII 10)
at the end of the line, and binary kernel files -- SPKs and CKs -- are
IEEE LSB binary files. While data files in this archive can be used
'as is' with SPICE toolkits for the majority of supported environments,
converting the files to the binary or text format native to the user's
computer may be required for use of the data with FORTRAN toolkits on
incompatible environments. Refer to the documentation provided with the
SPICE Toolkit to find out whether conversion is needed in each specific
case.
NAIF provides a tool (BINGO) that can convert either binary or text
kernels from one format to another. This means that text files can
have their line terminator changed and binary files can be converted
to the native format of the platform of interest. BINGO is available
from the utilities page at the NAIF Node of the PDS:
https://naif.jpl.nasa.gov/naif/utilities.html
Back to Table of Contents
SPICE Software and Documentation
================================
The latest SPICE Toolkit for a variety of computer platforms,
additional utility programs, documentation, tutorials, and hands-on
lessons are available at the NAIF Node of the PDS:
https://naif.jpl.nasa.gov
specifically:
Toolkit: https://naif.jpl.nasa.gov/naif/toolkit.html
Utilities: https://naif.jpl.nasa.gov/naif/utilities.html
Tutorials: https://naif.jpl.nasa.gov/naif/tutorials.html
Lessons: https://naif.jpl.nasa.gov/naif/lessons.html
Back to Table of Contents
Contact Information
===============================
PDS Navigation and Ancillary Information Facility (NAIF),
MAIL STOP 301-121
Jet Propulsion Laboratory
California Institute of Technology
4800 Oak Grove Drive
Pasadena, CA, 91109-8099
818-354-8136
WWW Site: https://naif.jpl.nasa.gov
Back to Table of Contents
Cognizant Persons
=================
This archive was produced by Marc Costa Sitja, Boris Semenov,
and Matthew Barnes, Planetary Data System Navigation and Ancillary
Information Facility Node, Jet Propulsion Laboratory, Pasadena,
California.
End of Mars 2020 SPICE archive description.
Back to Table of Contents


‘Off The Market!’ Mixed Reactions After Keanu Reeves Reveals His New Love Interest
Canadian actor Keanu Reeves is known for keeping his love life private following the stillbirth of his daughter with actress Jennifer Syme and her subsequent death a few months later. Now, 20 years later, the actor has gone public about his new love interest, appearing at a fashion event with 46-year-old artist Alexandra Grant.
55-year-old actor Keanu Reeves provoked a wave of comments and reactions this weekend after going to the LACMA Art + Film Gala hand-in-hand with his old business colleague and artist Alexandra Grant. As the couple looked particularly affectionate and interested in each other, fans could not help but congratulate Keanu Reeves for finding his significant someone following decades of solitude after the death of his ex-girlfriend Jennifer Syme in 2001, which was preceded by the stillbirth of their daughter Ave.
Some Twitter users, however, were surprised by Reeves’ unusual choice of romantic partner, despite his high status among the world’s most prominent celebrities, hinting at Grant’s apparent nonconformity to Hollywood standards and her visible age.
But most concluded that it did not matter after all, as the couple, who have previously collaborated on two books together, appeared to be happy and enjoying each other’s company.
The two was previously spotted together at the Saint Laurent Men's Spring Summer show and the MOCA Benefit 2019 at the Geffen Contemporary this summer. Keanu Reeves has not been in any long relationships following the death of Jennifer Syme, with Grant and Reeves reportedly meeting in 2009.


Enter your email address and we will send you a link to reset your password.
Check your email for a link to reset your password. If it doesn’t appear within a few minutes, check your spam folder.
Enter a valid email
Submit
Return to sign in


b2Shape Class Reference
#include <b2Shape.h>
List of all members.
Detailed Description
A shape is used for collision detection. You can create a shape however you like. Shapes used for simulation in b2World are created automatically when a b2Fixture is created.
Member Enumeration Documentation
- Enumerator:
| e_unknown |
|
| e_circle |
|
| e_polygon |
|
| e_typeCount |
|
Constructor & Destructor Documentation
| b2Shape::b2Shape |
( |
|
) |
[inline] |
| virtual b2Shape::~b2Shape |
( |
|
) |
[inline, virtual] |
Member Function Documentation
| virtual void b2Shape::ComputeAABB |
( |
b2AABB * |
aabb, |
|
|
const b2Transform & |
xf | |
|
) |
| | const [pure virtual] |
Given a transform, compute the associated axis aligned bounding box for this shape.
- Parameters:
-
| aabb | returns the axis aligned box. |
| xf | the world transform of the shape. |
Implemented in b2CircleShape, and b2PolygonShape.
| virtual void b2Shape::ComputeMass |
( |
b2MassData * |
massData, |
|
|
float32 |
density | |
|
) |
| | const [pure virtual] |
Compute the mass properties of this shape using its dimensions and density. The inertia tensor is computed about the local origin.
- Parameters:
-
| massData | returns the mass data for this shape. |
| density | the density in kilograms per meter squared. |
Implemented in b2CircleShape, and b2PolygonShape.
Get the type of this shape. You can use this to down cast to the concrete shape.
- Returns:
- the shape type.
Cast a ray against this shape.
- Parameters:
-
| output | the ray-cast results. |
| input | the ray-cast input parameters. |
| transform | the transform to be applied to the shape. |
Implemented in b2CircleShape, and b2PolygonShape.
| virtual bool b2Shape::TestPoint |
( |
const b2Transform & |
xf, |
|
|
const b2Vec2 & |
p | |
|
) |
| | const [pure virtual] |
Test a point for containment in this shape. This only works for convex shapes.
- Parameters:
-
| xf | the shape world transform. |
| p | a point in world coordinates. |
Implemented in b2CircleShape, and b2PolygonShape.
Member Data Documentation
The documentation for this class was generated from the following file:


{% extends "_layouts/bare.html" %}
{% set title = "Hour of Code™ with Microsoft Touch Develop" %}
{% set description = "Hour of Code™ with Microsoft Touch Develop" %}
{% block headAdd %}
{% endblock %}
{% block body %}
The 'Hour of Code'™ is a nationwide initiative by Computer Science Education Week and Code.org to introduce millions of students to one hour of computer science and computer programming.


Getting started
Installation
Installing Hugo
Hugo itself is just a single binary without dependencies on expensive runtimes like Ruby, Python or PHP and without dependencies on any databases. You just need to download the latest version. For more information read the official installation guides.
Let’s make sure Hugo is set up as expected. You should see a similar version number in your terminal:
hugo version
# Hugo Static Site Generator v0.15 BuildDate: 2016-01-03T12:47:47+01:00
Installing Material
Next, assuming you have Hugo up and running the hugo-material-docs
theme can be installed with git
:
# create a new Hugo website
hugo new site my-awesome-docs
# move into the themes folder of your website
cd my-awesome-docs/themes/
# download the theme
git clone git@github.com:digitalcraftsman/hugo-material-docs.git
Setup
Next, take a look in the exampleSite
folder at themes/hugo-material-docs/
. This directory contains an example config file and the content that you are currently reading. It serves as an example setup for your documentation.
Copy at least the config.toml
in the root directory of your website. Overwrite the existing config file if necessary.
Hugo includes a development server, so you can view your changes as you go - very handy. Spin it up with the following command:
hugo server
Now you can go to localhost:1313 and the Material theme should be visible. You can now start writing your documentation, or read on and customize the theme through some options.
Configuration
Before you are able to deploy your documentation you should take a few minute to adjust some information in the config.toml
. Open the file in an editor:
baseurl = "https://example.com/"
languageCode = "en-us"
title = "Material Docs"
[params]
# General information
author = "Digitalcraftsman"
description = "A material design theme for documentations."
copyright = "Released under the MIT license"
Options
Github integration
If your project is hosted on GitHub, add the repository link to the
configuration. If the provider
equals GitHub, the Material theme will
add a download and star button, and display the number of stars:
[params]
# Repository
provider = "GitHub"
repo_url = "https://github.com/digitalcraftsman/hugo-material-docs"
Adding a version
In order to add the current version next to the project banner inside the
drawer, you can set the variable version
:
[params]
version = "1.0.0"
This will also change the link behind the download button to point to the archive with the respective version on GitHub, assuming a release tagged with this exact version identifier.
Adding a logo
If your project has a logo, you can add it to the drawer/navigation by defining
the variable logo
. Ideally, the image of your logo should have
rectangular shape with a minimum resolution of 128x128 and leave some room
towards the edges. The logo will also be used as a web application icon on iOS.
Either save your logo somewhere in the static/
folder and reference the file relative to this location or use an external URL:
[params]
logo = "images/logo.png"
Adding a custom favicon
Favicons are small small icons that are displayed in the tabs right next to the title of the current page. As with the logo above you need to save your favicon in static/
and link it relative to this folder or use an external URL:
[params]
favicon = "favicon.ico"
Google Analytics
You can enable Google Analytics by replacing UA-XXXXXXXX-X
with your own tracking code.
googleAnalytics = "UA-XXXXXXXX-X"
Small tweaks
This theme provides a simple way for making small adjustments, that is changing
some margins, centering text, etc. The custom_css
and custom_js
option allow you to add further CSS and JS files. They can either reside locally in the /static
folder or on an external server, e.g. a CDN. In both cases use either the relative path to /static
or the absolute URL to the external ressource.
[params]
# Custom assets
custom_css = [
"foo.css",
"bar.css"
]
custom_js = ["buzz.js"]
Changing the color palette
Material defines a default hue for every primary and accent color on Google’s
material design [color palette][]. This makes it very easy to change the overall look of the theme. Just set the variables palette.primary
and palette.accent
to one of the colors defined in the palette:
[params.palette]
primary = "red"
accent = "light-green"
Color names can be written upper- or lowercase but must match the names of the material design color palette. Valid values are: red, pink, purple, deep purple, indigo, blue, light-blue, cyan, teal, green, light-green, lime, yellow, amber, orange, deep-orange, brown, grey and blue-grey. The last three colors can only be used as a primary color.
If the color is set via this configuration, an additional CSS file called
palettes.css
is included that defines the color palettes.
Changing the font family
Material uses the Ubuntu font family by default, specifically the regular sans-serif type for text and the monospaced type for code. Both fonts are loaded from Google Fonts and can be easily changed to other fonts, like for example Google’s own Roboto font:
[params.font]
text = "Roboto"
code = "Roboto Mono"
The text font will be loaded in font-weights 400 and 700, the monospaced font in regular weight.
Syntax highlighting
This theme uses the popular Highlight.js library to colorize code examples. The default theme is called Github
with a few small tweaks. You can link our own theme if you like. Again, store your stylesheet in the static/
folder and set the relative path in the config file:
[params]
# Syntax highlighting theme
highlight_css = "path/to/theme.css"
Adding a GitHub and Twitter account
If you have a GitHub and/or Twitter account, you can add links to your
accounts to the drawer by setting the variables github
and
twitter
respectively:
[social]
twitter = ""
github = "digitalcraftsman"
Adding menu entries
Once you created your first content files you can link them manually in the sidebar on the left. A menu entry has the following schema:
[[menu.main]]
name = "Material"
url = "/"
weight = 0
pre = ""
name
is the title displayed in the menu and url
the relative URL to the content. The weight
attribute allows you to modify the order of the menu entries. A menu entry appears further down the more weight you add. The pre
attribute is optional and allows you to *pre*pend elements to a menu link, e.g. an icon.
Instead of just linking a single file you can enhance the sidebar by creating a nested menu. This way you can list all pages of a section instead of linking them one by one (without nesting).
You need extend the frontmatter of each file content file in a section slightly. The snippet below registers this content file as ‘child’ of a menu entry that already exists.
menu:
main:
parent: Material
identifier: <link name>
weight: 0
main
specifies to which menu the content file should be added. main
is the only menu in this theme by default. parent
let’s you register this content file to an existing menu entry, in this case the Material
link. Note that the parent in the frontmatter needs to match the name in config.toml
.
identifier
is the link that is shown in the menu. Ideally you choose the same name for the identifier
and the title
of the page. Again, weight
allows you to change the order of the nested links in a section.
Markdown extensions
Hugo uses Blackfriday to process your content. For a detailed description of all options take a look at the Blackfriday configuration section in the Hugo documentation.
[blackfriday]
smartypants = true
fractions = true
smartDashes = true
plainIDAnchors = true


"The more often we see the things around us - even the beautiful and wonderful things - the more they become invisible to us. That is why we often take for granted the beauty of this world: the flowers, the trees, the birds, the clouds - even those we love. Because we see things so often, we see them less and less."


FluidName:
Nitrogen
R134a
Input #1:
Select one...
Pressure [Pa]
Temperature [K]
Density [kg/m³]
Input #2:
Select one...
Pressure [Pa]
Temperature [K]
Density [kg/m³]
Calculate
Output:


| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
I would like to thank: Bill Sommerfeld, for his help with some of this documentation, and catching some of the bugs the first time around; Honeywell Information Systems, for not killing off the Multics operating system before I had an opportunity to use it; Honeywell’s customers, who persuaded them not to do so, for a while; Ted Anderson of CMU, for catching some problems before version 1.2 left the nest; Stan Zanarotti and several others of MIT’s Student Information Processing Board, for getting us started with “discuss,” for which this package was originally written; and everyone I’ve talked into — I mean, asked to read this document and the “man” pages.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This document was generated by buildd user on March 30, 2012 using texi2html 1.82.


Christopher Latham Sholes
The Inventor of the QWERTY Keyboard!
Christopher Latham Sholes checking on the typewriter
Christopher Latham Sholes (February 14, 1819 – February 17, 1890) was an American inventor who invented the QWERTY keyboard, and along with Samuel W. Soule, Carlos Glidden and John Pratt, has been contended as one of the inventors of the first typewriter in the United States. He was also a newspaper publisher and Wisconsin politician.
Some fun facts about the inventors of the QWERTY keyboard:- Sun Sign: Aquarius
- Died At Age: 71
- Born In: Mooresburg, Montour County, Pennsylvania, United States
- Famous As: Inventor Of The QWERTY Keyboard
- Family: Spouse/Ex-: Mary Jane McKinney
- Father: Orrin Sholes
- Mother: Catherine Sholes
- Place Of Death: Milwaukee, Wisconsin, U.S.A
- U.S. State: Pennsylvania


How do I... Use long-polling?
If your system uses long-polling, then your bots will have to long-poll too, to create an accurate test. You have two ways of doing this.
Blocking
The simplest way to long-poll is to repeatedly make HTTP requests (with an appropriately long timeout). You could do this in a recursive loop, or as a repeating action. For example:
# infinite loop long-poll action
def long_poll(context) do
_response = HTTPoison.get!(@long_poll_url, @headers, timeout: 300)
# recur
long_poll(context)
end
While this effectively represents long-polling, it presents a problem - the bot can't do anything else. The bot is either waiting for a response, or starting a new request. The bot will never get a chance to perform any other actions.
This probably isn't what you want, though it can be useful for performance metrics. For example, split up your bots to have half busy long-polling, and the other half making writes.
Non-blocking
For a more accurate representation, where bots can both long-poll and do their normal routine at the same time, you need to set up a concurrent asynchronous long-polling mechanic.
The way to do this in Elixir is to create another Erlang process, which is simple and light-weight. The idea is to kick off the recursive long-poll in a separate process. Each time it gets a response, it needs to update the bot, then poll again. Because the bot's process isn't tied up waiting for a response, it can do other things.
The part that I glossed over is how the long-polling process "updates" the bot. Each
bot is actually a GenServer
, so the long-polling process can call
it with
update messages. The bot will process the message in between actions, giving you a
chance to update the context.
In order to handle the incoming message, you need to extend your bot with a custom
BotArmy.Bot
. Depending on how you set it up, you can also include logic to switch
between different feeds, as well as conditionally stop a specific feed. Here's an
example:
# In MyActions.ex
@doc """
Action to kick off a long-polling process for the active feed.
Only call this action once to initialize the process.
Make sure to handle the update messages in a custom `BotArmy.Bot`.
"""
def start_long_polling(%{active_feed_id: feed_id}) when is_binary(feed_id) do
bot_pid = self()
long_poll_url = @url_base <> "/feeds/#{feed_id}"
headers = []
# This starts a new process, and does not block the bot. Since it is linked to the
# bot, if either process crashes, the other one will too. In this case, if the
# long-poll request errors, the bot will die.
spawn_link(fn ->
# wrap the long-polling steps in a function so it can recur
do_long_poll = fn ->
# Make the long-poll, blocking until it returns
%{body: body, status_code: 200} = HTTPoison.get!(long_poll_url, headers, timeout: 300)
# Send the response to the bot, blocking until the bot handles it and replies.
# The message is a tuple that we need to create a `handle_call` for in our custom
# bot. In this case, the bot's reply is a boolean for if we should poll again.
continue_polling? =
GenServer.call(bot_pid, {:long_poll_response, feed_id, Jason.parse!(body)})
if continue_polling? do
# recur
do_long_poll()
else
# exiting with `:normal` will quit the polling process without quitting the bot
exit(:normal)
end
end
# kick off the initial long-poll
do_long_poll()
end)
end
# In MyBot.ex
# Be sure to specify this custom bot when running your test
defmodule MyBot do
@moduledoc """
Extended `BotArmy.Bot` to handle long-polling updates.
See https://hexdocs.pm/bot_army/1.0.0/BotArmy.Bot.html#module-extending-the-bot
"""
# You need this line to get all of the base `Bot` functionality
use BotArmy.Bot
@doc """
This matches the message sent from a long-polling process. It receives the
response from the poll and replies with a boolean whether the long-polling should
continue or not, based on if the active feed changed since the long-poll started.
"""
@impl GenServer
def handle_call({:long_poll_response, feed_id, response}, _from, context) do
# Note that `context` is the same state of the bot used in the actions.
# Make sure the response is for a feed that we still care about
if feed_id == context.active_feed_id do
# update the context however you need to based on the long-poll response
new_context = Map.put(context, :feed_data, response)
{:reply, true, new_context}
else
# The active feed changed, so we ignore the obsolete response and reply not to
# continue polling.
{:reply, false, context}
end
end
end


{% extends 'web/base.html' %}
{% load staticfiles %}
{% block title %}Compare Performance{% endblock %}
{% block compare_active %}active{% endblock %}
{% block js_scripts %}
{# #}
{% endblock %}
{% block body %}
The comparison of transfer speed between JSON and XML
Client resolving speed of JSON and XML
Streets in USA


Close your eyes and imagine paradise. A place in the middle of the Atlantic Forest and bathed by the sea, where you find peace, tranquility, comfort and convenience.
Set in a completely wooded area, Hotel Cocaray the only foot on the sand hotel. Here the sea will be your companion and you will have the beauties of nature as a guide.
Located in southern Bahishy, between the sea and the Atlantic Forest, Cocaray has refreshing waterfalls, beautiful beaches, many of them so small that they don't even appear on maps.
Do you know that laid-back date with family and friends? Or a moment relax? Our structure has a diversity of spaces that provide unforgettable moments.
Hotel Cocaray has 29 units, divided between 11 chalets, 16 large suites and 2 family chalets, all with cable TV, minibar, and balcony with hammock.


Core Topics
Advanced Topics
Misc
Getting Started
What is Mithril?
Mithril is a client-side Javascript MVC framework, i.e. it's a tool to make application code divided into a data layer (called Model), a UI layer (called View), and a glue layer (called Controller)
Mithril is around 5kb gzipped thanks to its small, focused, API. It provides a templating engine with a virtual DOM diff implementation for performant rendering, utilities for high-level modelling via functional composition, as well as support for routing and componentization.
The goal of the framework is to make application code discoverable, readable and maintainable, and hopefully help you become an even better developer.
Unlike some frameworks, Mithril tries very hard to avoid locking you into a web of dependencies: you can use as little of the framework as you need.
However, using its entire toolset idiomatically can bring lots of benefits: learning to use functional programming in real world scenarios and solidifying good coding practices for OOP and MVC are just some of them.
A Simple Application
Once you have a copy of Mithril, getting started is surprisingly boilerplate-free:
<!doctype html>

Yes, this is valid HTML 5! According to the specs, the
,
and
tags can be omitted, but their respective DOM elements will still be there implicitly when a browser renders that markup.
Model
In Mithril, an application typically lives in a namespace and contains modules. Modules are merely structures that represent a viewable "page" or component.
For simplicity, our application will have only one module, and we're going to use it as the namespace for our application:

This object will namespace our two Model classes:
var todo = {};
//for simplicity, we use this module to namespace the model classes
//the Todo class has two properties
todo.Todo = function(data) {
this.description = m.prop(data.description);
this.done = m.prop(false);
};
//the TodoList class is a list of Todo's
todo.TodoList = Array;
m.prop
is simply a factory for a getter-setter function. Getter-setters work like this:
//define a getter-setter with initial value `John`
var name = m.prop("John");
//read the value
var a = name(); //a == "John"
//set the value to `Mary`
name("Mary"); //Mary
//read the value
var b = name(); //b == "Mary"
Note that the Todo
and TodoList
classes we defined above are plain vanilla Javascript constructors. They can be initialized and used like this:
var myTask = new todo.Todo({description: "Write code"});
//read the description
myTask.description(); //Write code
//is it done?
var isDone = myTask.done(); //isDone == false
//mark as done
myTask.done(true); //true
//now it's done
isDone = myTask.done(); //isDone == true
The TodoList
class is simply an alias of the native Array
class.
var list = new todo.TodoList();
list.length; //0
Controller
Our next step is to write a controller that will use our model classes.
//the controller uses three model-level entities, of which one is a custom defined class:
//`Todo` is the central class in this application
//`list` is merely a generic array, with standard array methods
//`description` is a temporary storage box that holds a string
//
//the `add` method simply adds a new todo to the list
todo.controller = function() {
this.list = new todo.TodoList();
this.description = m.prop("");
this.add = function(description) {
if (description()) {
this.list.push(new todo.Todo({description: description()}));
this.description("");
}
};
}
The code above defines a controller class. It has three members: list
, which is simply an array, description
, which is an m.prop
getter-setter function with an empty string as the initial value, and add
, which is a method that adds a new Todo instance to list
if an input description getter-setter is not an empty string. Later in this guide, we'll pass the description
property as the parameter to this function. I'll explain why we're passing it as an argument when we get there.
You can use the controller like this:
var ctrl = new todo.controller();
ctrl.description(); //[empty string]
//try adding a to-do
ctrl.add(ctrl.description);
ctrl.list.length; //0
//you can't add a to-do with an empty description
//add it properly
ctrl.description("Write code");
ctrl.add(ctrl.description);
ctrl.list.length; //1
View
The next step is to write a view so users can interact with the application
todo.view = function(ctrl) {
return m("html", [
m("body", [
m("input"),
m("button", "Add"),
m("table", [
m("tr", [
m("td", [
m("input[type=checkbox]")
]),
m("td", "task description"),
])
])
])
]);
};
The utility method m()
creates virtual DOM elements. As you can see, you can use CSS selectors to specify attributes. You can also use the .
syntax to add CSS classes and the #
to add an id.
The view can be rendered using the m.render
method:
//assuming the `ctrl` variable from earlier
m.render(document, todo.view(ctrl));
Notice that we pass a root DOM element to attach our template to, as well as the template itself.
This renders the following markup:

<input />
<button>Add</button>

<input type="checkbox" />
task description

Data Bindings
Let's implement a data binding on the text input. Data bindings connect a DOM element to a Javascript variable so that updating one updates the other.
m("input")
//becomes
m("input", {value: ctrl.description()})
This binds the description
getter-setter to the text input. Updating the value of the description updates the input when Mithril redraws.
var ctrl = new todo.controller();
ctrl.description(); // empty string
m.render(document, todo.view(ctrl)); // input is empty
ctrl.description("Write code"); //set the description in the controller
m.render(document, todo.view(ctrl)); // input now says "Write code"
Note that calling the todo.view
method multiple times does not re-render the entire template.
Internally, Mithril keeps a virtual representation of the DOM in cache, scans for changes, and then only modifies the minimum required to apply the change.
In this case, Mithril only touches the value
attribute of the input.
Bindings can also be bi-directional: that is, they can be made such that, in addition to what we saw just now, a user typing on the input updates the description getter-setter.
Here's the idiomatic way of implementing the view-to-controller part of the binding:
m("input", {onchange: m.withAttr("value", ctrl.description), value: ctrl.description()})
The code bound to the onchange
can be read like this: "with the attribute value, set ctrl.description".
Note that Mithril does not prescribe how the binding updates: you can bind it to onchange
, onkeypress
, oninput
, onblur
or any other event that you prefer.
You can also specify what attribute to bind. This means that just as you are able to bind the value
attribute in an <select>
, you are also able to bind the selectedIndex
property, if needed for whatever reason.
The m.withAttr
utility is a functional programming tool provided by Mithril to minimize the need for ugly anonymous functions in the view.
The m.withAttr("value", ctrl.description)
call above returns a function that is the rough equivalent of this code:
onchange: function(e) {
ctrl.description(e.target["value"]);
}
The difference, aside from the cosmetic avoidance of anonymous functions, is that the m.withAttr
idiom also takes care of catching the correct event target and selecting the appropriate source of the data - i.e. whether it should come from a Javascript property or from DOMElement::getAttribute()
In addition to bi-directional data binding, we can also bind parameterized functions to events:
m("button", {onclick: ctrl.add.bind(ctrl, ctrl.description)}, "Add")
In the code above, we are simply using the native Javascript Function::bind
method. This creates a new function with the parameter already set. In functional programming, this is called partial application.
The ctrl.add.bind(ctrl, ctrl.description)
expression above returns a function that is equivalent to this code:
onclick: function(e) {
ctrl.add(ctrl.description)
}
Note that when we construct the parameterized binding, we are passing the description
getter-setter by reference, and not its value. We only evaluate the getter-setter to get its value in the controller method. This is a form of lazy evaluation: it allows us to say "use this value later, when the event handler gets called".
Hopefully by now, you're starting to see why Mithril encourages the usage of m.prop
: Because Mithril getter-setters are functions, they naturally compose well with functional programming tools, and allow for some very powerful idioms. In this case, we're using them in a way that resembles C pointers.
Mithril uses them in other interesting ways elsewhere.
As a side note, some readers have pointed out that we can refactor the add
method like this:
this.add = function() {
if (this.description()) {
this.list.push(new todo.Todo({description: this.description()}));
this.description("");
}
}.bind(this);
The difference is that add
no longer takes an argument, and we call .bind(this)
at the end to lock the scoping of this
inside of the add
method
Then we can make the onclick
binding on the template much simpler:
m("button", {onclick: ctrl.add}, "Add")
The only reason I talked about partial application here was to make you aware of that technique, since it becomes useful when dealing with parameterized event handlers. In real life, given a choice, you should always pick the simplest idiom for your use case, as we just did here.
To implement flow control in Mithril views, we simply use Javascript:
//here's the view
m("table", [
ctrl.list.map(function(task, index) {
return m("tr", [
m("td", [
m("input[type=checkbox]")
]),
m("td", task.description()),
])
})
])
In the code above, ctrl.list
is an Array, and map
is one of its native functional methods. It allows us to iterate over the list and merge transformed versions of the list items into an output array.
As you can see, we return a partial template with two
's. The second one has a data binding to the description
getter-setter of the Todo class instance.
You're probably starting to notice that Javascript has strong support for functional programming and that it allows us to naturally do things that can be clunky in other frameworks (e.g. looping inside a
/
/

construct).
The rest of the code can be implemented using idioms we already covered. The complete view looks like this:
todo.view = function(ctrl) {
return m("html", [
m("body", [
m("input", {onchange: m.withAttr("value", ctrl.description), value: ctrl.description()}),
m("button", {onclick: ctrl.add}, "Add"),
m("table", [
ctrl.list.map(function(task, index) {
return m("tr", [
m("td", [
m("input[type=checkbox]", {onclick: m.withAttr("checked", task.done), checked: task.done()})
]),
m("td", {style: {textDecoration: task.done() ? "line-through" : "none"}}, task.description()),
])
})
])
])
]);
};
Here are the highlights of the template above:
- The template is rendered as a child of the implicit

element of the document. - The text input saves its value to the
ctrl.description
getter-setter we defined earlier. - The button calls the
ctrl.add
method when clicked. - The table lists all the existing to-dos, if any.
- The checkboxes save their value to the
task.done
getter setter. - The description gets crossed out via CSS if the task is marked as done.
- When updates happen, the template is not wholly re-rendered - only the changes are applied.
When running the classes in this application separately, you have full control and full responsibility for determining when to redraw the view.
However, Mithril does provide another utility to make this task automatic: the Auto-Redrawing System.
In order to enable Mithril's auto-redrawing system, we run the code as a Mithril module:
m.module(document, todo);
Mithril's auto-redrawing system keeps track of controller stability, and only redraws the view once it detects that the controller has finished running all of its code, including asynchronous AJAX payloads.
Also note that this mechanism itself is not asynchronous if it doesn't need to be: Mithril does not need to wait for the next browser repaint frame to redraw - it doesn't even need to wait for the document ready event on the first redraw - it will redraw immediately upon script completion, if able to.
Summary
Here's the application code in its entirety:
<!doctype html>

Notes on Architecture
Let's look at each MVC layer in detail to illustrate some of Mithril's design principles and philosophies:
Model
Idiomatic Mithril code is meant to apply good programming conventions and be easy to refactor.
In the application above, notice how the Todo class can easily be moved to a different module if code re-organization is required.
Todos are self-contained and their data aren't tied to the DOM like in typical jQuery based code. The Todo class API is reusable and unit-test friendly, and in addition, it's a plain-vanilla Javascript class, and so has almost no framework-specific learning curve.
m.prop
is a simple but surprisingly versatile tool: it's composable, it enables uniform data access and allows a higher degree of decoupling when major refactoring is required.
When refactoring is unavoidable, the developer can simply replace the m.prop
call with an appropriate getter-setter implementation, instead of having to grep for API usage across the entire application.
For example, if todo descriptions needed to always be uppercased, one could simply change the description
getter-setter:
this.description = m.prop(data.description)
becomes:
//private store
var description;
//public getter-setter
this.description = function(value) {
if (arguments.length > 0) description = value.toUpperCase();
return description;
}
//make it serializable
this.description.toJSON = function() {return description}
//set the value
this.description(data.description)
According to Mithril's philosophy, list
and description
are also considered model-level entities. This is a subtle but important point: model entities don't need to be full-blown custom classes.
Native Javascript classes are quite appropriate for storing primitive and structured data. Since in this case they are indeed being used to store data - even if temporarily - they are model entities!
Be aware that by using the native Array class for a list, we're making an implicit statement that we are going to support all of the standard Array methods as part of our API.
While this decision allows better API discoverability, the trade-off is that we're largely giving up on custom constraints and behavior. For example, if we wanted to change the application to make the list be persisted, a native Array would most certainly not be a suitable class to use.
In order to deal with that type of refactoring, one can explicitly decide to support only a subset of the Array API, and implement another class with the same interface as this subset API.
Given the code above, the replacement class would only need to implement the .push()
and .map()
methods. By freezing APIs and swapping implementations, the developer can completely avoid touching other layers in the application while refactoring.
todo.TodoList = Array;
becomes:
todo.TodoList = function () {
this.push = function() { /*...*/ },
this.map = function() { /*...*/ }
};
Hopefully these examples give you an idea of ways requirements can change over time and how Mithril's philosophy allows developers to use standard OOP techniques to refactor their codebases, rather than needing to modify large portions of the application.
Controller
Mithril follows a data binding paradigm that is familiar to developers that use server-side MVC frameworks like Rails and Django.
The difference, as mentioned earlier, is that Mithril philosophy considers any form of data storage as being a model entity - even data from a text input waiting to be saved!
In Mithril, controllers are not meant to progressively operate on model entities. Instead, model entities should expose methods that atomically act on themselves.
What this rule means is that controllers can have conditional logic, as is the case in the add
method in the application above, but each action that touches a model entity should not leave it in an unstable state.
This is in contrast to the ActiveRecord pattern of other frameworks, which allows entities to be in potentially invalid states (for example, a to-do with no description), so long as they are not "saved".
The idea of disallowing unstable states hinges largely on the developer deciding what constitutes validity:
An empty description in the context of the text input in the UI is a perfectly valid state, and a string is an appropriate type to express that.
A to-do with no description is not valid, therefore we avoid writing code that ever leaves the Todo class instance in a unstable state.
Mithril doesn't programmatically define the scope of each model entity or in what states an entity is considered valid - validity is something the developer is responsible for defining.
Mithril's philosophical framework simply encourages that the developer map validity to static types. This is a key step in ensuring programs are robust and refactorable.
View
The first and most obvious thing you may have noticed in the view layer is that the view is not written in HTML.
While superficially this may seem like an odd design, this actually has a lot of benefits:
No flash-of-unbehaviored-content (FOUC). In fact, Mithril is able to render a fully functional application - with working event handlers - before the "DOM ready" event fires!
There's no need for a parse-and-compile pre-processing step to turn strings containing HTML + templating syntax into working DOM elements.
Mithril views can provide accurate and informative error reporting, with line numbers and meaningful stack traces.
You get the ability to automate linting, unit testing and minifying of the entire view layer - and you are even able to use Closure Compiler's Advanced Mode without needing extensive annotations.
It provides full Turing completeness: full control over evaluation eagerness/laziness and caching in templates. You can even build components that take other components as first-class-citizen parameters!
Turtles all the way down: you don't need write custom data binding code in jQuery for every possible user interaction, and you don't need to support a complicated "directive" layer to be able to fit some types of components into the system.
Views in Mithril use a virtual DOM diff implementation, which sidesteps performance problems related to opaque dirty-checking and excessive browser repaint that are present in some frameworks.
Another feature - the optional m()
utility - allows writing terse templates in a declarative style using CSS shorthands, similar to popular HTML preprocessors from server-side MVC frameworks.
And because Mithril views are Javascript, the developer has full freedom to abstract common patterns - from bidirectional binding helpers to full blown components - using standard Javascript refactoring techniques.
Mithril templates are also more collision-proof than other component systems since there's no way to pollute the HTML tag namespace by defining ad-hoc tag names.
A more intellectually interesting aspect of the framework is that event handling is encouraged to be done via functional composition (i.e. by using tools like m.withAttr
, m.prop
and the native .bind()
method for partial application).
If you've been interested in learning or using Functional Programming in the real world, Mithril provides very pragmatic opportunities to get into it.
Learn More
Mithril provides a few more facilities that are not demonstrated in this page. The following topics are good places to start a deeper dive.


The Kabuki Warriors debut new theme at a WWE live show
by Shubham RoyThe WWE Women's Tag Team Champions, The Kabuki Warriors debuted a new entrance theme at a WWE live show in Grand Rapids, Michigan. One-half of the tag team champions, Kairi Sane retweeted a fan's post on Twitter which shows video footage of the team walking out to their new entrance.
Asuka and Kairi Sane as a team
WWE Superstars Asuka and Kairi Sane were introduced as a tag team by Paige on the April 16, 2019 episode of WWE SmackDown. After feuding with then-WWE Tag Team Champions The IIconics - Billie Kay and Peyton Royce, the team went on a hiatus.
They returned in September and scored a victory over Fire & Desire - Mandy Rose and Sonya Deville. That win earned them an opportunity at winning the Women's Tag Team Championships from the team of Alexa Bliss and Nikki Cross. They defeated Bliss and Cross at this year's Hell in a Cell after Asuka used the green mist on Cross.
The next night on RAW, they turned heel after they cut a scathing promo on RAW Women's Champion Becky Lynch and Charlotte Flair in their native Japanese. They then defeated Lynch and Flair in a non-title match on the same night and Asuka used the green mist on Lynch.
The Kabuki Warriors were drafted to RAW as a part of the 2019 WWE Draft and on the October 28 episode of RAW, they turned on Paige after Asuka spew the green mist on her.
What are your thoughts on the new theme of The Kabuki Warriors? Leave your opinions by commenting below.
Want us to know your thoughts on the matches that you see on TV? Go to our WWE section to rate and comment about them!


Many people take out bank loans to make major purchases, like homes or cars. A mortgage is a bank loan which uses a home or piece of property as a security. Many people use a mortgage to borrow money to buy a home. If they fail to repay the loan, the bank gets to take the security - in this case, their home. When the bank takes the security from the loan, it is called a foreclosure (usually used with homes and property) or a reposession (usually used with vehicles like cars or boats). The result is the same - the bank takes the property which was used to secure the loan. They are then able to sell that property to earn back the money that they loaned out. Interest rates for these types of loans tend to be much lower, because the opportunity to foreclose on the property gives the bank a way to earn their money back even if the borrower does not repay the loan.
in-context


Lesson 4 - Let's Get Moving!
Introduction
Now that we have covered creating and coloring polygons, let's add some animation. Most of the source code is identical boilerplate to the second and third lessons so this lesson is also quite short.
Again, we instantiate a scene and call initializeScene()where all the work gets done. Similarly, the creation of the triangle and the square is identical to the third lesson.
The key difference in this lesson is that we don't call renderScene() directly. Instead, we call animateScene() which invokes a special behaviour in the browser that repeatedly calls a callback function, which in turn calls renderScene().
In the function, we first increase the y rotation of the triangle mesh and decrease the x rotation of the square mesh.
triangleMesh.rotation.y += 0.1;
squareMesh.rotation.x -= 0.075;
The Animation
Then we call a browser function, requestAnimationFrame. That method tells the browser that you wish to perform an animation and requests that the browser call a specified function to update an animation before the next repaint. The method takes as an argument a callback to be invoked before the repaint. In our case, the callback function we pass in is animateScene. Note that if the container (i.e. the browser window) is not visible, the animation is paused.
requestAnimationFrame(animateScene);
Note also that our callback function effectively calls requestAnimationFrame() every time it is invoked - which is required - it's not a fire and forget sort of call.
Finally, we actually call renderScene() which then maps the 3D scene down to the 2D screen, just like the previous lessons
renderScene();
And that's it! Click on this link to see the actual rendered demo in all it's rainbow glory!


Base classes and general utility classes. These include the abstract base classes for the several varieties of type-specific collection classes.
{@link com.sosnoski.util.GrowableBase} provides the basic implementation of a collection which uses a growable array, with call out methods (abstract methods used by the base class but defined by the subclass) for handling the particular needs of each such type of collection. The array, queue, and stack collection classes are all derived from this class.
{@link com.sosnoski.util.PrimitiveHashBase} and {@link com.sosnoski.util.ObjectHashBase} provide the basic implementation of hash-based collection. These also use call out methods for handling the particular needs of each such type of collection. The hash map and hash set collection classes are derived from this pair of classes.
{@link com.sosnoski.util.ArrayRangeIterator}, {@link com.sosnoski.util.WrappedArrayIterator} and
{@link com.sosnoski.util.SparseArrayIterator} provide java.util.Iterator
implementations
for array-based collections. They're used by the collections classes to return iterators for
object collections, but can also be used directly by applications.
{@link com.sosnoski.util.CharBuffer} supports working with character
sequences (including arrays and String
s) as a lightweight
StringBuffer
workalike. It extends the {@link com.sosnoski.util.array.CharArray}
growable character array implementation with added support for append/insert/replace
operations on the character sequence, along with comparing various types of
character sequences and computing format-independent hash codes for character
sequences.


Lanark Amateur Swimming Club take Junior Age Group Championships medals
The club did well at the event at Tollcross International Swimming Centre in Glasgow.
by Andy McGilvray, https://www.dailyrecord.co.uk/authors/andy-mcgilvray/Lanark Amateur Swimming Club provided two medallists at the West District Junior Age Group Championships at Tollcross International Swimming Centre in Glasgow.
Millie McArthur, 13, was second in 100m backstroke, third in the 100m butterfly, and fourth in both the 100m and 800m freestyle.
She was also fifth in the 400m individual medley.
Justin Bone, 12, was third in the 1500m.
New personal best times were set by Abbie Barnstaple, Katie Towers, Ross Carswell and Ayla Miller.
Coach Karen Kelly said: “Well done to both Millie and Justin, but Ayla and Ross also deserve a special mention.
“We are in the middle of a heavy competition programme, which runs to mid-November.”


Detects a Variable Pattern that shadows a stable identifier defined in the enclosing scope. To perform an equality test against that value, use backticks.
Before:
val foo = 0 0 match { case foo => }
After:
val foo = 0 0 match { case `foo` => }


presents
Peter Hutton
Images of Asian Music (A Diary from Life 1973-74)
16mm, 29 minutes, 1974
"IMAGES OF ASIAN MUSIC represents footage compiled during 1973-74 when Peter Hutton was living in Thailand and working at sea as a merchant seaman. While the film is silent, the title was intended to evoke a comparison to the movement of classical Asian music. IMAGES OF ASIAN MUSIC is a personal celebration of Asia formed by a sensitivity to filmic composition and to the perception of these images in a silent time created by the filmmaker." --Whitney Museum of American Art
"...The camera records a ship working out of Thailand, the faces of the seamen, the sea, a storm, fireworks, a big snake coiling exploratorily about a young girl, the huge Buddha in the lotus position and landscapes and skyscapes reminiscent of the film work of Satyajit Ray. It is beautiful, mute, and meaningful in the silence." --Archer Winston, New York Post
Lodz Symphony
16mm, 20 minutes, 1991-3
A portrait of Lodz, Poland that exists in a timewarp of sad memory. Hutton creates an empty world evoking the 19th century industrial atmosphere that is populated with the ghosts of Poland's tragic past.
Leighton Pierce
Glass
16mm, 7 minutes, 1998
A not-so-still-life in the back yard with children, water, fire, and a few other basic elements. This is another contemplative painterly piece in Leighton Pierce's on going "Memories of Water" series. While the ultimate effect is intended to be poetic (and maybe even transformative), it is simultaneously a study in the laws of optics--an exploration of refraction, diffraction, diffusion, reflection, and absorption. --Leighton Pierce
A window pane is a paradox of sorts, as it unifies two opposing functions. On the one hand it separates the 'inside' from the 'outside while the two spaces still remain visually connected. Glass, like water, can also flow, and both substances also share the qualities of transparency, refraction, and reflection. It is in this last quality that 'inside' and 'outside' can merge into one image. The accompanying crystal clear soundtrack, which ranges from a groaning swing to a crackling fire, very effectively contrasts the diffuse qualities of "Glass." --Arjon Dunnewind IMPAKT Festival Catalog 1998 (Utrecht, The Netherlands).
Awards: Best Cinematography--Ann Arbor and tour, Juror's Choice (top award)--Black Maria, Cash Award-- Athens
Selected Festival Screenings: New York Film Festival, European Media Arts Fest and tour (Germany), Impakt and tour (Netherlands), Ann Arbor (tour), Athens, Black Maria, etc.
Red Shovel
16mm, 8 minutes, 1992
A narrow angle of view, closely watched, on the Fourth of July.
Red Shovel is an impressionistic documentary focussing on a few moments in a small town along the coast of Maine on the Fourth of July (American Independence day). The approach to image is very painterly with the simple view transformed "with Turneresque luminosity." Most of the unusual visual effect is from the careful use of a shallow depth of field and natural objects (blowing grass, bushes, etc.)to bend and twist the images into a languid sense of time. In the end the film documents a state of mind more than a particular spot. It also resonates with the ambiguous metaphoric threat of a national symbol impinging upon the child's toy.
Festivals and Awards: Marin County 1994 First Place IMPAKT Festival (Netherlands) 1993 Osnabrück Media Arts Festival 1993 AVE Festival (Netherlands) 1993 MediaWave, Györ, Hungary Ann Arbor Film Festival Cash Award Humboldt Film Festival Black Maria 1993 Juror's Award Sinking Creek 1993 Kodak Cinematography Award Bucks County 1992 Cash Award
Screenings also at the American Museum of the Moving Image, The National Gallery of Art, Flaherty Film Seminars, etc.
Jon Jost
Canyon
16mm, 5 minutes, 1970
A single view of the Grand Canyon, seen over one day. I had been to the Canyon, hiked to the bottom, shot material which was useless, and returned several years later knowing I had nothing to say about the Grand Canyon, but that it should speak for itself.
Saturday October 2nd, 3.30pm. Donations appreciated.
Call Joss for more information and details on how to get to this month's Eiga Arts: 090-7165-999


Oh, don’t get me wrong, it’s exciting too. Turning to face the wide open plains of your imagination, you boldly stroll towards the horizon of your own creative tundra, pausing only to whet the thirst of your curiosity along the way. Through praxis, you discover a new way to look at the world: your way. It’s beautiful. It’s unique. It’s you.
You emerge, and eagerly share it with the world.

OK, it’s not like this for everyone. But sadly, that’s the story for many artists, whether musician, writer, designer, or VR painter. And the discrepancy is odd. We all agree that art has terrific value - paying for Netflix is no burden - except when we don’t. But we do skew towards rewarding major practitioners over small ones.
Forget Kanye and his Yeezy Adidas $600-for-a-pair of-sweatpants fashion line. Forget Damien Hirst and his allegedly-ironic-but-maybe-it’s-just-plain-old-end-stage-capitalism £1M diamond-encrusted skull. Forget Dan Brown and his “the famous man looked at the red cup” prose-of-doom that shifted 200 million copies at €9.99 a time in airports the world over. These are all the 1%.
If the internet era has taught us anything, it’s to ignore the 1% as much as is feasible. There needs to be a new way for creators to get their credit where it’s due. The problem is that maybe the world doesn’t want to do that any more.
———-
Learn to accept your reward
Just like every other industry, the arts celebrates the achievements of the few and pours money and attention onto them, whilst leaving the rest to wonder what separates them from the riches.
The 99% almost always produces something people want. The frustrating part is that, somewhere along the way, the reward for their work fizzles out and never quite reaches the artist; yet the consumer’s life is enriched a little bit by the existence of that art.
It’s one of the sad unifying experiences for any creator in any niche.
Hang your head, because we all helped create this nefarious disconnect - ever downloaded music that you’ve not paid for? Ever found an image online you liked and used it as your Facebook header? Ever googled for a hooky PDF of a trashy poolside thriller? Yeah, me too.
And these are just the obvious and lightweight examples of our behaviour widening the gap between creator and payment: have you ever paused to wonder who gets paid for the songs you stream for free off Youtube, and how much they get? (SPOILER: it’s about, erm, $0.0000616 per stream)
What about the pictures you linger over and bookmark on Pinterest? What about the hot-take blog posts you read to while away your time on the toilet?
But don’t feel bad. It’s not anyone’s fault that the creators rarely get rewarded: it’s the system, man.
And that system is about to change.
What is the system and how is it broken?
The system has been, for a long time, broadly along these lines: people make nice things, a few of these people become successful, this success breeds more success; repeat to fade. Meanwhile, the rest scratch around for the scraps of success.
This “success,” note, is not by any means just about money. It could be a thousand different varieties of reward; but mainly, it’s about public recognition. (OK, and money.)
Recognition is the bottom line for creators: it can be something as simple as attribution, because public recognition is the cultural currency that eventually becomes actual currency. And recognition changes in monetary value as the participants grow in stature.
Finding your work being used online without reward is akin to searching for a needle in a haystack, inside a universe made of haystacks. On acid.
Here’s an example of the accompanying thought process, in full:
- If you're running a small blog sharing cool designs, just use my pictures for free and recognise me by explaining who made it.
- If you’re a major fashion brand and are using my drawings (or something very much like them) on your handbags, recognise me with a big ol’ slice of that money you’re making off the back of them.
And here’s where the system breaks down. There are plenty of opportunities for creating value and reward between the two extremes outlined above. It’s just that the internet is wild, huge and fractured, and finding your work being used without reward online is akin to searching for a needle in a haystack, inside a universe made of haystacks. On acid.
So the chances are that despite your work being automatically copyrighted to you upon conception, it’s being used in all sorts of ways - some of the innocent and some not - and few give you any type of recognition, let alone money.
And here’s where the blockchain gallops into the picture, cresting the horizon of creativity, and promising, as it does to every industry, revolution.
Blocking creativity
The important thing to remember about the blockchain is that no-one really knows how it all works. Some people really know one or two parts of it really well, and how it fits into the rest. So feel free to bluff as much as you like from hereon.
But the miracle of blockchain tech - and especially varieties like Ethereum - is that not only can your work and attribution to you be recorded on a distributed public ledger, but also small "smart contracts" can be inserted into this public record.
It means that creatives can make a piece of artwork, confirm it is theirs, then set parameters for who can use it, how, and how much they get paid.
Companies like the Berlin-based Ascribe offer a brilliant way to make sure your work has a digital name plate beneath attached to it at all times. It means that wherever your work is used, it’s clear that it belongs to you.
You can specify how your work is used and in what context: maybe it’s gratis for a charity to use your poetry in their training materials, but if Pepsi wanted to put your poem on a soda can (bear with me here, we can live in hope), they’d need to cough up serious moolah.
And you can answer a tricky problem that has haunted artists since the digital age began: limited editions. Creating a limited run of 100 signed lithographic prints was - and still is - an idea that leverages value onto copies of art.
This hasn’t work well for digital art, which can be endlessly copied and shared - but this blockchain tech allows your photos to become limited editions, and identification of unlicensed use can be proven and enforced.
No one can use your work without your say-so. How could that possibly be a bad thing?
This is a powerful tool: suddenly, musicians can set a few parameters, and their songs can be used wherever they choose - in TV ads, movies, YouTube videos, fashion shows, cafes, etc - and they can be paid (maybe in an Art Cryptocurrency) immediately, in proportion to the use of it.
Or maybe you can set the possibility for your images to be printed and exhibited anywhere, wherever, and when the sale is made, because the transaction will be connected to the smart contract and the blockchain, you get paid immediately, at a price you choose, with a cut for the gallery you decide.
This version of the future is highly attractive and feels morally correct: your creative rights are not only assured, they’re enforceable and rewarded. No one can use your work without your say-so. How could that possibly be a bad thing?
———
The counterargument to a new, everything-attributed-everywhere system exists within the Meme Of Summer 2017: the Distracted Boyfriend.
The Distracted Boyfriend, like all true memes, began life as a creative artefact, and then has been remixed over and over - like photocopies of photocopies - until it has become a cultural artefact, with a whole new meaning.
This particular stock photograph was created and titled with the agonising obviousness of all stock photos (“Disloyal Man Walking With His Girlfriend And Looking Amazed at Another Seductive Girl”) by photographer Antonio Guillem.
Post-mememageddon, Antonio feels sore: possibly because everyone is sniggering at his creation, but certainly because his image is now one of the most recognisable in the world - and he’s not getting a penny from it.
Antionio is vaguely threatening to get the money he’s owed - by, I dunno, suing the internet? - for the unpaid use of his unintentionally hilarious photo.
Smart contracts within a blockchain system could have a free-to-use “Meme Clause” to prevent the Death Of Memes.
And this is where an open, enforceable attribution system could be used by mean-spirited or money-obsessed types to put the brakes on cultural creativity.
Dank memes bring levity to dark times, after all, and if an enforced need to pay - even just a one-off crypto-currency micro-transaction - meant that our dearest, dankest memes were extinguished before birth, then we’d all lose a tiny bit of joy.
Of course, smart contracts within any blockchain system could easily have a free-to-use “Meme Clause” to prevent the Death Of Memes.
But maybe bringing order to chaos might destroy the charm of the meme, or at least cause a de-dankification process from which our favourite gifs could never recover. A balance between memetic freedom and enforceable attribution could turn out to be the art-blockchain’s acid test.
Open everything, restrict nothing
In 2017, technology means that everything can be copied, often free from reprisal. Some people argue that, for the benefit of creativity, this should be the default setting.
Chinese IP laws are thought to be famously ignorable. Actually, Chinese IP laws are tightening fast but it’s not a massive stretch to assume that copyright, IP and patent laws are regularly flaunted. Have you ever had a cheap product shipped from China that looks just like the “real” version, and is very possibly made in similar factories, using similar, patented, machines?
Talent imitates, genius steals. In that case, China is the genius who now leads the world in creativity. In the industrial heartland of Shenzen, the flaunting of IP has, some argue, accelerated creativity for the benefit of humankind.
This process is also driven memetically. Chinese hacker, maker and open-source enthusiast David Li argues that the freedom to remix something someone else has made is more valuable than the restrictions that copyright brings.
This process - known in a positive and negative sense as Shanzai - is actually not a million miles from the Distracted Boyfriend meme.
Let’s imagine a US-based company designs a cutting-edge drone, and builds it in China.
Shanzai practitioners would quickly explore how the drone was built and look for ways not to copy it, but to evolve it: make it cheaper, faster to build, lighter, or more tailored to niche markets.
They could even use the tools, components and workforce on their doorstep to quickly beat the “real” product to market. The result is a drone that is, for many people, “better” in a number of different ways.
In the best case scenario, the beneficiary here is the many (the purchasers, who get a newer, “better” product), not the few (the original creators, who perhaps don’t even get credit, let alone money).
It’s not fair. But the majority, as we have seen repeatedly in a series of wild recent political events, has a habit of getting its way.
Me, me, me
Defending memes as an argument for radically changing how artists make a living is possibly one of the first signs of madness. But a world where a sliver of doubt is cast over the ability to take something, tweak it, and share it - for fun, or for the sake of selfless innovation, or just for the sheer hell of it - might not be one we want to live in.
And yet… shouldn’t creators be rewarded for their work, every time, without exception? Here’s that conflict again: humans love to create things, and the same humans like to get those things for as close to nothing as to make no difference.
So technology now means that the ability to remix, re-create, re-shape, re-think and re-form is not only a fun thing to do, but possibly the future of creativity itself. Maybe the act of creativity and what it means in terms of reward has quietly changed.
But we’re at a pivotal point where we might be able have our cake and eat it. "Remix creators" get to take everything apart and quickly make something new, the original creators get credit of some sort, and the human race as a whole gets a little bit richer in a different way each time.
It sounds like a good compromise for the benefit of everyone, and not just that gilded 1%. Oh, and we get to keep our sweet, sweet memes.


'Miracle' spray stops frost building on your car windscreen
For £25 you can wave goodbye to de-icing your car
by Rachel Pugh, Jamie HawkinsTemperatures continue to plummet across the country, meaning many have to de-ice their car in the morning.
Scraping ice off your car is not what you want to be doing first thing on a cold morning, especially as it can take ages to get rid of it all.
But, there is a way to stop this from every happening again thanks to a miracle spray, Manchester Evening News reports.
It's on sale at Halfords, and it promises to banish windscreen ice and fog for good.
A description on the Halfords website reads: "Duxback is a professional-quality car glass treatment that makes driving safer.
"Originally developed for the airline industry, Duxback causes water to 'bead' on glass, dramatically improving visibility in the rain.
In fact, if you're driving over 40mph, you won't even need wipers - the water runs straight off!
"What's more, it makes cleaning much easier, and prevents frost sticking to your windscreen in winter."
Each treatment costs £25, and lasts up to six months.
According to Halfords, research has shown that Duxback can increase visibility by 35% in pouring rain.
What's more, it's claimed, the treatment improves the driver's ability to identify a small object by 25%.
In winter time, ice will either not stick to the glass or will be much easier to remove, thanks to the product's hydrophobic qualities, it's claimed.
It even promises to make it easier to remove squashed bugs!