Andy Thomason is a Senior Programmer at Genomics PLC. He has been witing graphics systems, games and compilers since the '70s and specialises in code performance.
Self-descriptive data can be difficult to process since the format of the data is not fixed, but is instead described by metadata. The [Data Format Description Language (DFDL)] and [Apache Daffodil] are powerful tools that can describe and parse a wide variety of data, but even some self-descriptive data formats can prove to be a challenge, particularly when they are logically self-descriptive. Below we detail what DFDL is, what Apache Daffodil is, and a generic approach to use them to describe and parse complex self-descriptive data.
The [Data Format Description Language (DFDL)] is a specification, developed by the [Open Grid Forum], capable of describing many data formats, including both textual and binary, scientific and numeric, legacy and modern, commercial record-oriented, and many industry and military standards. It defines a language that is a subset of W3C XML schema to describe the logical format of the dat
#lang racket | |
;; this is a stand alone simple version of the closure conversion part of the hoist pass from the tarot compiler | |
;; see https://rain-1.github.io/scheme for more. | |
(require data/queue) | |
;; closure conversion for lambda calculus | |
;; | |
;; the input language is: |
[package] | |
name = "min-char-rnn-rs" | |
version = "0.1.0" | |
authors = ["Suyash <suyash93@protonmail.com>"] | |
edition = "2018" | |
[dependencies] | |
rulinalg = "0.4.2" | |
rand = "0.6.4" | |
indicatif = "0.11.0" |
This is not intended to be comprehensive or authoritative, just free online resources I've found valuable while learning more about Erlang.
- 0xAX's list of Erlang bookmarks
- Federico Carrone, Erlang Spawned Shelter
- Ivan Uemlianin's list of resources on various BEAM languages
- David Robakowski's curated list of awesome Erlang libraries, resources and shiny things
- Julius Beckmann's curated list of amazingly awesome Elixir and Erlang libraries, resources and shiny things
// Use the code below to simplify your re:Invent 2018 schedule search. | |
// Paste these into your browser console just once. They will remain in scope even after you change filters. | |
function openSchedules(elems) { | |
// As long as the list of elements is non-zero in length, expand the last element and call openSchedules with the rest. | |
if (elems.length) { | |
var el = elems.pop(); | |
setTimeout(openSchedules, 200, elems); // You could shorten the timeout, but that probably isn't polite. | |
el.click(); | |
} else { |
We're rapidly approaching a world where flow-based programming is taking the lead, but there isn't any useful notation to represent all of the complexities of flow management. Let's assume a basic flow that takes a click event, extracts the X and Y coordinates from it, and moves a player based on the extracted values.
+----------+ +-----------+ +------------+
| getClick +-----> extractXY +---------------> movePlayer |
+----------+ +-----------+ xyChannel +------+-----+
|
|
- Author: Richard Wei
- Date: October 2018
This document is written for both the machine learning community and the Swift programming language design community, with a strong focus on language design.
(dominic: this list of papers was originally recommended to me by Brain Noguchi @bnoguchi, and was a great start to understanding distributed systems)
Here's a selection of papers that I think you would find helpful and interesting:
The seminal paper about event ordering and concurrency. The important result is that events in a distributed system define a partially ordered set. The connection to what we're working on is fundamental, as this defines how to detect concurrent updates. Moreover, the chosen algorithm to turn the partially ordered set into a totally ordered set defines the conflict resolution algorithm.
http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf
Test scopes
- Unit test - an isolated test around a single 'unit' of code, although that can be anything from a method to a class to a series of (related) classes.
- Component test - same as a unit test
- Isolated test - a test that doesn't do any I/O, i.e. the Ports have been filled with in-memory Adapters
- Integration test - a test that interacts with deployed instances of the code and related services, possiby with some Test Doubles (mocked/faked/stubbed etc).
- End to End test - a test that entirely interacts with deployed instances using public interfaces
- Test-per-class - a convention that there should be one unit test for each class
Uses of tests