Chez Scheme是一种有着众多的语言和编程环境扩展的“Revised6 Report on Scheme [27] (R6RS)”实现。
本书详细描述了这些扩展。 亦包含了标准的和Chez Scheme的形式与过程的简明摘要，给出了每个形式和每个过程所接受的参数的数量和类型的语法。 标准Scheme特性的详细内容可参考The Scheme Programming Language, 4th Edition (TSPL4) [11]或者the Revised6 Report on Scheme. The Scheme Programming Language, 4th Edition也包含了一个关于Scheme语言的广泛的介绍和众多长长短短的例子。
本文档大部分内容也适用于Petite Chez Scheme（与完整版Chez Scheme系统完全兼容，但其使用了一个高速解释器替代了增量本地编译器）。 为Chez Scheme写的程序只要不调用编译器的话，那么无需修改就能在Petite Chez Scheme中运行， 事实上，Petite Chez Scheme编译自与Chez Scheme相同的代码，仅仅除去了与编译器相关的代码。 该区别造成的影响的详细讨论参见Section 2.8.
本章的其余部分将介绍Chez Scheme对Scheme语法的拓展(Section 1.1)，本书中使用的符号约定(Section 1.2)，用于系统自定义的参数用法(Section 1.3)，与如何查找与Chez Scheme相关的更多信息(Section 1.4).
Chapter 2 描述了如何使用Chez Scheme来进行程序开发、脚本、应用交付，以及如何使编译器生成最高效的代码。
Chapter 3 描述了调试和对象检查功能（//object inspection facilities）。
Chapter 4 陈述了与不同处理器或其他语言代码交互的facilities。
Chapter 5 描述了绑定表格。
Chapter 6 陈述了控制结构。
Chapter 7 陈述了对非数字对象的操作。
Chapter 8 陈述了各种对数字的操作，包括各种数字操作、高效的特定类型操作。
Chapter 9 描述了输入/输出操作和允许定义具有任意输入/输出语义的通用端口。
Chapter 10 讨论了如何将R6RS库和顶层程序加载到Chez Scheme以及控制和跟踪加载过程的各种功能。
Chapter 11 描述了语法扩展和模块。
Chapter 12 描述了系统操作，例如与操作系统交互和定制Chez Scheme的用户界面的操作。
Chapter 13 描述了如何调用和控制存储管理系统并记录监护人和弱对。（//documents guardians and weak pairs.）
Chapter 14 描述了Chez Scheme的表达式编辑器以及如何对其定制。
Chapter 15 陈述了包括Chez Scheme的本地线程系统接口的过程和语法形式。
Chapter 16 描述了各种兼容性功能。
本书的后面包含了参考书目，语法形式摘要，和索引。 在语法形式摘要出现的页码以及在索引中出现的斜体页码指明了语法形式和过程被正式定义在文本中的位置 语法形式摘要和索引包含了来自TSPL4的条目，故而它们完整覆盖了Chez Scheme的功能。 TSPL4的条目以一个“t”字母为页码前缀作为标记。
本书和TSPL4的在线版本和勘误表可参见www.scheme.com.
致谢: Michael Adams, Mike Ashley, Carl Bruggeman, Bob Burger, Sam Daniel, George Davidson, Aziz Ghuloum, Bob Hieb, Andy Keep, and Oscar Waddell have contributed substantially to the development of Chez Scheme. Chez Scheme's expression editor is based on a command-line editor for Scheme developed from 1989 through 1994 by C. David Boyer. File compression is performed with the use of the zlib compression library developed by Jean-loup Gailly and Mark Adler. Implementations of the list and vector sorting routines are based on Olin Shiver's opportunistic merge-sort algorithm and implementation. Michael Lenaghan provided a number of corrections for earlier drafts of this book. Many of the features documented in this book were suggested by current Chez Scheme users, and numerous comments from users have also led to improvements in the text. Additional suggestions for improvements to Chez Scheme and to this book are welcome.
Chez Scheme同时在对象(数据（//datum）)层面和语法形式层面拓展了Scheme的语法。 在对象层面，Chez Scheme支持包含非标准字符、以浮点数和科学计数法表达的非十进制数字、显式长度的向量、共享和环状结构、records，boxes等等的符号的额外表示法。 这些扩展将在下面描述。 语法形式层面的拓展的描述将贯穿本书，并且将总结在本书的后面的语法形式摘要中。
Chez Scheme以多种方式拓展了标识符的语法。 首先，组建标识符名字的字符序列可以以数字、句点、加号、减号为开头，只要整体不被解析为一个数字。 例如，0abc, +++, and ..在Chez Scheme中都是有效的标识符。 第二点，单字符序列{和}也是标识符。 第三点，包含任意字符的标识符将可以使用\或|来使用转义字符的方式打印。 \用来转义单个字符（除了‘x’，因为\x用于标记一个十六进制标量值的开始）， 而|用来转义从|开始到|结束的中键的字符串组。 例如\||\|是一个有着两个字符的标识符，其由一个字符|后跟一个字符\组成，而|hit me!|则是一个包含着一个空格字符的标识符。
此外，gensyms(page 7.9)能写成以#{和}括起来的包含漂亮和独一无二两个名字的形式，例如#{g1426 e5g1c94g642dssw-a}。 它们也可以只用漂亮名字以#:作为前缀来书写，例如#:g1426。
任意2到36的基数（译注，二进制基数是2、十进制基数是10、十六进制基数是16）可以使用前缀#nr，其中的n表示基数。 大小写并不重要，所以写成#nR也能用。 从10到35的数字能用大/小写的英文字母表示，就像十六进制那么用一样。 例如#36rZZ表示35 × 36 + 35，也即1295。
Chez Scheme也允许非十进制数字以浮点数或科学计数法的方式打印 例如，#o1.4等于1.5，而#b1e10等于4.0。 数字写在指数的前面，所以#x1e20等同于四位十六进制数7712.
除了标准命名的字符 #\alarm, #\backspace, #\delete, #\esc, #\linefeed, #\newline, #\page, #\return, #\space, 和 #\tab, Chez Scheme也能识别 #\bel, #\ls, #\nel, #\nul, #\rubout, 和 #\vt (or #\vtab)。 标量值小于256的字符也能以#\为前缀后跟3个八进制数的八进制方式书写。 例如，#\000等同于#\nul。
Chez Scheme的fxvectors，或者换种说法fixnum vectors，能写成类似向量(vectors)但却以#vfx(为前缀而不是#(的形式。 向量(Vectors)，bytevectors以及fxvectors都可以写成以一个明确的长度为前缀，并且当明确的长度被指定，重复的尾部元素可以被简写为一个。 例如，#(a b c)能写成#3(a b c)，而一个包含100个全零的向量可以简写为#100(0)。
Chez Scheme的box以#&为前缀，例如#&17是一个包含整型数17的box。
Records能写成#[type-name field ...]这样的语法形式，其中符号type-name是record的类型名、field ...则表示record字段的内容。
共享和循环结构可写成使用图标记和相关前缀#n=和#n#的形式。 #n=用于标记输入端的项， 而#n#用于标记被标注为n的项。 例如，'(#1=(a) . #1#)是一个car和cdr包含着同一list的pair，而#0=(a . #0#)是一个循环list，也就是说，它的cdr是它本身。
一个$primitive form (详见page 336)可能会以quote form同样的方式，即使用#%为前缀，作为缩写。 例如， #%car等同于($primitive car)， #2%car等同于($primitive 2 car)， #3%car等同于($primitive 3 car)，
Chez Scheme的end-of-file对象写作#!eof。 如果end-of-file对象出现在任何载入了的文件的数据外部（//If the end-of-file object appears outside of any datum within a file being loaded），load将把它视为一个真正的文件结尾并停止在这个位置的载入。 在一个文件的中间插入#!eof可以方便地跟踪load-time错误。
weak pairs中的Broken pointers(详见page 381)被表示为broken weak pointer对象，写作#!bwp。
除了标准的分隔符(空格，左右小括号，左右中括号，双引号，分号，以及#), Chez Scheme也将以下作为分隔符：左右大括号，单引号，反引号，逗号。
The Chez Scheme lexical extensions described above are disabled in an input stream after an #!r6rs comment directive has been seen, unless a #!chezscheme comment directive has been seen since. Each library loaded implicitly via import and each RNRS top-level program loaded via the --program command-line option, the scheme-script command, or the load-program procedure is treated as if it begins implicitly with an #!r6rs comment directive.
The case of symbol and character names is normally significant, as required by the Revised6 Report. Names are folded, as if by string-foldcase, following a #!fold-case comment directive in the same input stream unless a #!no-fold-case has been seen since. Names are also folded if neither directive has been seen and the parameter case-sensitive has been set to #f.
The printer invoked by write, put-datum, pretty-print, and the format ~s option always prints standard Revised6 Report objects using the standard syntax. For example, it prints symbols whose names require escaping using hex scalar value escapes, not one of the other mechanisms supported by the reader. Similarly, it does not print the explicit length or suppress duplicate trailing elements unless the parameter print-vector-length is set to true.
This book follows essentially the same notational conventions as The Scheme Programming Language, 4th Edition. These conventions are repeated below, with notes specific to Chez Scheme.
When the value produced by a procedure or syntactic form is said to be unspecified, the form or procedure may return any number of values, each of which may be any Scheme object. Chez Scheme usually returns a single, unique void object (see void) whenever the result is unspecified; avoid counting on this behavior, however, especially if your program may be ported to another Scheme implementation. Printing of the void object is suppressed by Chez Scheme's waiter (read-evaluate-print loop).
This book uses the words "must" and "should" to describe program requirements, such as the requirement to provide an index that is less than the length of the vector in a call to vector-ref. If the word "must" is used, it means that the requirement is enforced by the implementation, i.e., an exception is raised, usually with condition type &assertion. If the word "should" is used, an exception may or may not be raised, and if not, the behavior of the program is undefined. The phrase "syntax violation" is used to describe a situation in which a program is malformed. Syntax violations are detected prior to program execution. When a syntax violation is detected, an exception of type &syntax is raised and the program is not executed.
Scheme objects are displayed in a typewriter typeface just as they are to be typed at the keyboard. This includes identifiers, constant objects, parenthesized Scheme expressions, and whole programs. An italic typeface is used to set off syntax variables in the descriptions of syntactic forms and arguments in the descriptions of procedures. Italics are also used to set off technical terms the first time they appear. The first letter of an identifier that is not ordinarily capitalized is not capitalized when it appears at the beginning of a sentence. The same is true for syntax variables written in italics.
In the description of a syntactic form or procedure, a pattern shows the syntactic form or the application of the procedure. The syntax keyword or procedure name is given in typewriter font, as are parentheses. The remaining pieces of the syntax or arguments are shown in italics, using names that imply the types of the expressions or arguments expected by the syntactic form or procedure. Ellipses are used to specify zero or more occurrences of a subexpression or argument.
All Chez Scheme system customization is done via parameters. A parameter is a procedure that encapsulates a hidden state variable. When invoked without arguments, a parameter returns the value of the encapsulated variable. When invoked with one argument, the parameter changes the value of the variable to the value of its argument. A parameter may raise an exception if its argument is not appropriate, or it may filter the argument in some way.
New parameters may be created and used by programs running in Chez Scheme. Parameters are used rather than global variables for program customization for two reasons: First, unintentional redefinition of a customization variable can cause unexpected problems, whereas unintentional redefinition of a parameter simply makes the parameter inaccessible. For example, a program that defines *print-level* for its own purposes in early releases of Chez Scheme would have unexpected effects on the printing of Scheme objects, whereas a program that defines print-level for its own purposes simply loses the ability to alter the printer's behavior. Of course, a program that invokes print-level by accident can still affect the system in unintended ways, but such an occurrence is less likely, and can only happen in an incorrect program.
Second, invalid values for parameters can be detected and rejected immediately when the "assignment" is made, rather than at the point where the first use occurs, when it is too late to recover and reinstate the old value. For example, an assignment of *print-level* to -1 would not have been caught until the first call to write or pretty-print, whereas an attempted assignment of -1 to the parameter print-level, i.e., (print-level -1), is flagged as an error immediately, before the change is actually made.
Built-in system parameters are described in different sections throughout this book and are listed along with other syntactic forms and procedures in the Summary of Forms in the back of this book. Parameters marked "thread parameters" have per-thread values in threaded versions of Chez Scheme, while the values of parameters marked "global parameters" are shared by all threads. Nonthreaded versions of Chez Scheme do not distinguish between thread and global parameters. See Sections 12.13 and 15.6 for more information on creating and manipulating parameters.
The articles and technical reports listed below document various features of Chez Scheme and its implementation:
Links to abstracts and electronic versions of these publications are available at the url http://www.cs.indiana.edu/chezscheme/pubs/.
Chez Scheme Version 9 User's Guide
Copyright © 2016 Cisco Systems, Inc.
Licensed under the Apache License Version 2.0
(full copyright notice.).
Revised June 2016 for Chez Scheme Version 9.4
about this book


This is an analysis and commentary of the keywords in VLDB paper titles since 1975. The word vectors are clustered by shape and highlight the rise and fall of many topics in our area.
The analysis and data are all on GitHub.
See the old analysis at vldb.html.


About me
I am a passionate and self-taught mobile developer specializing in Flutter. My focus is on creating intuitive and aesthetically appealing mobile applications. Although I am new to the professional field, I have invested time and effort in building a strong foundation of knowledge in Flutter and Dart.
I am excited about opportunities for growth and learning, and I am ready to contribute to a dynamic team in the development of high-quality mobile applications.
What i'm doing
-
Mobile Apps
Professional development of applications for iOS and Android.
-
Scripting
Automation and task scripting using Python to enhance efficiency and productivity.
-
UI/UX Designing
Intuitive and visually appealing user interfaces and user experiences.
-
Web Development
High-quality development of sites at the professional level.


import ConnectionController from 'service-framework/src/hyperty/ConnectionController.js'
ConnectionController
Extends:
Constructor Summary
| Public Constructor | ||
| public |
constructor(syncher: *) |
Member Summary
| Public Members | ||
| public set |
dataObjectObserver(dataObject: ConnectionDataObject): * Set the dataObject in the controller |
|
| public get |
dataObjectObserver: ConnectionDataObject: * return the dataObject in the controller |
|
| public set |
dataObjectReporter(dataObject: ConnectionDataObject): * Set the dataObject in the controller |
|
| public get |
dataObjectReporter: ConnectionDataObject: * return the dataObject in the controller |
|
| public set |
remotePeerInformation(remotePeerInformation: Object): * Set Remote peer information, like Hyperty. |
|
| public get |
Get information relative to the Remote Peer; |
Method Summary
| Public Methods | ||
| public |
Used to accept an incoming connection request. |
|
| public |
Used to add/invite new peers on an existing connection instance (for multiparty connections). |
|
| public |
changePeerInformation(dataObjectObserver: *) |
|
| public |
|
|
| public |
|
|
| public |
Used to decline an incoming connection request. |
|
| public |
disableCam(): * |
|
| public |
disableMic(): * |
|
| public |
Used to close an existing connection instance. |
|
| public |
getUserMedia(options: Object): Promise Get WebRTC API resources |
|
| public |
infoError(err: *) |
|
| public |
mute(): * |
|
| public |
onLocalSessionCreated(description: *) |
|
| public |
processPeerInformation(data: *) |
|
| public |
remoteDescriptionError(error: *) |
|
| public |
|
|
| public |
Used to remove a peer from an existing connection instance. |
Public Constructors
public constructor(syncher: *) source
Params:
| Name | Type | Attribute | Description |
| syncher | * |
Public Members
public set dataObjectObserver(dataObject: ConnectionDataObject): * source
Set the dataObject in the controller
public get dataObjectObserver: ConnectionDataObject: * source
return the dataObject in the controller
Return:
| ConnectionDataObject | dataObject |
public set dataObjectReporter(dataObject: ConnectionDataObject): * source
Set the dataObject in the controller
public get dataObjectReporter: ConnectionDataObject: * source
return the dataObject in the controller
Return:
| ConnectionDataObject | dataObject |
Public Methods
public accept(options: *): Promise source
Used to accept an incoming connection request.
Params:
| Name | Type | Attribute | Description |
| options | * |
public addPeer(): Promise source
Used to add/invite new peers on an existing connection instance (for multiparty connections).
public changePeerInformation(dataObjectObserver: *) source
Params:
| Name | Type | Attribute | Description |
| dataObjectObserver | * |
public createAnswer() source
public createOffer() source
public getUserMedia(options: Object): Promise source
Get WebRTC API resources
Params:
| Name | Type | Attribute | Description |
| options | Object | Object containing the information that resources will be used (camera, mic, resolution, etc); |
public infoError(err: *) source
Params:
| Name | Type | Attribute | Description |
| err | * |
public onLocalSessionCreated(description: *) source
Params:
| Name | Type | Attribute | Description |
| description | * |
public processPeerInformation(data: *) source
Params:
| Name | Type | Attribute | Description |
| data | * |
public remoteDescriptionError(error: *) source
Params:
| Name | Type | Attribute | Description |
| error | * |


World Class
The dynamics world, where all bodies and constraints lives.
Constructor
World
-
[options]
Parameters:
-
[options]
Object optional-
solver
SolverDefaults to GSSolver.
-
gravity
Float32ArrayDefaults to [0,-9.78]
-
broadphase
BroadphaseDefaults to NaiveBroadphase
-
Item Index
Methods
Methods
addBody
-
body
Add a body to the simulation
Parameters:
-
body
Body
Example:
var world = new World(),
body = new Body();
world.addBody(body);
addContactMaterial
-
contactMaterial
Add a ContactMaterial to the simulation.
Parameters:
-
contactMaterial
ContactMaterial
clear
()
Resets the World, removes all bodies, constraints and springs.
fromJSON
-
json
Load a scene from a serialized state in JSON format.
Parameters:
-
json
Object
Returns:
True on success, else false.
getContactMaterial
-
materialA
-
materialB
Get a contact material given two materials
Returns:
The matching ContactMaterial, or false on fail.
hitTest
-
worldPoint
-
bodies
-
precision
Test if a world point overlaps bodies
Parameters:
-
worldPoint
ArrayPoint to use for intersection tests
-
bodies
ArrayA list of objects to check for intersection
-
precision
NumberUsed for matching against particles and lines. Adds some margin to these infinitesimal objects.
Returns:
Array of bodies that overlap the point
runNarrowphase
-
np
-
bi
-
si
-
xi
-
ai
-
bj
-
sj
-
xj
-
aj
-
mu
-
glen
Runs narrowphase for the shape pair i and j.
Parameters:
-
np
Narrowphase -
bi
Body -
si
Shape -
xi
Array -
ai
Number -
bj
Body -
sj
Shape -
xj
Array -
aj
Number -
mu
Number -
glen
Number
step
-
dt
Step the physics world forward in time.
Parameters:
-
dt
NumberThe time step size to use.
Example:
var world = new World();
world.step(0.01);
toJSON
()
Object
Convert the world to a JSON-serializable Object.
Returns:
upgradeJSON
-
json
Upgrades a JSON object to current version
Parameters:
-
json
Object
Returns:
New json object, or false on failure.
Properties
applySpringForces
Boolean
Enable to automatically apply spring forces each step.
bodies
Array
All bodies in the world.
constraints
Array
User-added constraints.
Gravity in the world. This is applied on all bodies in the beginning of each step().
contactMaterials
Array
The ContactMaterials added to the World.
defaultFriction
Number
Friction between colliding bodies. This value is used if no matching ContactMaterial is found for the body pair.
doPofiling
Boolean
Whether to do timing measurements during the step() or not.
lastStepTime
Number
How many millisecconds the last step() took. This is updated each step if .doProfiling is set to true.
lastTimeStep
Number
For keeping track of what time step size we used last step
solveConstraints
Boolean
Enable/disable constraint solving in each step.
springs
Array
All springs in the world.


Inevitably, when you start using a shared Terraform code base between more than two or three people you have to start introducing measures to ensure consistency of approach across your team.
For instance, how do you make sure everyone is running the same version of Terraform? Or that they’re initializing the backend properly? And if you’re using null_resource
resources or provisioner
blocks to execute scripts out-of-band, you have to ensure everyone has the right dependencies installed.
This is one approach I’ve used to address these problems, using a Docker image and a Makefile to provide a consistent environment for running Terraform locally and a wrapper around Terraform to make sure the whole team are executing it in the same way.
Requirements
- Relatively up to date versions of Docker and docker-compose
Repository structure
For the purposes of this post, let’s assume your Terraform code is all versioned in one repository with a structure similar to this:
.
├── README.md
└── terraform
├── project1
│ ├── main.tf
│ ├── outputs.tf
│ ├── variables.tf
│ └── vars
│ ├── dev.tfvars
│ ├── prod.tfvars
│ └── staging.tfvars
└── project2
├── main.tf
├── outputs.tf
├── variables.tf
└── vars
├── dev.tfvars
├── prod.tfvars
└── staging.tfvars
There’s a folder for each project in your organization under ./terraform/
containing .tf
files and a .tfvars
file for each environment. This is my preferred way to partition my Terraform code, but if yours is different it doesn’t make much difference in the context of this guide.
Dockerfile
The first thing I’m going to add is a Dockerfile
to the root of the repository:
FROM alpine:3.8
ENV TERRAFORM_VERSION=0.11.13
ENV AWSCLI_VERSION=1.14.10
RUN apk add --update bash make python python-dev py-pip build-base unzip ca-certificates jq
RUN pip install awscli==$AWSCLI_VERSION --upgrade
RUN wget https://releases.hashicorp.com/terraform/${TERRAFORM_VERSION}/terraform_${TERRAFORM_VERSION}_linux_amd64.zip \
&& unzip terraform_${TERRAFORM_VERSION}_linux_amd64.zip -d /usr/local/bin/
WORKDIR /terraform
ENTRYPOINT ["/bin/bash"]
Pretty simple. Essentially all I’m doing here is downloading my desired version of the Terraform binary to /usr/local/bin inside a simple alpine:3.8 image.
You’ll also notice that that I install awscli
and jq
. This is because in this particular code base I intend to run a few scripts out-of-band that require them. That’s why we’re using Docker: so we can be certain that when we run Terraform, we have everything we need, no matter who’s running it or where.
docker-compose
You might have noticed that I didn’t copy the contents of my ./terraform
directory into the Docker image. That’s because I’m going to mount it instead so that I can make changes to the files on my local filesystem but then apply them from within the running Docker container.
If you were including this repo inside a CI/CD pipeline, you might choose to copy the dir in to provide you with a versioned artifact. On the other hand, in that situation I think there’s still something to be said for versioning your terraform code and what is essentially your terraform binary separately. More on that later.
I create docker-compose.yml
next to my Dockerfile
:
version: '3'
services:
terraform:
build: .
tty: true
stdin_open: true
environment:
- AWS_DEFAULT_REGION=eu-west-2
volumes:
- ./terraform:/terraform
- ~/.aws:/root/.aws
Under volumes you can see I bind the ./terraform
directory to /terraform
on the container. I also mount the ~/.aws
directory and set the AWS_DEFAULT_REGION
environment variable so that the AWS credentials of the user will be available and the resources in the right region will be targeted (this is all assuming your Terraform code uses AWS resources, of course).
The tty
and stdin_open
bools set to true
ensure than when I eventually run the container, I get an interactive bash shell and I can cd to one of my project directories, see all the code and run Terraform if I wish.
$ docker-compose run terraform
bash-4.4# cd project1
bash-4.4# ls
main.tf outputs.tf variables.tf vars
bash-4.4# terraform get
bash-4.4# terraform init
Initializing the backend..
Makefile
This Makefile
wraps around the plan and apply commands, making sure they’re ran in a consistent fashion.
ENVIRONMENT := dev
PROJECT := $(notdir $(shell pwd))
TF_BUCKET := org-tfstate-${ENVIRONMENT}
.PHONY: update init plan apply
all: update
update:
@terraform get -update .
init: update
@terraform init \
-backend=true \
-backend-config="bucket=$(TF_BUCKET)" \
-backend-config="key=$(PROJECT).tfstate" .
plan: init
@-rm -f ./plan.tfout
@terraform plan \
-refresh=true \
-out=./plan.tfout \
-var-file=vars/$(ENVIRONMENT).tfvars $(ARGS) .
apply: init
@terraform apply ./plan.tfout
@-rm -f ./plan.tfout
By default the Makefile
targets the dev environment. This can be overriden by supplying the ENVIRONMENT
variable when make
is ran:
$ docker-compose run terraform
bash-4.4# cd project1
bash-4.4# make plan ENVIRONMENT=prod
Additionally, if you want to append extra arguments to plan
you can do so with ARGS
:
bash-4.4# make plan ARGS="-target=aws_s3_bucket.example"
You can place the Makefile
inside each project directory, alongside the .tf
files. Or, what I prefer to do is to put it at the root of the repository as common.makefile
and refer back to it with an include
statement in a Makefile
in each project. This avoids unnecessary duplication:
include ../../common.makefile
The structure now looks like this:
.
├── common.makefile
├── docker-compose.yml
├── Dockerfile
├── README.md
└── terraform
├── project1
│ ├── main.tf
│ ├── Makefile
│ ├── outputs.tf
│ ├── variables.tf
│ └── vars
│ ├── dev.tfvars
│ ├── prod.tfvars
│ └── staging.tfvars
└── project2
├── main.tf
├── Makefile
├── outputs.tf
├── variables.tf
└── vars
├── dev.tfvars
├── prod.tfvars
└── staging.tfvars
Continuous Deployment
This guide has assumed, so far, that individual team members are running Terraform to update infrastructure. However, when your Terraform deployment reaches a certain level of sophistication or your team reaches a size where it’s becoming hard to keep track of which changes have been deployed to which environment, you might start to consider running Terraform with a CI/CD solution.
There are numerous ways to implement this but my recommendation would be to separate the Dockerfile into it’s own repository and version it separately to your Terraform code.
Then, as part of your pipeline’s deployment phase, you could run something like the following from within a project root module:
$ docker run --rm -it -v .:/terraform -e AWS_PROFILE=$AWS_PROFILE myorg/terraform:v0.0.4 make plan
$ docker run --rm -it -v .:/terraform -e AWS_PROFILE=$AWS_PROFILE myorg/terraform:v0.0.4 make apply
This mounts the project dir in the container and runs plan
and apply
. It also passes the AWS_PROFILE
environment variable from your CI environment to the container. There’s obviously endless bespoke configuration you could add here.
Conclusion
This post gives you one approach to running terraform consistently that I’ve used with great success in a number of different organisations. I’d love to hear from anyone doing anything similar, or dissimilar, to achieve the same ends.


Legal stuff we're required to say:
General terms applicable to all PriceMet Vouchers (unless the Fine Print specifies an exception): This Voucher is not redeemable for cash. It does not cover tax or gratuity. The amount paid for this Voucher will never expire and may be applied toward any goods or services offered by the merchant if the original goods or services specified on the voucher are no longer available. If you have gone to the merchant and the merchant has refused to redeem the cash value of your expired Voucher, PriceMet will refund the purchase price of the Voucher. This Voucher can only be used for making purchases of goods/services at the named merchant. Merchant is solely responsible for Voucher redemption. Neither PriceMet nor the named merchant shall be responsible for PriceMet Vouchers that are lost or damaged. Voucher is for promotional purposes.


Full screen mode makes it simple for you to use Balthisar Tidy without any distractions. Follow these steps to enable full screen mode.
Select Enter Full Screen from the View menu.
Alternatively you can use the shortcut key as shown in the View menu.
You can also use the standard Mac OS X document window title bar control to start full screen.


-
Prediction and Analysis
Ladder Position Probabilities by Record
Show all records
Hide records with more than one draw
Hide all records with draws
Loading...
Who should I barrack for?
Loading...
Matches Played
Loading...
Matches to Come
Loading...


Creating your own token gives you additional options to manage apps in the web component. By having this you can:
You only need the token to get your settings saved. It's available everywhere!


Jian He
Welcome
Portfolio
Additional Links
Jian He
Game developer/designer, UI/UX designer, photographer.
Based in Miami.
Portfolio
Contact Me


Eid Muhammad
Contact
Portfolio
About
Portfolio
Add a description of the image here
Add a description of the image here
Add a description of the image here
Add a description of the image here
Your browser does not support the video tag.
Add a description of the image here


But it wasn't long before the gender dysphoria issues that had plagued I'm A Celebrity star Caitlyn from the age of 10 resurfaced and put a dampener on their love-making.
While their intimacy was always “imbued” with love, Cait - who was called Bruce before her transition - admitted the experience was an awkward one.
"My attitude is no different than it was in high school: I'm just not entirely comfortable with it," she wrote in her autobiography, The Secrets of My Life.
Indeed, before Kris, the Olympian had slept with just two other women - wives Chrystie Crownover and Linda Thompson.
And after her 2015 transition started, she remained decidedly on the fence about whether she would sleep with men, women or both.
"Of the most important things in my life, sex is beyond the bottom; it has been that way for a long time," she explained.
“A future female companion? I think about that.  Not happening, at least for now, and perhaps not ever,” Caitlyn, 70, wrote in her memoirs.
At the time, she hinted she may actually have been more open to meeting a man.
 I have never had the inclination. But maybe that attitude might possibly change if I have the Final Surgery," she continued.

“The surgery was a success, and I feel not only wonderful but liberated," she wrote, insisting the body part was 'just a penis' that was of no 'use'.
"I just want to have all the right parts. I am also tired of tucking the damn thing in all the time," joked the reality star, who also underwent a nose job, boob job, tracheal shave, jaw reshaping and beard removal as part of her transition.
Then reports claimed she was dating transgender model Sophia Hutchins, 23.
And in 2017, Caitlyn hinted that she was once again enjoying intimacy, telling The Times she'd previously been "no good" at sex because it meant “giving", adding, "[but] I believe I am better now."
Meanwhile, Caitlyn and Sophie wasted no time moving in together and have spent the last two years jet-setting across the globe.
Acknowledging their reported relationship, Caitlyn's step-daughter Khloe Kardashian described Sophia as, "really sweet."
"She’s younger, but she’s not bothering anyone. She’s super sweet," she said in a Divorce Sucks! podcast.
And while neither Cait or Sophie have officially confirmed their relationship status, the latter described them as "partners in everything we do".
"We’re inseparable, we’re business partners, we live together, we share a dog, we share family, we share a life together," she said.


Downloads Release Notes
Release Notes
What has updated, changed or fixed in each release of Infinispan
Infinispan 10.0 Release Notes
LOREM
- Compile-time internal dependency injection removes runtime reflection
- Non-blocking embedded and remote listeners
- Expiration on primary-node only to reduce load
- Quarkus
- Off-heap iterator improvements
Infinispan Server
- Complete rearchitecture
- Reduced disk footprint (50MB vs 170MB)
- Reduced boot memory footprint (18MB vs 40MB)
- Single-port design for Hot Rod, HTTP/1.1 and HTTP/2
- Elytron-backed security
- New Hot Rod authentication mechs (SCRAM, OAUTHBEARER)
- New HTTP authentication mechs (DIGEST, CLIENT_CERT, TOKEN)
- Non-blocking Hot Rod and REST authentication
- New CLI
- REST-based admin API
Quarkus
- Embedded Quarkus extension
- Remote Quarkus extension
- Native server
REST
- New V2 REST API
- Support for counters
- Much better performance
- Full authorization support
Marshalling
- Complete separation of internal and user marshaller
- Embedded marshaller is now based on Protocol Buffers
Configuration
- Inline JGroups configuration with XSite
- Out-of-the-box JGroups stacks for many cloud environments
- XInclude support
Management, monitoring and logging
- MicroProfile metrics
- OpenMetrics endpoint
- Coarse-grained logging categories
- JSON logging
Persistence
- All core cache-stores are now non-blocking
- Increased passivation throughput
- Segmented stores by default for faster performance and decreased memory usage
Container Image
- Based on UBI Minimal and Java 11
- Simple YAML configuration
- Authentication, Encryption, Logging and XSite support
Cross-Site Clustering
- Concurrent requests handled simultaneously instead of sequentially
- Detect site disconnections in async mode
- Metrics for asynchronous requests
Infinispan 9.4 Release Notes
Core
- Segmented off-heap data container
Data Interoperability
- Transcoding completely replaces compatibility mode
Cache Stores
- Segmented cache stores
Infinispan Server
- Rebased on WildFly 14
Management, monitoring and logging
- Hot Rod client-side statistics
Hot Rod / REST
- Transaction recovery over Hot Rod
- Near-cache performance/reliability improvements
Infinispan 9.3 Release Notes
Core
- Segmented on-heap data dontainer
- Cluster-wide max idle expiration
Data Interoperability
- Transparently convert between JSON and Protobuf for remote APIs
Cache Stores
- Write-behind stores are now fault-tolerant
Infinispan Server
- Rebased on WildFly 13
- Single port access independent of protocol
Management, monitoring and logging
- Improved editors to add syntax highlighting
Hot Rod / REST
- Transactions over Hot Rod
- On the fly data conversion
Integrations
- Hibernate 5.1/5.3 second-level cache providers
- Hibernate Search 5.10
- WildFly feature packs for Infinispan use in app server
Infinispan 9.2 Release Notes
Core
- Further improvements to conflict resolution and merge policies
- Reactive streams for increased throughput
- Biased reads for scattered caches
- More accurate off-heap memory calculations
Data Interoperability
- Transparently convert between JSON and Protobuf
API
- Multimap caches for embedded and Hot Rod
- Clustered Counters for Hot Rod
- Clustered Locks
- Wildcard configurations
- Cluster-wide cache admin via embedded and remote
Indexing and Query
- Broadcast queries
Management, monitoring and logging
- Console support for counters
- Improved remote protocol access logging
Infinispan Server
- Rebased on WildFly 11
- Hot Rod server uses async ops for reduced thread usage
Integrations
- JCache 1.1
- Hibernate 5.1/5.2 second-level cache providers
- Azure cloud discovery
Hot Rod / REST
- Clustered Counters over Hot Rod
- MultiMap over Hot Rod
- Queries over REST
- Hot Rod Client rewritten to use Netty
Infinispan 9.1 Release Notes
Core
- Conflict resolution and merge policies
- Performance improvements
Cache Stores
- Batching support
API
- Clustered counters
- Exclusive stream operations
- Distributed compute(), computeIfAbsent(), computeIfPresent()
Infinispan Server
- HTTP/2 support for the REST endpoint
- Much improved REST endpoint performance
Management and monitoring
- Endpoint management through the console
- Usability improvements
Integrations
- Improved Kubernetes PING support
Infinispan 9.0 Release Notes
Core
- Graceful shutdown and restart with persistent cache state
- Off-heap storage
- Performance improvements
- New internal marshaller
Indexing and Query
- Ickle, a new query language derived from JPQL with full-text predicates
- Replace the HQL translator with an internal one
- Always cache the query AST
- ElasticSearch indexing backend
API
- Replace the home-brew notifying futures with CompletableFutures everywhere
- Stream usability improvements
Infinispan Server
- Server base upgraded to WildFly 11
- SNI for Hot Rod and REST
- Multi-tenancy
Eviction
- New bounded container based on Caffeine
- More reliable eviction
Integrations
- Spring Session support
- Kryo and Protostuff marshallers for Hot Rod
- Kubernetes PING support
Management and monitoring
- Web console works with both domain and standalone mode
Cache Stores
- RocksDB cache store which replaces the LevelDB one
- Upserts and transactions for JDBC stores
- HikariCP connection pooling
- Dropped Mixed and Binary JDBC stores
Infinispan 8.2 Release Notes
Core
- Staggered remote gets
- Continued internals refactoring
- Synchronous consistent hashing is now the default
- Initial cluster size configuration
- Performance and memory allocation-rate improvements
Indexing and Query
- Explicit indexed entity configuration
- Hibernate Search 5.6 Alpha and Lucene 5.5
- Unified continuous query API between embedded and remote
- Experimental index affinity
API
- New lambda-aware clustered executor to replace distributed executor
Infinispan Server
- Server base upgraded to WildFly 10
- Queryable event logger
- More complete management ops for schemas and scripts
Management and monitoring
- Persistent login session which survives refresh
- Deployment / undeployment of user code
- Management of ProtoBuf schemas for indexing
- Management of scripts for task execution
- Event viewing
- Much improved cache and template configuration
- Container configuration
- Cross-site replication management
Server tasks
- Deployable tasks
- Alternate data-types for input/output for cross-language compatibility
Infinispan 8.1 Release Notes
Core
- Global state persistence
- Continued internals refactoring
- Per-cache rebalance control
Indexing and Query
- Continuous Queries are now indexed
- Projections in Continuous Queries
- Lots of improvements in performance and correctness
API
- Cache injection in forEach consumer
Infinispan Server
- Server base upgraded to WildFly 10
- Caches can be hidden from the clients to perform maintenance
Management and monitoring
- Huge overhaul of the web-based management console for server
Server tasks
- Includes server-side scripting
- Per-task role ACL, strict named-parameter checking
Hot Rod protocol improvements
- Site failover support
- Clustered statistics
- Compatibility mode awareness
Security
- Improved caching of ACLs with flush ops
Infinispan 8.0 Release Notes
Core
- Based on Java 8
- Reduced resource consumption
- Reduced locking
- Separate thread pool for async operations
Indexing and Query
- Continuous Query listeners
- Grouping and Aggregation with DSL-based queries
- Mixed queries, supporting indexed and non-indexed fields
- The indexing and query engine has been upgraded to Lucene 5.2
API
- New lambda-based functional cache API
- Distributed streams based on java.util.stream
- Configuration templates
Integrations
- Apache Spark connector
- Apache Hadoop connector
Eviction
- Memory size-based eviction
- Runtime resizing of the maximum number of entries
Management and monitoring
- Remote entry iterator
- Expose server segment mapping
Listeners
- Notifications for entry expiration
- Listeners can be registered using DSL queries
Hot Rod protocol improvements
- Remote entry iterator
- Expose server segment mapping
Infinispan 7.2 Release Notes
Bulk operations
- The performance of bulk operations (getAll, putAll) in both embedded and remote mode has been improved by an order of magnitude
- The clear operation is now non-transactional and lock-free.
Scripting (JSR-223) in server
- Allows creation of server-side scripts which can be invoked from HotRod
Eviction
- New design based on the ConcurrentHashMap from JDK 8
- The maximum number of entries is now respected exactly, and not rounded up to the nearest power of 2
- A greatly improved LIRS algorithm which is much more accurate in deciding which entries to evict
Integrations
- JCache (JSR-107) support over Hot Rod
Listeners
- Listeners can be registered using DSL queries
Cache Stores
- It is now possible to deploy cache stores to the server
- We now have a cache store Maven archetype
Configuration
- Configuration inheritance now only applies modified attributes, making programmatic templating more predictable
Indexing
- More performance improvements
Infinispan 7.1 Release Notes
Near Cache support
- HotRod clients can utilize near caching to improve read performance
Uber Jars
- The CLI is now also packaged as an UberJar
- Many fixes to classloading and hiding of private inner packages
Partition Handling
- Cluster will enter degraded mode instead of unavailable allowing for more keys to stay available
- Huge stability improvements
Indexing
- Mass Indexer operation no longer blocks
- Huge performance/stability improvements in indexing
Clustered listeners
- Enhanced performance when multiple cluster listeners are installed as well as asynchronous cluster listeners
Remote events over HotRod
- Remote event filter/converter callbacks can use raw data
Enhanced Statistics
- Statistics for clustered caches
- Statistics for a single node
Entry Iterator
- Local entry iteration when no loader should operate subsantially faster
Infinispan 7.0 Release Notes
Partition Handling
- Detects split brain scenarios and reduces availability to provide consistency in such situations
Uber JARs
- To add Infinispan to your application you now need to use only one JAR
Security
- Cache and CacheManager authorization with support for custom auditing. This feature can optionally integrate with the JDK SecurityManager.
- HotRod authentication based on SASL and integrated with the Security Realms in the server.
- Clustering authentication and authorization integrated with the Security Realms in the server.
Brand new XML configuration
- XML configuration has been revamped to match server-side configuration format found in Infinispan Server, Wildfly or JBoss Application Server 7.
- Support for the XML format used by Infinispan 6.0 and older has been dropped
Cross-Site Clustering
State-transfer across sites for seamless synchronization of data when a remote site is brought online
Query improvements
- Indexless queries
- Integration with Apache Lucene version 4.10.x
- Improved reliability of index storage
- Significant performance improvements for asynchronous indexing backends
- Experimental support for “MoreLikeThis” queries
- Automatic election of “master” indexing node (experimental)
Clustered listeners
Distributed caches can now notify a single listener in the cluster of all write events
Remote events over HotRod
- Server-side cache events can be now propagated to Hot Rod clients that register listeners, enabling near-cache architectures.
- Events can be filtered server-side and they can be customized to fit the user.
Distributed Entry Iterator
- Allows for memory sensitive way to iterate entire contents of the cluster
- Provides way for filtering of entries retrieved and materialized views
Remote Query improvements
- Simplified schema management using the cache API
- Schemas are automatically compiled by the server
- Field-level indexing granularity
- Protobuf schemas are supported without need to precompile them
Map bulk operations enhancements (entrySet, keySet, values, size)
- Operations now properly take into account entire cluster contents
- Returned collections are now backing in that updates to the collection are reflected in the cache and vice versa
Infinispan Server improvements
- Hot Rod remote event filters and converters, container within JAR files, can be deployed using standard mechanisms to Infinispan Servers.
- The server CLI is now built on top of WildFly’s CLI enabling access to the full Domain Management Model
Map/Reduce performance improvements
- Now takes advantage of multicore concurrency in all phases for exceptional speedup when compared to Infinispan 6
Hot Rod 2.0 protocol improvements
- RemoteCache.size() now implemented with a dedicated size() operation in the protocol, which takes both persistent store, and cluster wide cache contents into account.
- Better topology updates sent to clients, containing less information and providing more precise key location mechanism.
Integrations
- JCache (JSR-107) support upgraded to 1.0.0
- Support for CDI events
- OSGi support
- Support for both Spring 3.x and 4.x
New experimental Soft Index File Store
- A file store which indexes entries using B+ tree that is cached in-memory using Java's soft references


{% filter markdown %}
![Mountain](http://7xkb4l.com1.z0.glb.clouddn.com/blog/mountain.jpg "Mountain")
My name is Yufei Li, major in computer science. I like python, and interested in machine learning. I believe in:
> Living and hrad working, Simple is powerful.
{% endfilter %}
{% filter markdown %}
## LATEST UPDATES
## Open Source Project
I had pushed most of my open source project to [Github](http://github.com/yufeiminds), under MIT License, and you may also preview it on [Lab](http://lab.thxminds.com).
## THXMINDS.COM
The theme of this blog is design by [Lepture](http://lepture.com), I custom it a little and add the formula support.
All the content are under the [CC By 4.0]() License, you may found it on [Github]().
Theme power by [Lepture](http://lepture.com) - [yue.css](http://lab.lepture.com/yue.css/)
{% endfilter %}


Where have the main party leaders visited so far?
Jeremy Corbyn has clocked up the most visits, but Boris Johnson has covered more ground
The main party leaders have been criss-crossing the country for nearly three weeks, but there is one type of constituency they have yet to visit on the campaign: a Liberal Democrat seat.
This is just as true for Lib Dem leader Jo Swinson as for Boris Johnson and Jeremy Corbyn.
The fact that all three have yet to make a campaign stop in a Lib Dem seat reflects the lopsided battleground of this year’s election.
The race for Number 10 will be won and lost mainly in constituencies that are contests between the Tories and Labour.
Neither of these parties has much chance of taking seats from the Lib Dems.
Another is that many of the seats the Lib Dems are defending are in areas that voted strongly Remain in the 2016 EU referendum, which puts them pretty much out of reach of the Conservatives.
Ms Swinson has yet to pay a campaign visit to a single seat her party is defending, which says a lot about her expectations in this election.
Instead she has spent her time mostly visiting Conservative and Labour seats that would need a big swing to be gained by the Lib Dems.
She has visited just two marginal seats on her party’s target list: Fife North East (being defended by the SNP) and St Albans (Conservative).
By contrast, Mr Corbyn has visited 13 Tory-held seats, 10 of which are marginal enough to fall to Labour on a swing of 5% or below – including the ultra-marginal seats of Pudsey (0.31%), Telford (0.81%) and Milton Keynes South (1.34%)
Mr Johnson has made fewer campaign visits than his Labour counterpart, but has still clocked up 12 Conservative-held seats and nine Labour-held seats, including two that would fall to the Tories on a swing of under 1%: Ashfield (0.44%) and Stockton South (0.82%).
Unlike the Labour and Lib Dem leaders, Mr Johnson has yet to go campaigning in an SNP-held constituency.
But he is the only leader to have travelled to all four nations of the UK.
There is one constituency to which all three leaders have paid a visit: Doncaster North, a safe Labour seat, but the location of some of the worst damage in the recent floods.


Terms of Use
Copyright © 2018 Your Name
This website belongs to Your Name Copyright © 2018. All Rights Reserved. All information presented on the website is reserved with the exception of third-party logos, pictures, text and / or links that are subject to the copyright rights of their providers. Any duplication or use of objects such as images or texts in other electronic or printed publications is not permitted without Your Name's agreement.


This test checks that spelling suggestions in the context menu are not show when spellcheck="false". To test manually, right click on the text in the input box.


Body Class
A rigid body. Has got a center of mass, position, velocity and a number of shapes that are used for collisions.
Constructor
Body
-
[options]
Parameters:
-
[options]
Object optional-
[mass=0]
Number optionalA number >= 0. If zero, the .motionState will be set to Body.STATIC.
-
[position]
Float32Array | Array optional -
[velocity]
Float32Array | Array optional -
[angle=0]
Number optional -
[angularVelocity=0]
Number optional -
[force]
Float32Array | Array optional -
[angularForce=0]
Number optional
-
Item Index
Methods
Properties
Methods
addShape
-
shape
-
[offset]
-
[angle]
Add a shape to the body. You can pass a local transform when adding a shape, so that the shape gets an offset and angle relative to the body center of mass. Will automatically update the mass properties and bounding radius.
Parameters:
-
shape
Shape -
[offset]
Float32Array | Array optionalLocal body offset of the shape.
-
[angle]
Number optionalLocal body angle.
Example:
var body = new Body(),
shape = new Circle();
// Add the shape to the body, positioned in the center
body.addShape(shape);
// Add another shape to the body, positioned 1 unit length from the body center of mass along the local x-axis.
body.addShape(shape,[1,0]);
// Add another shape to the body, positioned 1 unit length from the body center of mass along the local y-axis, and rotated 90 degrees CCW.
body.addShape(shape,[0,1],Math.PI/2);
adjustCenterOfMass
()
Moves the shape offsets so their center of mass becomes the body center of mass.
applyForce
-
force
-
worldPoint
Apply force to a world point. This could for example be a point on the RigidBody surface. Applying force this way will add to Body.force and Body.angularForce.
Parameters:
-
force
Float32ArrayThe force to add.
-
worldPoint
Float32ArrayA world point to apply the force on.
fromPolygon
-
path
-
[options]
Reads a polygon shape path, and assembles convex shapes from that and puts them at proper offset points.
Parameters:
-
path
ArrayAn array of 2d vectors, e.g. [[0,0],[0,1],...] that resembles a concave or convex polygon. The shape must be simple and without holes.
-
[options]
Object optional-
[optimalDecomp=false]
Boolean optionalSet to true if you need optimal decomposition. Warning: very slow for polygons with more than 10 vertices.
-
[skipSimpleCheck=false]
Boolean optionalSet to true if you already know that the path is not intersecting itself.
-
[removeCollinearPoints=false]
Boolean | Number optionalSet to a number (angle threshold value) to remove collinear points, or false to keep all points.
-
Returns:
True on success, else false.
removeShape
-
shape
Remove a shape
Parameters:
-
shape
Shape
Returns:
True if the shape was found and removed, else false.
setZeroForce
()
Sets the force on the body to zero.
toLocalFrame
-
out
-
worldPoint
Transform a world point to local body frame.
Parameters:
-
out
Float32Array | ArrayThe vector to store the result in
-
worldPoint
Float32Array | ArrayThe input world vector
toWorldFrame
-
out
-
localPoint
Transform a local point to world frame.
Parameters:
-
out
ArrayThe vector to store the result in
-
localPoint
ArrayThe input local vector
updateBoundingRadius
()
Update the bounding radius of the body. Should be done if any of the shapes are changed.
updateMassProperties
()
Updates .inertia, .invMass, .invInertia for this Body. Should be called when changing the structure or mass of the Body.
Example:
body.mass += 1;
body.updateMassProperties();
Properties
angle
Number
The angle of the body
angularForce
Number
The angular force acting on the body
angularVelocity
Number
The angular velocity of the body
boundingRadius
Number
Bounding circle radius
DYNAMIC
Number
static
Dynamic body.
force
Float32Array
The force acting on the body
id
Number
The body identifyer
inertia
Number
The inertia of the body around the Z axis.
invInertia
Number
The inverse inertia of the body.
invMass
Number
The inverse mass of the body.
KINEMATIC
Number
static
Kinematic body.
mass
Number
The mass of the body.
motionState
Number
The type of motion this body has. Should be one of: Body.STATIC (the body does not move), Body.DYNAMIC (body can move and respond to collisions) and Body.KINEMATIC (only moves according to its .velocity).
Example:
// This body will move and interact with other bodies
var dynamicBody = new Body();
dynamicBody.motionState = Body.DYNAMIC;
// This body will not move at all
var staticBody = new Body();
staticBody.motionState = Body.STATIC;
// This body will only move if you change its velocity
var kinematicBody = new Body();
kinematicBody.motionState = Body.KINEMATIC;
position
Float32Array
The position of the body
shapeAngles
Array
The body-local shape angle transforms. This is an array of numbers (angles).
shapeOffsets
Array
The local shape offsets, relative to the body center of mass. This is an array of Float32Array.
shapes
Array
The shapes of the body. The local transform of the shape in .shapes[i] is defined by .shapeOffsets[i] and .shapeAngles[i].
STATIC
Number
static
Static body.
velocity
Float32Array
The velocity of the body
vlambda
Float32Array
Constraint velocity that was added to the body during the last step.
wlambda
Float32Array
Angular constraint velocity that was added to the body during last step.


§412:5-304 General requirement for investments. A bank shall make investments that are consistent with prudent banking practices and in compliance with all applicable federal and state law. [L 1993, c 350, pt of §1]


JavaScript To-Do List
JavaScript script to-do list
custom alert message.
add
JavaScript is powerful.
I like coding
Personal website.
Click me to remove.
Clear All


Freesound
open class Freesound
Freesound** is an abstract class that manages interactions with the Freesound API.
-
Returns whether or not the current app is authorized to use Freesound.
Declaration
Swift
static public var isAuthorized: Bool
-
Stores client information to later communicate with API. Should be called first, typically in the AppDelegate method application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions:).
Declaration
Swift
static public func setup(with clientID: String, clientSecret: String)
Parameters
clientID
The client ID registered with the Freesound API.
clientSecret
The client secret registered with the Freesound API.
-
Authorizes client via OAuth2 and retrieves access token. Should be called if not already authorized, which can be checked via the isAuthorized property. If already authorized, see refresh().
Declaration
Swift
static public func authorize(handler: @escaping () -> ())
Parameters
handler
A closure in which you may implement some input interface for the user to enter a temporary authorization code obtained after logging in to Freesound, which can then be used with handleCode(_:).
-
Refreshes authorization, retrieves new access and refresh tokens. Typically called if already authorized, which can be checked by accessing the isAuthorized property.
Declaration
Swift
static public func refresh()
-
Handles the temporary authorization code generated by Freesound.
Declaration
Swift
static public func handleCode(_ code: String?) -> FreesoundResult
Parameters
code
The temporary authorization code provided by Freesound to the user.
-
Text search searches sounds using tags and metadata.
Declaration
Swift
static public func search(_ text: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
text
The query text to look up.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the sounds on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Content search searches sounds using their content descriptors.
Declaration
Swift
static public func contentSearch(_ target: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
target
The ID of a sound whose content descriptors should be used in the query.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the sounds on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Content search searches sounds using their content descriptors.
Declaration
Swift
static public func contentSearch(_ target: [String: String], page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
target
A dictionary of filters and corresponding values (given as strings).
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the sounds on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Downloads a sound file to a specified URL.
Declaration
Swift
static public func download(_ id: String, to url: URL, handler: @escaping ((URL?) -> ()))
Parameters
id
The ID number of a sound to download.
url
The destination URL to download a sound to.
handler
A closure that takes an optional URL (nil if the file didn’t download correctly).
-
Uploads a sound file to Freesound.
Declaration
Swift
static public func upload(_ url: URL, name: String = "", tags: [String]? = nil, description: String = "", pack: String? = nil, license: FreesoundLicense, geoTag: Bool = false, handler: @escaping FreesoundHandler)
Parameters
url
The URL of the sound file to upload.
name
The name for the uploaded sound.
tags
Tags for the uploaded sound (nil by default).
description
A description to add to the uploaded sound.
pack
The name of a new/existing pack to add the sound to (nil by default).
license
The license for the uploaded sound.
geoTag
A boolean value indicating whether or not to geotag the sound (false by default). May request user authorization to access location data.
handler
A closure that handles the response data, an optional dictionary with the following keys:
- detail: A confirmation message.
- id: The sound ID if a description was provided, OR
- name: The sound name if a description was not provided.
-
Describes an upload-pending sound.
Declaration
Swift
static public func describeSound(_ uploadFilename: String, name: String?, tags: [String]? = nil, description: String, license: FreesoundLicense, pack: String? = nil, geoTag: Bool = false, handler: @escaping FreesoundHandler)
Parameters
uploadFilename
The upload-pending file to add a description to.
name
A name for the uploaded sound.
tags
Tags for the uploaded sound (nil by default).
description
A description to add to the uploaded sound.
license
The license for the uploaded sound.
pack
The name of a new/existing pack to add the sound to (nil by default).
geoTag
A boolean value indicating whether or not to geotag the sound (false by default). May request user authorization to access location data.
handler
A closure that handles the response data, an optional dictionary with the following keys:
- detail: A confirmation message.
- id: The sound ID.
-
Edits an existing sound file’s description on Freesound.
Declaration
Swift
static public func editSoundDescription(_ id: String, name: String?, tags: [String]? = nil, description: String, license: FreesoundLicense, pack: String? = nil, geoTag: Bool = false, handler: @escaping FreesoundHandler)
Parameters
id
The ID number of a sound whose description to edit.
name
A new name for the sound.
tags
New tags for the sound (nil by default).
description
A new description for the sound.
license
The new license for the sound.
pack
The name of a new/existing pack to add the sound to (nil by default).
geoTag
A boolean value indicating whether or not to geotag the sound (false by default). May request user authorization to access location data.
handler
A closure that handles the response data, an optional dictionary with the following key:
- detail: A confirmation message.
-
Retrieves a dictionary of pending uploads.
Declaration
Swift
static public func getPendingUploads(handler: @escaping FreesoundHandler)
Parameters
handler
A closure that handles the response data, as an optional dictionary with the keys:
- pending_description: An array of filenames for sounds pending description.
- pending_processing: An array of dictionaries, each representing a sound.
- pending_moderation: An array of dictionaries, each representing a sound.
-
Bookmarks a sound for the logged in user.
Declaration
Swift
static public func bookmarkSound(_ id: String, name: String? = nil, category: String? = nil, handler: @escaping FreesoundHandler)
Parameters
id
The ID of the sound to be bookmarked.
name
A new name for the bookmarked sound (nil by default).
category
A bookmark category for the bookmarked sound (nil by default).
handler
A closure that handles the response data, an optional dictionary with the following key:
- detail: A confirmation message.
-
Rates a sound for the logged in user (rating range is 0-5).
Declaration
Swift
static public func rateSound(_ id: String, rating: Int, handler: @escaping FreesoundHandler)
Parameters
id
The ID of the sound to be rated.
rating
The rating for the sound as an integer from 0 to 5.
handler
A closure that handles the response data, an optional dictionary with the following key:
- detail: A confirmation message or description of an error if one occurred.
-
Add a comment to a sound on Freesound.
Declaration
Swift
static public func commentSound(_ id: String, comment: String, handler: @escaping FreesoundHandler)
Parameters
id
The ID of the sound to comment on.
comment
The comment to leave.
handler
A closure that handles the response data, an optional dictionary with the following key:
- detail: A confirmation message.
-
Gets preview audio for a sound.
Declaration
Swift
static public func getPreview(_ id: String, to url: URL, quality: FreesoundPreviewQuality, handler: @escaping (URL?) -> ())
Parameters
id
The ID of the sound whose preview audio to get.
url
The URL to download the preview audio to.
quality
The quality (high/low) of the preview to get.
handler
A closure that takes an optional URL (nil if the file didn’t download correctly).
-
Gets preview URL for a sound.
Declaration
Swift
static public func getPreviewURL(_ id: String, quality: FreesoundPreviewQuality, handler: @escaping (URL?) -> ())
Parameters
id
The ID of the sound whose preview URL to get.
quality
The quality (high/low) of the preview soundfile whose URL to get.
handler
A closure that takes in an optional URL that points to the preview soundfile.
-
Retrieves a user instance.
Declaration
Swift
static public func getUserInstance(_ username: String, handler: @escaping FreesoundHandler)
Parameters
username
The user whose information to retrieve.
handler
A closure that handles the response data, an optional dictionary with the following keys:
- url: URL for the user’s Freesound website profile.
- username: The user’s username.
- about: The user’s profile’s
about
text. - homepage: URI for the user’s homepage (if listed).
- avatar: Dictionary containing URIs for the user’s avatar (nil if not available). Fields are Small, Medium, and Large.
- date_joined: The date when the user joined Freesound.
- num_sounds: Number of sounds uploaded by the user.
- sounds: URI for a list of sounds by the user.
- num_packs: Number of packs created by the user.
- packs: URI for a list of packs by the user.
- num_posts: Number of forum posts by the user.
- num_comments: Number of comments made by the user on other users’ sounds.
- bookmark_categories: URI for a list of bookmark categories made by the user.
-
Retrieves a user’s sounds.
Declaration
Swift
static public func getUserSounds(_ username: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
username
The user whose sounds to retrieve.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the sounds on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Retrieves a user’s packs.
Declaration
Swift
static public func getUserPacks(_ username: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
username
The user whose packs to retrieve.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in packs-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The pack ID.
- url: The URI for the pack.
- description: The description for the pack (if available).
- created: Date the pack was made.
- name: The name of the pack.
- username: Username of the pack owner.
- num_sounds: Number of sounds in the current pack.
- sounds: URI for list of sounds in the current pack.
- num_downloads: Number of times the current pack has been downloaded.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Retrieves a user’s sound bookmark categories.
Declaration
Swift
static public func getUserBookmarkCategories(_ username: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
username
User whose bookmark categories to retrieve.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in bookmark-categories-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- url: URI for the bookmark category.
- name: Name of the bookmark category.
- num_sounds: Number of sounds in the bookmark category.
- sounds: URI for list of sounds in the current bookmark category.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Retrieves sounds from a user’s sound bookmark category.
Declaration
Swift
static public func getUserBookmarkCategorySounds(_ username: String, categoryID: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
username
User whose bookmark category to retrieve sounds from.
categoryID
ID of the bookmark category from which to retrieve sounds.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Retrieves a pack instance.
Declaration
Swift
static public func getPackInstance(_ packID: String, handler: @escaping FreesoundHandler)
Parameters
packID
ID of the pack to get information about.
handler
A closure that handles the response data, an optional dictionary containing the following keys:
- id: The pack ID.
- url: The URI for the pack.
- description: The description for the pack (if available).
- created: The date the pack was made.
- name: The name of the pack.
- username: Username of the pack owner.
- num_sounds: Number of sounds in the current pack.
- sounds: URI for list of sounds in the current pack.
- num_downloads: Number of times the current pack has been downloaded.
-
Retrieves a pack’s sounds.
Declaration
Swift
static public func getPackSounds(_ packID: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
packID
ID of the pack to retrieve sounds from.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Downloads a pack’s sounds.
Declaration
Swift
static public func downloadPack(_ packID: String, to url: URL, handler: @escaping (URL?) -> ())
Parameters
packID
ID of the pack to download sounds from.
url
URL to download the pakc .zip file to.
handler
A closure that takes an optional URL (nil if the file didn’t download correctly).
-
Retrieves information about the logged-in user.
Declaration
Swift
static public func getMe(handler: @escaping FreesoundHandler)
Parameters
handler
A closure that handles the response data, an optional dictionary with the following keys:
- url: URL for the user’s Freesound website profile.
- username: The user’s username.
- about: The user’s profile’s
about
text. - homepage: URI for the user’s homepage (if listed).
- avatar: Dictionary containing URIs for the user’s avatar (nil if not available). Fields are Small, Medium, and Large.
- date_joined: The date when the user joined Freesound.
- num_sounds: Number of sounds uploaded by the user.
- sounds: URI for a list of sounds by the user.
- num_packs: Number of packs created by the user.
- packs: URI for a list of packs by the user.
- num_posts: Number of forum posts by the user.
- num_comments: Number of comments made by the user on other users’ sounds.
- bookmark_categories: URI for a list of bookmark categories made by the user.
- email: Email ID of the logged in user.
- unique_id: A unique ID associated with the user.
-
Retrieves sound analysis data.
Declaration
Swift
static public func getAnalysis(_ id: String, descriptors: [FreesoundDescriptor], normalized: Bool = false, handler: @escaping FreesoundHandler)
Parameters
id
ID of sound to be analyzed.
descriptors
Analysis descriptors to retrieve for the sound file.
normalized
A boolean value that sets whether to retrieve normalized or absolute values for specified content descriptors.
handler
A closure that handles response data, an optional dictionary that contains keys corresponding to content descriptors.
-
Retrieves information about sounds similar to ID specified.
Declaration
Swift
static public func getSimilarSounds(_ id: String, page: Int? = nil, pageSize: Int? = nil, handler: @escaping FreesoundHandler)
Parameters
id
The ID of the sound to get sounds that are similar to.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- id: The sound ID.
- name: The sound name.
- tags: The sound’s tags.
- username: The user who uploaded the current sound.
- license: The license provided.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).
-
Retrieves comments made on a sound.
Declaration
Swift
static public func getComments(_ id: String, handler: @escaping FreesoundHandler)
Parameters
id
The ID of the sound to get comments made on.
page
The page number of results to retrieve (nil by default).
pageSize
The size of each returned page (nil by default, given in sounds-per-page).
handler
A closure that handles the response data, an optional dictionary with the following keys:
- count: The number of results on the page.
- next: A link to the next page of results (nil if none).
- results: An array of dictionaries representing information about the packs on the current page.
- Each of these dictionaries contains, by default, the following keys:
- username: Username of the comment author.
- comment: The comment itself.
- created: Date the comment was made.
- Each of these dictionaries contains, by default, the following keys:
- previous: A link to the previous page of results (nil if none).


| Author | Matthew Schinkel - borntechi.com, copyright © 2009, all rights reserved. |
| Adapted-by | |
| Compiler | >=2.4k |
Library for GLCD touch controller & A/D device ad7843. used with GLCD's such as stm032qvt-003
http://www.divshare.com/download/11463401-4a9
No dependency found
var bit*3 touch_register at _touch_settings : 4
const bit*3 TOUCH_REG_IN3 = 0b010
const TOUCH_12_BIT = 0
const bit*3 TOUCH_REG_IN4 = 0b110
const TOUCH_INTERRUPT_ENABLE = 0
var bit touch_ser_dfr at _touch_settings : 2
const TOUCH_INTERRUPT_DISABLED = 1
var bit touch_pd0 at _touch_settings : 0
const bit*3 TOUCH_REG_Y = 0b001
var byte _touch_settings
const TOUCH_8_BIT = 1
const TOUCH_AD_SINGLE_ENDED = 1
var bit touch_mode at _touch_settings : 3
var bit touch_pd1 at _touch_settings : 1
const TOUCH_LOW_POWER = 0
const TOUCH_AD_DIFFERENTIAL = 0
var bit touch_start_bit at _touch_settings : 7
const bit*3 TOUCH_REG_X = 0b101
const TOUCH_HIGH_POWER = 1
var bit*3 touch_register at _touch_settings : 4
register select bits
const bit*3 TOUCH_REG_IN3 = 0b010
read analog input IN3
const TOUCH_12_BIT = 0
modes
const bit*3 TOUCH_REG_IN4 = 0b110
read analog input IN4
const TOUCH_INTERRUPT_ENABLE = 0
interrupt setting constants
var bit touch_ser_dfr at _touch_settings : 2
A/D reference mode
const TOUCH_INTERRUPT_DISABLED = 1
No documentation found
var bit touch_pd0 at _touch_settings : 0
interrupt enable bit
const bit*3 TOUCH_REG_Y = 0b001
read y
var byte _touch_settings
command byte
const TOUCH_8_BIT = 1
No documentation found
const TOUCH_AD_SINGLE_ENDED = 1
No documentation found
var bit touch_mode at _touch_settings : 3
resolution mode. 0 = 12bit, 1 = 8bit
var bit touch_pd1 at _touch_settings : 1
power management bit
const TOUCH_LOW_POWER = 0
power setting constants
const TOUCH_AD_DIFFERENTIAL = 0
A/D reference modes
var bit touch_start_bit at _touch_settings : 7
register write start bit
const bit*3 TOUCH_REG_X = 0b101
registers
const TOUCH_HIGH_POWER = 1
No documentation found
touch_init()
Initiate touch controller
touch_read_xy_8_bit(byte in out x, byte in out y)
Read x,y coordinates of touch screen with 8 bit resolution. Should be polled. If x near equal to 0, and y near equal to 127, then there is no activity.
| 18f4620 | 18f4620_glcd_touch_stm032qvt_003.jal |
| 18f46k22 | 18f46k22_glcd_touch_stm032qvt_003.jal |


Cute
A simple way to create, process, and observe Queues in Swift
Ah, queing. Everything will eventually need it. While iOS offers NSOperation
and NSOperationQueue
, in my experience they are messy, confusing, difficult to use, and not very portable. Cute
attempts to solve that problem by implementing a basic, thread-safe and type-safe Queue structure, complete with type-safe processing, observing, and persistence. Cute
is composable, portable, and easy to use.
Table of Contents
Installation
First thing first, you need to install
it. You have 2 options: Carthage
and Good Ol' Clone 'n Build
.
Carthage
Add the following to your Cartfile
github
https://github.ehealthinnovation.org/PHIT/Cute.git
~> 0.1Do a
carthage update --platform iOS --cache-builds
Install the framework as described in building for iOS, tvOS, or watchOS
Build your first queue!
Clone n’ Build
git clone
this repo- Open the
Cute.xcodeproj
and build it.
Using Cute
Cute attempts to make things as simple as possible for queing and processing jobs. It attempts to make no assumptions about how you use queues, including whether or not you wish to process the queues automagically.
JobQueues and QueueJobs
Well, the naming sucks, but here’s what they are:
QueueJob
: A protocol which defines what a job is.QueueJob
defines 4 fields:id: String
: The unique id of a given job.createdDate: Date
: The Date the job was createddata: Data?
: The optional data contained in this job which will be used by a processoraction: String
: Theaction
for this job, in the situation where a processor may need to do one of multiple things when processing a job.action
is domain specific, and can be whatever you need it to be.
JobQueue<Job: QueueJob>
: A generic Queue which (optionally) processes aQueueJob
.JobQueue
s are basic Queue structures (first in, first out) with a typical Queue interfaces:add(_: [Job])
: addes an array of jobs to the queueremove() -> Job
: Removes the next job in the queue and returns itpeek() -> Job
: Returns the next job in the queue without removing it.count: Int
: Returns the number of jobs in the queue.
Cute.JobQueue
s provide additional APIs:cancel(id: String)
: Removes a job from the queue with the matchingid
retry(_: Job)
: Adds the job at the front of the queue so it’s next up for processing. This is typically used by aRetryStrategy
, which we’ll get to later.start()
: If the queue has been assigned aJobProcessor
, then the queue will start feeding queued jobs to the processor.stop()
: The inverse ofstart
, in that the queue will stop feeding queued jobs to the processorobserve(_: @escaping (JobQueue<Job>, [Job], JobQueueEvent) -> Void) -> JobQueueNotificationToken<Job>
: Provides a means of observing activity in the queue.
Creating a QueueJob
QueueJob
is a simple protocol to which anything can be conformed. In my experience, conforming to a struct
is the most convenient and, likely, the more swifty way of doing things. Because Swift 4 allows you to typealias existing structs/classes, and furthermore allows you to add extensions to those typealiases, it’s easiest to create a base
QueueJob
for your project. You can use the following as a template:
import Foundation
import Cute
struct CuteJob: QueueJob {
private(set) var id: String = UUID().uuidString
private(set) var createdDate = Date()
var data: Data?
var action: String = ""
}
With the above base
QueueJob
, we can easily create other types
of jobs. For example, if we wanted to define a QueueJob
used for uploading a FHIR Observation to a server, we could do the following:
import Foundation
import FireKit
enum UploadAction: String {
case create, update, delete
}
typealias ObservationUploadJob = CuteJob
extension ObservationUploadJob {
var uploadAction: UploadAction? {
return UploadAction(rawValue: action)
}
init(_ action: UploadAction, _ observation: Observation) throws {
self.action = action.rawValue
self.data = try JSONEncoder().encode(observation)
}
}
We can now create an ObservationUploadJob
by simply doing the following:
import Foundation
import FireKit
let observation = Observation()
observation.valueString = "Above Threshold"
observation.subject = Reference(Patient.self, id: "\(123456)")
let job = try? ObservationUploadJob(.create, observation)
We now have a QueueJob
of type ObservationUploadJob
, complete with serialized observation data and an action specific to this domain. This job can now be submitted to any JobQueue
which allows ObservationUploadJob
s.
Creating a JobQueue
With the ObservationUploadJob
defined, how do we create the JobQueue
that will accept that type of job? Easy - just do the following:
import Foundation
import Cute
let observationUploadQueue = JobQueue(handling: ObservationUploadJob.self,
name: "Observation Upload Queue")
That’s it. We now have a JobQueue of type JobQueue<ObservationUploadJob>
that will only accept jobs of that defined type. As such, we can submit our job to the queue by calling the add(_: [ObservationUploadJob])
method on the queue:
observationUploadQueue.add([job])
Creating a basic JobQueue
like the one above creates an in-memory only JobQueue. This means as soon as the queue goes out of scope, any jobs contained in the Queue will be lost. This might be okay in some use cases, but you may want to persist those jobs between scope or app-cycles. For that we turn to JobPersister
s.
Persisting QueueJobs
You can persist jobs in a JobQueue by assigning that JobQueue a JobPersister<JobType: QueueJob>
, a protocol with an associatedtype
. There are 4 functions defined on a JobPersister
:
persist(_: [JobType]) throws
: Persists the given jobs to… somewhere!delete(_: JobType) throws
: Deletes the job’s persistent representationload() throws -> [JobType]
: Loads and returns all jobs from their persistent representationclear(completion: ((Error?) -> Void)?)
: Clear all persisted jobs
If a JobQueue
is provided a JobPersister
, then the JobQueue
will attempt to persist
every added job, while also delete
ing every removed
job. Furthermore, if a JobQueue is initialized with a JobPersister
, the JobQueue
will atttempt to load
all jobs from the persister and add
the returned jobs to itself.
FileBasedPersister
Cute
provides a single JobPersister
out of the box: The FileBasedPersister
. The FileBasedPersister
persists jobs to the local device’s file system. Specifically, it will persist the jobs in the device’s Application Support
directory at Application Support/Cute/Queues/[Queue Name]
.
So if we wanted the queue we created earlier to persist its jobs, we can either create and assign it our own JobPersister
(if we want to persist the job somewhere other than the local FileSystem), or simply create an instance of FileBasedPersister
and assign it.
import Foundation
import Cute
let name = "Observation Upload Queue"
let observationUploadQueue = try JobQueue(handling: ObservationUploadJob.self,
name: name)
let persister = FileBasedPersister(handling: ObservationUploadJob.self,
queueName: name)
// Note: We need to type-erase using `AnyJobPersister` because you can't store
// protocols with associated types as parameters or properties.
observationUploadQueue.persister = AnyJobPersister(persister)
Our observationUploadQueue
will now persist any added, removed, or cancelled jobs to the device’s file system at `Application Support/Cute/Queues/Observation-Upload-Queue".
If we want our observationUploadQueue
to load jobs and add them on init
, we would simply pass the persister at the time of initialization:
import Foundation
import Cute
let name = "Observation Upload Queue"
let persister = FileBasedPersister(handling: ObservationUploadJob.self,
queueName: name)
let observationUploadQueue = try JobQueue(handling: ObservationUploadJob.self,
name: name,
persister: persister)
Processing a JobQueue
By default JobQueues are in-memory only queues which don’t actually do any processing. They simply maintain a First-In-First-Out data buffer which must be manually maintained. This can be useful in, say, a function which requires short controlled processing, but for background processing it stinks. Enter the JobProcessor<JobType: QueueJob>
.
public protocol JobProcessor: class {
associatedtype JobType: QueueJob
func processJob(_ job: JobType, completion: @escaping ((JobType, Error?) -> Void))
}
JobProcessor<JobType: QueueJob>
is a protocol with an associatedtype of JobType
, which must conform to the QueueJob
protocol (just like JobQueue
s and JobPersister
s). The protocol has a single function, processJob(_: JobType, completion: @escaping ((JobType, Error?) -> Void))
. This function receives a job, does something with the job, and then calls the completion block. If the job failed to process, we call the completion with the job that was received, along with the generated Error
. Otherwise, if the processing was successful, we simply call the completion block with job that was successfully processed.
To continue our Observation Upload example, we could create a JobProcessor
with the following (somewhat pseudo) code:
class ObservationUploadJobProcessor: JobProcessor {
typealias JobType = ObservationUploadJob
// some server which knows how to add/update/delete, and returns a promise to do so
var server: ObservationServer?
convenience init(server: ObservationServer) {
self.init()
self.server = server
}
func processJob(_ job: ObservationUploadJob, completion: @escaping ((ObservationUploadJob, Error?) -> Void)) {
guard let data = job.data else {
fatalError("No data was found in Job, and thus we cannot upload the Observation to the server. Removing job from queue.")
}
guard let action = job.uploadAction else {
fatalError("Could not determine the job's upload action `\(job.action)`. This seems like a bug.")
}
var observation: Observation!
do {
observation = try JSONDecoder().decode(Observation.self, from: data)
} catch let error {
fatalError("Failed to deserialize the FHIR Observation from the ObservationUploadJob. This seems like a bug: \(error)")
}
firstly {
serverAction(action, forObservation: observation)
}.done { Observations in
completion(job, nil)
}.catch { error in
completion(job, error)
}
}
func serverAction(_ action: ObservationUploadAction, forObservation Observation: Observation) -> Promise<[Observation]> {
guard let server = server else {
fatalError("No ObservationServer was set on the ObservationUploadQueueProcesser prior to it being started. This is a bug.")
}
switch action {
case .create: return server.create(Observations: [Observation])
case .update: return server.update(Observations: [Observation])
case .delete: return server.delete(Observations: [Observation])
}
}
}
The above processor attempts to invoke the appropriate function on some mythical ObservationServer
, which notifies the queue of whether or not it was successful. That’s it!
You can assign a JobQueue
any JobProcessor
which processes the same type of job as the JobQueue
.
import Foundation
import Cute
let name = "Observation Upload Queue"
let persister = FileBasedPersister(handling: ObservationUploadJob.self,
queueName: name)
let observationUploadQueue = try JobQueue(handling: ObservationUploadJob.self,
name: name,
persister: persister)
observationUploadQueue.processor = AnyJobProcessor(ObservationUploadJobProcessor(server: MyObservationServer())
However, recall that JobQueue
have start
and stop
methods. These methods control whether or not a JobQueue
will forward its jobs to the assigned JobProcessor.
...
observationUploadQueue.processor = AnyJobProcessor(ObservationUploadJobProcessor(server: MyObservationServer())
observationUploadQueue.start()
By calling start
above, we tell our ObservationUploadQueue to start forwarding jobs to the assigned JobProcessor
. The queue will continue to send jobs to the processor until the queue is empty, after which any new jobs that were added to the queue will also be forwarded to the processor.
Conversely, we can tell the queue to stop sending jobs to its assigned processor by calling the queue’s stop
method.
...
observationUploadQueue.stop()
When called, the stop
function will waiting until the current processing job is completed, afterwhich no more jobs will be sent to the assigned processor until start
is called.
The start()
and stop()
functions are important, and can be useful if we need to re-try jobs which failed to process. Speaking of which…
Job Retry Strategies
When a JobQueue
forwards a job to a JobProcessor
for processing, the JobQueue
will first remove()
that job from the queue. Any jobs that fail to process, by default, will not be re-added to the queue. However, JobQueue
s do provide a means of re-trying a failed job using a JobRetryStrategy<QueueJob>
.
“`swift 4 public protocol JobRetryStrategy {
/// Instructs how to retry the failed `job` on the provided `queue`
///
/// - Parameters:
/// - job: The QueueJob which failed to process
/// - queue: The JobQueue on which the job failed.
func retry<JobType: QueueJob>(job: JobType, failedOnQueue queue: JobQueue<JobType>)
}
A `JobRetryStrategy<QueueJob>` is a simple protocol which defines a method, `retry<JobType: QueueJob>(job: JobType, failedOnQueue queue: JobQueue<JobType>)`. This method is provided the failed job, along with the JobQueue on which the job had failed processing.
You can create your own `JobRetryStrategy`to do whatever you want. By default, `Cute` provides 3 different retry strategies for you:
- `HalthRetryStrategy`
- `MaxRetryStrategy`
- `BackoffRetryStrategy`.
#### The HaltRetryStrategy
The `HaltRetryStrategy` is a bit of a misleading name. It doesn't actually retry at all. Rather, the `HaltRetryStrategy` simply stops the queue and then re-queues the failed job at the front of the queue. The queue must be manually restarted. In most circumstances it is unlikely you'd want to actually use the `HaltRetryStrategy` for any kind of background processing.
#### The MaxRetryStrategy
The `MaxRetryStrategy` will re-add the job to the front of the queue such that the queue will re-attempt to process the job again (remember, queues will always `remove` the next job in line, and pass that job to the job processor). The `MaxRetryStrategy` will re-queue the failed job up to a max-number of times. If the job still fails to process after the max number of attempts is reached, the strategy will not re-add the job to the queue and the job will be purged.
#### BackoffRetryStrategy
The `BackoffRetryStrategy` will progressively "back off" attempts of processing the job, starting at 1 second. If the job fails again, the strategy will try to process the job again in 2 seconds, then 4 second, then 8, and so on, until a max-backoff is reached (defaults to 1 hour, or 3600 seconds). The `BackoffRetryStrategy` will never purge the queue of a failed job.
The `BackoffRetryStrategy` accomplishes the above by performing the following steps:
1. Stop the queue
2. re-add the job to the front of the queue
3. Schedule a `Timer` to fire in X-seconds
4. When `Timer` fires, the strategy re-starts the queue
You can define a re-try strategy for a `JobQueue` by assigning it's `retryStrategy` property to an instance of anything that conforms to the `JobRetryStrategy` protocol.
```swift
observationUploadQueue.retryStrategy = BackoffRetryStrategy(maxBackoff: 60*60) // waits a max 1 hour
Observing JobQueues
A JobQueue
fires notifications to observers during key events. Specifically, observers receive notifications whenever a JobQueue
- adds a job
- removes a job
- cancels a job
- processes a job
- fails to process a job
An observer receives a notification by calling a JobQueue
‘s observe
function and passing it a block.
let token = observationUploadQueue.observe { queue, jobs, event in
switch event {
case .added:
print("\(jobs) were added to queue \(queue)")
case .removed:
print("\(jobs) were removed from queue \(queue)")
case .cancelled:
print("\(jobs) were cancelled in queue \(queue)")
case .processed:
print("\(jobs) successfully processed on queue \(queue)")
case .failedToProcess:
print("\(jobs) failed to process on queue \(queue)")
}
}
The observe
function returns a weak JobQueueNotificationToken
which must be strongly retained. As soon as the token goes out of scop,e the JobQueue
will stop sending notifications to that observer.


This is the first paragraph. And this is a new line in the first paragraph.
The second paragraph shows bold and a link.
Last modified: Fri, 27 Jul 2007 18:34:31 BST


Privacy Policy
When you use Walkmap, we will collect your location information. This information is used to show your trail for a period of time. Walkmap will NOT share your location information with anyone. When you click "Unbinding" button of main UI, Walkmap will stop to collect location information of you.
隐私政策
当您使用Walkmap时，我们会收集您的位置信息。该位置信息用来向您显示过去一段时间您的轨迹。Walkmap不会与任何人共享您的位置信息。当您点击主界面的"解绑"后，Walkmap将会停止收集您的位置信息。


|
omg
0.0.1
Open Machinery for Graphics
|
Interface for backgrounds. More...
Classes | |
| class | Background |
| class | Buffer |
| A buffer for 2D images. More... | |
| class | GradBilinearBackground |
| Gradient background based on bilinear interpolation. More... | |
| class | ImageBackground |
| class | ParseException |
| Parsing exception. More... | |
| class | Parser |
| An interface for scene parsers. More... | |
| class | RaytracerVisitor |
| Executes the main operations of the ray tracer as a visitor of a parsed scene. More... | |
| class | Scene |
| Represents a 3D scene. More... | |
| class | SceneNode |
| Represents a scene node that can be visited by a visitor. More... | |
| class | SolidBackground |
| class | Visitor |
| Visitor class for rayt scene descriptions. More... | |
| class | YAMLParser |
| A scene parser using YAML. More... | |
Typedefs | |
| using | Vec2 = std::tuple< float, float > |
| using | Point2 = std::tuple< float, float > |
| using | Vec3 = std::tuple< float, float, float > |
| using | Point3 = Vec3 |
| using | RGBColor = tao::VecF |
| template<int NChannels> | |
| using | PixelValue = std::array< unsigned char, NChannels > |
| template<int N> | |
| using | Size = std::array< float, N > |
Interface for backgrounds.
Solid background.
Image background.


PUBLICATION ETHICS
The publication of an article in a peer-reviewed journal is an essential building block in the
development of a coherent and respected network of knowledge. It is a direct reflection of the
quality of the work of the authors and the institutions that support them. Peer-reviewed articles
support and embody the scientific method.
Ethical standards for publication exist to ensure reliable & high-quality scientific research
publications, public trust in scientific findings, and that researchers receive credit for their work
& ideas.
Plagiarism:
All articles published by JIECE are committed to publishing only original material, i.e., material
that has neither been published elsewhere, nor is under review elsewhere. Manuscripts that are
found to have been plagiarized from a manuscript by other authors, whether published or
unpublished, will incur plagiarism penalty.
Duplicate Submission:
Manuscripts that are found to have been published elsewhere, or to be under review elsewhere,
will incur duplicate submission sanctions. If authors have used their own previously published
work, or work that is currently under review, as the basis for a submitted manuscript, they are
required to cite the previous work and indicate how their submitted manuscript offers novel
contributions beyond those of the previous work.
Improper Author Contribution or Attribution:
All listed authors must have made a significant scientific contribution to the research in the
manuscript and approved all its claims. It is important to list everyone who made a significant
scientific contribution, including students and laboratory technicians.