- NAME
- binary - Insert and extract fields from binary strings
- SYNOPSIS
- DESCRIPTION
- BINARY FORMAT
- a
- A
- b
- B
- H
- h
- c
- s
- S
- t
- i
- I
- n
- w
- W
- m
- f
- r
- R
- d
- q
- Q
- x
- X
- @
- BINARY SCAN
- a
- A
- b
- B
- H
- h
- c
- s
- S
- t
- i
- I
- n
- w
- W
- m
- f
- r
- R
- d
- q
- Q
- x
- X
- @
- PORTABILITY ISSUES
- EXAMPLES
- SEE ALSO
- KEYWORDS
binary - Insert and extract fields from binary strings
binary format formatString ?arg arg ...?
binary scan string formatString ?varName varName ...?
This command provides facilities for manipulating binary data. The
first form, binary format, creates a binary string from normal
Tcl values. For example, given the values 16 and 22, on a 32-bit
architecture, it might produce an 8-byte binary string consisting of
two 4-byte integers, one for each of the numbers. The second form of
the command, binary scan, does the opposite: it extracts data
from a binary string and returns it as ordinary Tcl string values.
The binary format command generates a binary string whose layout
is specified by the formatString and whose contents come from
the additional arguments. The resulting binary value is returned.
The formatString consists of a sequence of zero or more field
specifiers separated by zero or more spaces. Each field specifier is
a single type character followed by an optional flag character followed
by an optional numeric count.
Most field specifiers consume one argument to obtain the value to be
formatted. The type character specifies how the value is to be
formatted. The count typically indicates how many items of the
specified type are taken from the value. If present, the count
is a non-negative decimal integer or *, which normally indicates
that all of the items in the value are to be used. If the number of
arguments does not match the number of fields in the format string
that consume arguments, then an error is generated. The flag character
is ignored for for binary format.
Here is a small example to clarify the relation between the field
specifiers and the arguments:
binary format d3d {1.0 2.0 3.0 4.0} 0.1
The first argument is a list of four numbers, but because of the count
of 3 for the associated field specifier, only the first three will be
used. The second argument is associated with the second field
specifier. The resulting binary string contains the four numbers 1.0,
2.0, 3.0 and 0.1.
Each type-count pair moves an imaginary cursor through the binary
data, storing bytes at the current position and advancing the cursor
to just after the last byte stored. The cursor is initially at
position 0 at the beginning of the data. The type may be any one of
the following characters:
- a
-
Stores a byte string of length count in the output string.
Every character is taken as modulo 256 (i.e. the low byte of every
character is used, and the high byte discarded) so when storing
character strings not wholly expressible using the characters \u0000-\u00ff,
the encoding convertto command should be used first to change
the string into an external representation
if this truncation is not desired (i.e. if the characters are
not part of the ISO 8859-1 character set.)
If arg has fewer than count bytes, then additional zero
bytes are used to pad out the field. If arg is longer than the
specified length, the extra characters will be ignored. If
count is *, then all of the bytes in arg will be
formatted. If count is omitted, then one character will be
formatted. For example,
binary format a7a*a alpha bravo charlie
will return a string equivalent to alpha\000\000bravoc,
binary format a* [encoding convertto utf-8 \u20ac]
will return a string equivalent to \342\202\254 (which is the
UTF-8 byte sequence for a Euro-currency character) and
binary format a* [encoding convertto iso8859-15 \u20ac]
will return a string equivalent to \244 (which is the ISO
8859-15 byte sequence for a Euro-currency character). Contrast these
last two with:
binary format a* \u20ac
which returns a string equivalent to \254 (i.e. \xac) by
truncating the high-bits of the character, and which is probably not
what is desired.
- A
-
This form is the same as a except that spaces are used for
padding instead of nulls. For example,
binary format A6A*A alpha bravo charlie
will return alpha bravoc.
- b
-
Stores a string of count binary digits in low-to-high order
within each byte in the output string. Arg must contain a
sequence of 1 and 0 characters. The resulting bytes are
emitted in first to last order with the bits being formatted in
low-to-high order within each byte. If arg has fewer than
count digits, then zeros will be used for the remaining bits.
If arg has more than the specified number of digits, the extra
digits will be ignored. If count is *, then all of the
digits in arg will be formatted. If count is omitted,
then one digit will be formatted. If the number of bits formatted
does not end at a byte boundary, the remaining bits of the last byte
will be zeros. For example,
binary format b5b* 11100<PHONE_NUMBER>10
will return a string equivalent to \x07\x87\x05.
- B
-
This form is the same as b except that the bits are stored in
high-to-low order within each byte. For example,
binary format B5B* 11100<PHONE_NUMBER>10
will return a string equivalent to \xe0\xe1\xa0.
- H
-
Stores a string of count hexadecimal digits in high-to-low
within each byte in the output string. Arg must contain a
sequence of characters in the set
“0123456789abcdefABCDEF”.
The resulting bytes are emitted in first to last order with the hex digits
being formatted in high-to-low order within each byte. If arg
has fewer than count digits, then zeros will be used for the
remaining digits. If arg has more than the specified number of
digits, the extra digits will be ignored. If count is
*, then all of the digits in arg will be formatted. If
count is omitted, then one digit will be formatted. If the
number of digits formatted does not end at a byte boundary, the
remaining bits of the last byte will be zeros. For example,
binary format H3H*H2 ab DEF 987
will return a string equivalent to \xab\x00\xde\xf0\x98.
- h
-
This form is the same as H except that the digits are stored in
low-to-high order within each byte. This is seldom required. For example,
binary format h3h*h2 AB def 987
will return a string equivalent to \xba\x00\xed\x0f\x89.
- c
-
Stores one or more 8-bit integer values in the output string. If no
count is specified, then arg must consist of an integer
value. If count is specified, arg must consist of a list
containing at least that many integers. The low-order 8 bits of each integer
are stored as a one-byte value at the cursor position. If count
is *, then all of the integers in the list are formatted. If the
number of elements in the list is greater
than count, then the extra elements are ignored. For example,
binary format c3cc* {3 -3 128 1} 260 {2 5}
will return a string equivalent to
\x03\xfd\x80\x04\x02\x05, whereas
binary format c {2 5}
will generate an error.
- s
-
This form is the same as c except that it stores one or more
16-bit integers in little-endian byte order in the output string. The
low-order 16-bits of each integer are stored as a two-byte value at
the cursor position with the least significant byte stored first. For
example,
binary format s3 {3 -3 258 1}
will return a string equivalent to
\x03\x00\xfd\xff\x02\x01.
- S
-
This form is the same as s except that it stores one or more
16-bit integers in big-endian byte order in the output string. For
example,
binary format S3 {3 -3 258 1}
will return a string equivalent to
\x00\x03\xff\xfd\x01\x02.
- t
-
This form (mnemonically tiny) is the same as s and S
except that it stores the 16-bit integers in the output string in the
native byte order of the machine where the Tcl script is running.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- i
-
This form is the same as c except that it stores one or more
32-bit integers in little-endian byte order in the output string. The
low-order 32-bits of each integer are stored as a four-byte value at
the cursor position with the least significant byte stored first. For
example,
binary format i3 {3 -3 65536 1}
will return a string equivalent to
\x03\x00\x00\x00\xfd\xff\xff\xff\x00\x00\x01\x00
- I
-
This form is the same as i except that it stores one or more one
or more 32-bit integers in big-endian byte order in the output string.
For example,
binary format I3 {3 -3 65536 1}
will return a string equivalent to
\x00\x00\x00\x03\xff\xff\xff\xfd\x00\x01\x00\x00
- n
-
This form (mnemonically number or normal) is the same as
i and I except that it stores the 32-bit integers in the
output string in the native byte order of the machine where the Tcl
script is running.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- w
-
This form is the same as c except that it stores one or more
64-bit integers in little-endian byte order in the output string. The
low-order 64-bits of each integer are stored as an eight-byte value at
the cursor position with the least significant byte stored first. For
example,
binary format w<PHONE_NUMBER>327718216
will return the string HelloTcl
- W
-
This form is the same as w except that it stores one or more one
or more 64-bit integers in big-endian byte order in the output string.
For example,
binary format Wc<PHONE_NUMBER>960341345 110
will return the string BigEndian
- m
-
This form (mnemonically the mirror of w) is the same as w
and W except that it stores the 64-bit integers in the output
string in the native byte order of the machine where the Tcl script is
running.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- f
-
This form is the same as c except that it stores one or more one
or more single-precision floating point numbers in the machine's native
representation in the output string. This representation is not
portable across architectures, so it should not be used to communicate
floating point numbers across the network. The size of a floating
point number may vary across architectures, so the number of bytes
that are generated may vary. If the value overflows the
machine's native representation, then the value of FLT_MAX
as defined by the system will be used instead. Because Tcl uses
double-precision floating point numbers internally, there may be some
loss of precision in the conversion to single-precision. For example,
on a Windows system running on an Intel Pentium processor,
binary format f2 {1.6 3.4}
will return a string equivalent to
\xcd\xcc\xcc\x3f\x9a\x99\x59\x40.
- r
-
This form (mnemonically real) is the same as f except that
it stores the single-precision floating point numbers in little-endian
order. This conversion only produces meaningful output when used on
machines which use the IEEE floating point representation (very
common, but not universal.)
- R
-
This form is the same as r except that it stores the
single-precision floating point numbers in big-endian order.
- d
-
This form is the same as f except that it stores one or more one
or more double-precision floating point numbers in the machine's native
representation in the output string. For example, on a
Windows system running on an Intel Pentium processor,
binary format d1 {1.6}
will return a string equivalent to
\x9a\x99\x99\x99\x99\x99\xf9\x3f.
- q
-
This form (mnemonically the mirror of d) is the same as d
except that it stores the double-precision floating point numbers in
little-endian order. This conversion only produces meaningful output
when used on machines which use the IEEE floating point representation
(very common, but not universal.)
- Q
-
This form is the same as q except that it stores the
double-precision floating point numbers in big-endian order.
- x
-
Stores count null bytes in the output string. If count is
not specified, stores one null byte. If count is *,
generates an error. This type does not consume an argument. For
example,
binary format a3xa3x2a3 abc def ghi
will return a string equivalent to abc\000def\000\000ghi.
- X
-
Moves the cursor back count bytes in the output string. If
count is * or is larger than the current cursor position,
then the cursor is positioned at location 0 so that the next byte
stored will be the first byte in the result string. If count is
omitted then the cursor is moved back one byte. This type does not
consume an argument. For example,
binary format a3X*a3X2a3 abc def ghi
will return dghi.
- @
-
Moves the cursor to the absolute location in the output string
specified by count. Position 0 refers to the first byte in the
output string. If count refers to a position beyond the last
byte stored so far, then null bytes will be placed in the uninitialized
locations and the cursor will be placed at the specified location. If
count is *, then the cursor is moved to the current end of
the output string. If count is omitted, then an error will be
generated. This type does not consume an argument. For example,
binary format a5@2a1@*a3@10a1 abcde f ghi j
will return abfdeghi\000\000j.
The binary scan command parses fields from a binary string,
returning the number of conversions performed. String gives the
input bytes to be parsed (one byte per character, and characters not
representable as a byte have their high bits chopped)
and formatString indicates how to parse it.
Each varName gives the name of a variable; when a field is
scanned from string the result is assigned to the corresponding
variable.
As with binary format, the formatString consists of a
sequence of zero or more field specifiers separated by zero or more
spaces. Each field specifier is a single type character followed by
an optional flag character followed by an optional numeric count.
Most field specifiers consume one
argument to obtain the variable into which the scanned values should
be placed. The type character specifies how the binary data is to be
interpreted. The count typically indicates how many items of
the specified type are taken from the data. If present, the
count is a non-negative decimal integer or *, which
normally indicates that all of the remaining items in the data are to
be used. If there are not enough bytes left after the current cursor
position to satisfy the current field specifier, then the
corresponding variable is left untouched and binary scan returns
immediately with the number of variables that were set. If there are
not enough arguments for all of the fields in the format string that
consume arguments, then an error is generated. The flag character
“u”
may be given to cause some types to be read as unsigned values. The flag
is accepted for all field types but is ignored for non-integer fields.
A similar example as with binary format should explain the
relation between field specifiers and arguments in case of the binary
scan subcommand:
binary scan $bytes s3s first second
This command (provided the binary string in the variable bytes
is long enough) assigns a list of three integers to the variable
first and assigns a single value to the variable second.
If bytes contains fewer than 8 bytes (i.e. four 2-byte
integers), no assignment to second will be made, and if
bytes contains fewer than 6 bytes (i.e. three 2-byte integers),
no assignment to first will be made. Hence:
puts [binary scan abcdefg s3s first second]
puts $first
puts $second
will print (assuming neither variable is set previously):
1
25185 25699 26213
can't read "second": no such variable
It is important to note that the c, s, and S
(and i and I on 64bit systems) will be scanned into
long data size values. In doing this, values that have their high
bit set (0x80 for chars, 0x8000 for shorts, 0x80000000 for ints),
will be sign extended. Thus the following will occur:
set signShort [binary format s1 0x8000]
binary scan $signShort s1 val; # val == 0xFFFF8000
If you require unsigned values you can include the
“u”
flag character following
the field type. For example, to read an unsigned short value:
set signShort [binary format s1 0x8000]
binary scan $signShort su1 val; # val == 0x00008000
Each type-count pair moves an imaginary cursor through the binary data,
reading bytes from the current position. The cursor is initially
at position 0 at the beginning of the data. The type may be any one of
the following characters:
- a
-
The data is a byte string of length count. If count
is *, then all of the remaining bytes in string will be
scanned into the variable. If count is omitted, then one
byte will be scanned.
All bytes scanned will be interpreted as being characters in the
range \u0000-\u00ff so the encoding convertfrom command will be
needed if the string is not a binary string or a string encoded in ISO
8859-1.
For example,
binary scan abcde\000fghi a6a10 var1 var2
will return 1 with the string equivalent to abcde\000
stored in var1 and var2 left unmodified, and
binary scan \342\202\254 a* var1
set var2 [encoding convertfrom utf-8 $var1]
will store a Euro-currency character in var2.
- A
-
This form is the same as a, except trailing blanks and nulls are stripped from
the scanned value before it is stored in the variable. For example,
binary scan "abc efghi \000" A* var1
will return 1 with abc efghi stored in var1.
- b
-
The data is turned into a string of count binary digits in
low-to-high order represented as a sequence of
“1”
and
“0”
characters. The data bytes are scanned in first to last order with
the bits being taken in low-to-high order within each byte. Any extra
bits in the last byte are ignored. If count is *, then
all of the remaining bits in string will be scanned. If
count is omitted, then one bit will be scanned. For example,
binary scan \x07\x87\x05 b5b* var1 var2
will return 2 with 11100 stored in var1 and
1110000110100000 stored in var2.
- B
-
This form is the same as b, except the bits are taken in
high-to-low order within each byte. For example,
binary scan \x70\x87\x05 B5B* var1 var2
will return 2 with 01110 stored in var1 and
1000011100000101 stored in var2.
- H
-
The data is turned into a string of count hexadecimal digits in
high-to-low order represented as a sequence of characters in the set
“0123456789abcdef”.
The data bytes are scanned in first to last
order with the hex digits being taken in high-to-low order within each
byte. Any extra bits in the last byte are ignored. If count is
*, then all of the remaining hex digits in string will be
scanned. If count is omitted, then one hex digit will be
scanned. For example,
binary scan \x07\xC6\x05\x1f\x34 H3H* var1 var2
will return 2 with 07c stored in var1 and
051f34 stored in var2.
- h
-
This form is the same as H, except the digits are taken in
reverse (low-to-high) order within each byte. For example,
binary scan \x07\x86\x05\x12\x34 h3h* var1 var2
will return 2 with 706 stored in var1 and
502143 stored in var2.
Note that most code that wishes to parse the hexadecimal digits from
multiple bytes in order should use the H format.
- c
-
The data is turned into count 8-bit signed integers and stored
in the corresponding variable as a list. If count is *,
then all of the remaining bytes in string will be scanned. If
count is omitted, then one 8-bit integer will be scanned. For
example,
binary scan \x07\x86\x05 c2c* var1 var2
will return 2 with 7 -122 stored in var1 and 5
stored in var2. Note that the integers returned are signed, but
they can be converted to unsigned 8-bit quantities using an expression
like:
set num [expr { $num & 0xff }]
- s
-
The data is interpreted as count 16-bit signed integers
represented in little-endian byte order. The integers are stored in
the corresponding variable as a list. If count is *, then
all of the remaining bytes in string will be scanned. If
count is omitted, then one 16-bit integer will be scanned. For
example,
binary scan \x05\x00\x07\x00\xf0\xff s2s* var1 var2
will return 2 with 5 7 stored in var1 and -16
stored in var2. Note that the integers returned are signed, but
they can be converted to unsigned 16-bit quantities using an expression
like:
set num [expr { $num & 0xffff }]
- S
-
This form is the same as s except that the data is interpreted
as count 16-bit signed integers represented in big-endian byte
order. For example,
binary scan \x00\x05\x00\x07\xff\xf0 S2S* var1 var2
will return 2 with 5 7 stored in var1 and -16
stored in var2.
- t
-
The data is interpreted as count 16-bit signed integers
represented in the native byte order of the machine running the Tcl
script. It is otherwise identical to s and S.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- i
-
The data is interpreted as count 32-bit signed integers
represented in little-endian byte order. The integers are stored in
the corresponding variable as a list. If count is *, then
all of the remaining bytes in string will be scanned. If
count is omitted, then one 32-bit integer will be scanned. For
example,
set str \x05\x00\x00\x00\x07\x00\x00\x00\xf0\xff\xff\xff
binary scan $str i2i* var1 var2
will return 2 with 5 7 stored in var1 and -16
stored in var2. Note that the integers returned are signed, but
they can be converted to unsigned 32-bit quantities using an expression
like:
set num [expr { $num & 0xffffffff }]
- I
-
This form is the same as I except that the data is interpreted
as count 32-bit signed integers represented in big-endian byte
order. For example,
set str \x00\x00\x00\x05\x00\x00\x00\x07\xff\xff\xff\xf0
binary scan $str I2I* var1 var2
will return 2 with 5 7 stored in var1 and -16
stored in var2.
- n
-
The data is interpreted as count 32-bit signed integers
represented in the native byte order of the machine running the Tcl
script. It is otherwise identical to i and I.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- w
-
The data is interpreted as count 64-bit signed integers
represented in little-endian byte order. The integers are stored in
the corresponding variable as a list. If count is *, then
all of the remaining bytes in string will be scanned. If
count is omitted, then one 64-bit integer will be scanned. For
example,
set str \x05\x00\x00\x00\x07\x00\x00\x00\xf0\xff\xff\xff
binary scan $str wi* var1 var2
will return 2 with<PHONE_NUMBER>7 stored in var1 and
-16 stored in var2. Note that the integers returned are
signed and cannot be represented by Tcl as unsigned values.
- W
-
This form is the same as w except that the data is interpreted
as count 64-bit signed integers represented in big-endian byte
order. For example,
set str \x00\x00\x00\x05\x00\x00\x00\x07\xff\xff\xff\xf0
binary scan $str WI* var1 var2
will return 2 with<PHONE_NUMBER>7 stored in var1 and -16
stored in var2.
- m
-
The data is interpreted as count 64-bit signed integers
represented in the native byte order of the machine running the Tcl
script. It is otherwise identical to w and W.
To determine what the native byte order of the machine is, refer to
the byteOrder element of the tcl_platform array.
- f
-
The data is interpreted as count single-precision floating point
numbers in the machine's native representation. The floating point
numbers are stored in the corresponding variable as a list. If
count is *, then all of the remaining bytes in
string will be scanned. If count is omitted, then one
single-precision floating point number will be scanned. The size of a
floating point number may vary across architectures, so the number of
bytes that are scanned may vary. If the data does not represent a
valid floating point number, the resulting value is undefined and
compiler dependent. For example, on a Windows system running on an
Intel Pentium processor,
binary scan \x3f\xcc\xcc\xcd f var1
will return 1 with 1.6000000238418579 stored in
var1.
- r
-
This form is the same as f except that the data is interpreted
as count single-precision floating point number in little-endian
order. This conversion is not portable to the minority of systems not
using IEEE floating point representations.
- R
-
This form is the same as f except that the data is interpreted
as count single-precision floating point number in big-endian
order. This conversion is not portable to the minority of systems not
using IEEE floating point representations.
- d
-
This form is the same as f except that the data is interpreted
as count double-precision floating point numbers in the
machine's native representation. For example, on a Windows system
running on an Intel Pentium processor,
binary scan \x9a\x99\x99\x99\x99\x99\xf9\x3f d var1
will return 1 with 1.6000000000000001
stored in var1.
- q
-
This form is the same as d except that the data is interpreted
as count double-precision floating point number in little-endian
order. This conversion is not portable to the minority of systems not
using IEEE floating point representations.
- Q
-
This form is the same as d except that the data is interpreted
as count double-precision floating point number in big-endian
order. This conversion is not portable to the minority of systems not
using IEEE floating point representations.
- x
-
Moves the cursor forward count bytes in string. If
count is * or is larger than the number of bytes after the
current cursor position, then the cursor is positioned after
the last byte in string. If count is omitted, then the
cursor is moved forward one byte. Note that this type does not
consume an argument. For example,
binary scan \x01\x02\x03\x04 x2H* var1
will return 1 with 0304 stored in var1.
- X
-
Moves the cursor back count bytes in string. If
count is * or is larger than the current cursor position,
then the cursor is positioned at location 0 so that the next byte
scanned will be the first byte in string. If count
is omitted then the cursor is moved back one byte. Note that this
type does not consume an argument. For example,
binary scan \x01\x02\x03\x04 c2XH* var1 var2
will return 2 with 1 2 stored in var1 and 020304
stored in var2.
- @
-
Moves the cursor to the absolute location in the data string specified
by count. Note that position 0 refers to the first byte in
string. If count refers to a position beyond the end of
string, then the cursor is positioned after the last byte. If
count is omitted, then an error will be generated. For example,
binary scan \x01\x02\x03\x04 c2@1H* var1 var2
will return 2 with 1 2 stored in var1 and 020304
stored in var2.
The r, R, q and Q conversions will only work
reliably for transferring data between computers which are all using
IEEE floating point representations. This is very common, but not
universal. To transfer floating-point numbers portably between all
architectures, use their textual representation (as produced by
format) instead.
This is a procedure to write a Tcl string to a binary-encoded channel as
UTF-8 data preceded by a length word:
proc writeString {channel string} {
set data [encoding convertto utf-8 $string]
puts -nonewline [binary format Ia* \
[string length $data] $data]
}
This procedure reads a string from a channel that was written by the
previously presented writeString procedure:
proc readString {channel} {
if {![binary scan [read $channel 4] I length]} {
error "missing length"
}
set data [read $channel $length]
return [encoding convertfrom utf-8 $data]
}
format, scan, tclvars
binary, format, scan
Copyright © 1995-1997 Roger E. Critchlow Jr.
Copyright © 1997 by Sun Microsystems, Inc.


The seed was planted ten years ago in Brazil. There was nothing better than sitting for a meal at my Grandmother’s kitchen table in Ubatuba, a small beach town located in the São Paulo state of Brazil.
The experience was legendary, everyone felt surrounded by the love and care that went into preparing the extraordinarily delicious food. Late each night after dinner my Vovo loved to eat acai, even though due to a lung condition she was not supposed to eat cold foods.
Our menu items are healthy and are fantastic in flavor.
acai contanins a lot vitamins and minerals. It is also a source of calcium, magnesium, zinc and copper.
All of our bases are vegan and non-dairy.


ManorCare Health Services is one of the nation's
leading providers of Alzheimer's care. We offer three
different care settings for people with Alzheimer's
disease and related memory disorders. Due to the
progressive nature of the disease, an individual's stage
of affliction often will determine the level and type of
care required. Family programs and support groups are a
key component of each program offered.
Alzheimer's Assisted Living
Our Arden Courts residential
facilities are designed exclusively for individuals in
the early to mid stages of Alzheimer's disease. Arden
Courts offers all the services normally associated with
an assisted living facility, however, the services have
been modified to take into account the unique needs of
the Alzheimer's resident. Special attention has been
given to physical building layout, safety and decor.
Modified activity and food service programs focus on
preferences, abilities and, most importantly, maintaining
independence for as long as possible. Of course, personal
care assistance is available 24 hours a day.
Alzheimer's Special Care
Unit (SCU)
Our Arcadia units (known
as Thalia in Florida) are secure, self-contained
units in our nursing and rehabilitation centers. Arcadia
is designed exclusively for people in the mid to late
stages of Alzheimer's disease or other related memory
disorders. Top experts in the field of dementia care have
helped us design every program detail from the decor
package to the activity, therapy and dietary programs.
These units are also appropriate for Alzheimer's
residents (at any stage) who may have a complex or
unstable medical condition.
Laurel Day Program
Available in our nursing and rehabilitation centers
that do not currently have an Alzheimer's Special Care
Unit. This structured daytime program provides supervised
therapeutic and recreational activities for Alzheimer's
residents in a safe and supportive environment.
|


DATEPART
FunctionReturns an integer representing the specified part of a date. Weekdays are numbered as: Monday = 1, Tuesday = 2, ..., Saturday = 6, Sunday = 7. Time zone offsets are represented as a positive or negative number of minutes (for instance, an offset of "-04:00" is represented as -240).
DATEPART(date-part, date)
year
, yy
, yyyy
quarter
, qq
, q
month
, mm
, m
dayofyear
, dy
, y
day
, dd
, d
week
, wk
, ww
weekday
, dw
hour
, hh
minute
, mi
, n
second
, ss
, s
millisecond
, ms
tzoffset
, tz
An integer representing the part of date that is specified by date-part.
PRINT DATEPART('month', '2016-07-23');
PRINT DATEPART('weekday', '2016-07-23');
DECLARE @x = DATEPART('dd', '2016-07-23');
@x
. PRINT DATEPART('tzoffset', '2016-07-23 12:00 -04:00');


Feel free to contact me with any questions that you may have. You can send me an email or message me on Facebook. I will try my hardest to answer all messages in a timely manner.
I look forward to hearing from you. Hopefully we can work together to make a difference!!


{% extends "devices/base.html" %} {% block content %}
Domus is a project for easily control simple devices.
Log in here or, if you don't have an account, register here


How to Hide a Nuclear Missile
After its Cuban Missile Crisis experience, Kremlin leaders wanted to ensure the USSR would never again be outgunned: one might call it ‘Cuban Missile Syndrome.’ The result were new missile systems, including schemes to cache nuclear warheads in the deep ocean and outer space. But before the strange logic of nuclear warfare could move off-world—and partially because the very effort placed too much strain on its economy—the Soviet Union collapsed. What follows is a history of these imagined futures of Cold War annihilation.
Throughout the 1970s, the Soviets launched a number of intimidating new weapons systems, from the SS-18 Satan missile to the Kiev, the Soviet Navy’s first aircraft carrier. Meanwhile, the Soviet Air Force launched the Tu-22M ’Backfire’ strategic bomber, which could deliver nuclear weapons over long distances. By 1974, meanwhile, Soviet engineers were working on a reusable spacecraft prototype that could be used to easily launch spy satellites—a program that resulted in the Buran craft, otherwise known as the Soviet space shuttle.
Many US defense analysts wondered what the Soviet Union was up to here. Was this an effort to achieve a military victory in the Cold War?
We now know that the Soviet Union were building massive missiles and rockets for a simple reason: they were good at it. It was their area of comparative advantage.
American missiles were smaller because their guidance systems were more sophisticated, ensuring greater accuracy and requiring a smaller warhead to hit the designated target area. Soviet missiles needed to be bigger so they were guaranteed to hit their target, and building big rockets with big warheads was something Soviet weapons designers could do well.
At the time, however, this was unclear to American defense analysts. To some of them it seemed that the Soviets were developing ‘silo busting’ missiles.
A number of those concerned about Soviet deployments joined the Committee on the Present Danger (CPD), a group dedicated to voicing concern about the survivability of the US nuclear force. These new Soviet missiles could potentially destroy US missiles in their silos in a devastating first strike, and thus win the cold war.
How so?
In this scenario, CPD analysts reasoned, the submarine leg of the nuclear triad was useless, because seaborne nuclear warheads were not big or accurate enough for any mission other than ‘city busting’. But ‘city busting’ was a terrible option: would a president order a retaliatory strike on Soviet cities knowing that to do so would invite the destruction of American cities? (The ‘Second Strike’ problem).
This conundrum encouraged new, imaginative thinking on how to ensure that American nuclear missile would survive a surprise Soviet attack.
In 1981, a number of Committee on the Present Danger members participated on an ‘MX Missile Basing Advisory Panel’ and wrote a detailed report 3 on how to better ensure the survival of American nuclear missiles.
In the report, the basing option that received the most attention was the ‘Multiple Protective Shelter (MPS)’ option. A new generation of American missiles, the MX missile, would move on road tracks between a number of silos. This would increase the number of targets for Soviet warheads, as Kremlin military planners would not know which silo a missile was in at any given moment. They would be forced to target them all, which would reduce the Soviet advantage in missile numbers.
There were also more extravagant suggestions, including a ’Small Submarine’ option. Four missiles would be housed in numerous diesel powered mini-subs, operating within 1000 miles of the continental United States. A new submarine fleet, the report conceded, was ‘a major undertaking’ and wouldn’t enter service until at least 1992-94: too far away. The program never got started.
Incidentally, the report might have mentioned ‘Project Sunrise’; a prototype system from the 1960s that envisaged missiles based on the seafloor. Now there’s a morbid name for a missile system.
Another particularly fantastic solution was the ‘Deep Underground’ option. The idea was to bury a missile deep inside a mountain, entirely sealed off from the outside world. Affixed to the top of the missile would be a ‘tunnel boring machine’ that would drill through the mountainside to reach a launch position. Sheltered by the mountain, the missile could survive a surprise attack and be ready for a retaliatory strike.
Unsurprisingly the costs of developing this ‘mole missile’ were enormous—or, more accurately, cost estimates were reported as being ’highly tentative’—and the design never left the drawing board.
Aside from cost, a problem with all these solutions was verification.
Arms control agreements rested on the ability of each side to check whether the other was cheating. Hiding missiles in mountains or in undersea platforms would have made verification impossible.
The ‘race track’ option lived on for several years because it did permit verification: at an agreed time, all the silos could be opened for Soviet satellites to check there weren’t more than the permitted number of missiles. (This was surely the best time for a surprise attack.)
Ultimately an even grander solution was devised: Ronald Reagan’s Star Wars program (the Strategic Defense Initiative). Rather than hiding or protecting American missiles to ensure a force capable of answering a surprise Soviet attack, a space-based platform would shoot down incoming missiles.
Of course, typical cold war paranoia ensured that some American analysts assumed the Soviets were well ahead in their own version of the Star Wars program.
An earlier version of this post originally appeared at Nick Blackbourn’s research blog.


The Indian Institute of Technology (IIT), Delhi will conduct the Graduate Aptitude Test in Engineering (GATE) 2020 - entrance exam for PSU jobs as well as admission to MTech courses across IITs and IISc - on February 1, 2, 8 and 9, 2020. Check here the mock question papers for one of the most opted for subject - computer science, prepared by Akhand Swaroop Pandit, founder and CEO, Catalyst Group - an online learning platform.


7 November 2005
The Ministry of Health in Indonesia has confirmed two additional cases of human infection with H5N1 avian influenza. The first newly confirmed case was a 19-year-old woman from Tangerang, near Jakarta, who developed symptoms on 19 October, was admitted to hospital on 26 October, and died on 28 October.
The second case is her 8-year-old brother. He developed symptoms on 25 October and remains hospitalized in good condition.
Field investigation has found evidence of sick and dying chickens in the residential area of the 8-year-old. His 19-year-old sister is known to have visited this area. Final results from an ongoing Ministry of Agriculture investigation are pending.
To date, Indonesia has confirmed 9 cases of human H5N1 infection of which 5 have been fatal.


Editing Views
Most documents come with at least one 3D view. The scene documents allow you to switch between single-view and quad-view mode, using the Toggle Views button in each view toolbar.
Using the Perspective menu in the toolbar (the eye icon) you can switch each view to either orthographic or perspective mode.
Camera controls and editing gizmos act differently in orthographic and perspective mode.
Render Modes
Render modes are used to visualize different aspects of the scene. They can be useful for debugging rendering issues, see potential performance hotspots, or easier edit a dark scene.
Most 3D viewports allow you to switch the rendering mode through a drop down menu.
Default
This mode renders the scene as it would appear in the final game.
Wireframe
In this mode the scene is rendered only as wireframe. Either monochrome or colored.
Diffuse Lit Only
This mode visualizes only the diffuse lighting contributions.
Specular Lit Only
This mode visualizes only the specular lighting contributions, including reflections.
Decal Count
Visualizes how many decals affect each pixel. Yellow and red areas indicate high decal overdraw and will affect performance negatively.
Light Count
Visualizes how many lights affect each pixel. Yellow and red areas have many contributing lights and will affect performance negatively.
Static vs Dynamic
This mode visualizes which objects in the scene are static
(green) and which ones are dynamic
(red). Dynamic objects have a per-frame performance cost, even if they don't move. This mode allows you to find objects that are unnecessarily set to be dynamic.
Texture Coordinates
There are two modes to visualize the UV0 and UV1 texture coordinates.
Normals and Tangents
There are multiple modes to visualize normals and tangents, per-vertex and per-pixel.
Diffuse Color
This mode only shows the diffuse color. It can be very handy for editing a scene that is otherwise very dark.
Diffuse Color Range Check
In Physically Based Rendering
(PBR) the diffuse color values should never be too dark or too bright, as both will not give the best possible results. This mode visualizes which areas may have non-optimal diffuse colors.
Emissive Color
This mode visualizes which objects use emissive colors.
Specular Color
Visualizes the specular color.
Ambient Occlusion
This mode shows ambient occlusion values. These come both from dedicated AO maps, as well as screen space ambient occlusion (SSAO).
Depth
Visualizes the depth of all objects. Note that depending on the near and far plane settings and the camera distance to the closest object, this mode may appear nearly entirely black or white. For this screenshot the far plane had to be adjusted.
Roughness
Visualizes the roughness of objects.


{% load static %}
This example is a quick exercise to illustrate how the default, static and fixed to top navbar work. It includes the responsive CSS and HTML, so it also adapts to your viewport and device.
To see the difference between static and fixed top navbars, just scroll.


--- title: "DESIGNING WITH FRESH FLOWERS" date: "2000-01-01 20:12:17 -06:00" categories: - adult subtitle: "" layout: "events" event-image: "fresh-flowers.jpg" event-dates: "Dec, Jan, Feb" event-location: "Online via Zoom" button-type: "register" tickets-link: "" registration-info: "Registration covers cost of flowers and container" instructor-info: "Scott Mower, Red Butte Garden Designer & Horticulturist" member-cost: "$43" public-cost: "$55" event-notes: "online" tickets-button: "" published: false ---
REGISTRATION REQUIRED
Zoom link will be sent to students via email the day before class.
Online class registration includes one free admission pass to Red Butte Garden.
Quarantine got you down? Climbing the walls because you’re going stir crazy? Needing a creative outlet? Well, this may be the perfect time to take an informal beginning floral design class, in the comfort of your own home. Each month students will learn a different style of design & themes, with a highlighted seasonal flower of the month. Learn how to turn a grocery store bouquet into a beautiful centerpiece. Designer, Scott Mower will share some helpful tips and the basics of floral design.
Registration covers material costs. Students will be able to pick up flowers and a container the day before class at Red Butte Garden (containers may be used again in following classes). Other items needed: Pruners and gloves (optional)
REGISTRATION REQUIRED


Before Change
state_name, net.shape[0].value / unroll_length, tf.float32)
else:
c = state_saver.state("%s_c" % state_name)
h = state_saver.state("%s_h" % state_name)
init_state = (c, h)
// Identities added for inputing state tensors externally.
c_ident = tf.identity(init_state[0], name="lstm_state_in_c")
After Change
// ConvLSTM layers.
batch_size = net.shape[0].value / unroll_length
with tf.variable_scope("LSTM", reuse=self._reuse_weights) as lstm_scope:
lstm_cell, init_state, _ = self.create_lstm_cell(
batch_size, (net.shape[1].value, net.shape[2].value), state_saver,
state_name)
net_seq = list(tf.split(net, unroll_length))


Hypergeometric Intersection distributions are a broad group of distributions that describe the probability of picking intersections when drawing independently from two (or more) urns containing variable numbers of balls belonging to the same n categories.
| Version: | 0.1-1 |
| Published: | 2013-07-24 |
| Author: | Alex T. Kalinka |
| Maintainer: | Alex T. Kalinka <alex.t.kalinka at gmail.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | yes |
| Citation: | hint citation info |
| CRAN checks: | hint results |
| Reference manual: | hint.pdf |
| Package source: | hint_0.1-1.tar.gz |
| Windows binaries: | r-devel: hint_0.1-1.zip, r-release: hint_0.1-1.zip, r-oldrel: hint_0.1-1.zip |
| OS X binaries: | r-release: hint_0.1-1.tgz, r-oldrel: hint_0.1-1.tgz |
| Old sources: | hint archive |
Please use the canonical form https://CRAN.R-project.org/package=hint to link to this page.


--- layout: doc title: Documentation ---
Coq Proof General is an instantiation of Proof General for the Coq proof assistant. It supports most of the generic features of Proof General.
| 11.1 Coq-specific commands | ||
| 11.2 Using the Coq project file | ||
| 11.3 Multiple File Support | ||
| 11.4 Editing multiple proofs | ||
| 11.5 User-loaded tactics | ||
| 11.6 Holes feature | ||
| 11.7 Proof-Tree Visualization |
Coq Proof General supplies the following key-bindings:
Inserts “intros ” and also introduces the name of the hypothesis proposed by coq on the current goal.
Show the goal (enter for the current goal, i <enter> for the ith goal).
Add the prefix C-u to see the answer with all pretty printing options temporarily disable (Set Printing All).
Prompts for “Check ” query arguments, the default input name is built from the identifier under the cursor.
Add the prefix C-u to see the answer with all pretty printing options temporarily disable (Set Printing All).
The same for a “Print ” query.
The same for a “About ” query.
The same for a “SearchAbout ” query (no C-u prefix).
The same for a Search “SearchIsos” (no C-u prefix).
Inserts “End <section-name>.” (this should work well with nested sections).
Before starting the Coq process, one need to set coqtop
options,
in particular the -I and -R command that set the directories to have in
the coq load path. You can use file variables (Using file variables) as it was recommended on previous versions of ProofGeneral
but there is now a better way. ProofGeneral knows how to extract this
information from the Coq project file if there is one. The Coq project
file must be named following variable ‘coq-project-filename’ (default:
_CoqProject
) and be on the root directory of your development.
It should contain something like:
-R foo bar -I foo2 -arg -foo3
The intial use of this file is to be given to the coq_makefile
tool to generate a Makefile (see Coq documentation for details). It is
parsed by ProofGeneral to guess the command line option. In this example
the command line built by Proofgeneral will be coqtop -foo3 -R foo
bar -I foo2
.
Remarque: -arg
must be followed by one and only one option
to pass to coqtop/coqc, use several -arg
to issue several
options. One per line (limitation of proofgeneral).
This is the recommended way of configuring coqtop options for coq compilation, CoqIde and Proofgeneral. Its main advantage is that it avoids duplicating informations between these three tools.
For specific (and rare) per file configuration one can still use file variables (Using file variables).
| 11.2.1 Changing the name of the coq project file | ||
| 11.2.2 Disabling the coq project file mechanism |
One can change the name of the project file by:
(setq coq-project-filename "myprojectfile")
or:
(setq (make-local-variable ’coq-project-filename) "myprojectfile")
If this is for a project, the best is probably to have a .dir-locals.el at the root of the project, as explained in Using file variables. This file should contain something like:
((coq-mode . ((coq-project-filename . "myprojectfile")))) |
or equivalently:
((coq-mode . ((eval . (progn (make-local-variable 'coq-project-filename) (setq coq-project-filename "myprojectfile")))))) |
If the variable ‘coq-use-project-file’ is nil, then Proofgeneral will not look at project file. therefore you can put this in your config file (.emacs) to disable the use of project file:
(setq coq-use-project-file nil) |
You can also use the .dir-locals.el as above to configure this setting on a per project basis.
Since version 4.1 Coq Proof General has multiple file support. It consists of the following points:
coqtop
when changing the active scripting bufferDifferent buffers may require different load path’ or different
sets of -I
options. Because Coq cannot undo changes in the
load path, Proof General is forced to restart coqtop
when
the active scripting buffer changes.
Locking those buffers on which the current active scripting
buffer depends. This is controlled by the user option
coq-lock-ancestors
,
Customizing Coq Multiple File Support and
Locking Ancestors.
Before a Require
command is processed it may be necessary
to save and compile some buffers. Because this feature
conflicts with existing customization habits, it is switched off
by default. When it is properly configured, one can freely switch
between different buffers. Proof General will compile the
necessary files whenever a Require
command is processed.
The compilation feature does currently not support ML modules.
There are actually two implementations of the Recompilation feature.
With synchronous compilation, coqdep and coqc are called synchronously for each Require command. Proof General is locked until the compilation finishes
With parallel compilation, coqdep and coqc are launched in the background and Proof General stays responsive during compilation. Up to ‘coq-max-background-compilation-jobs’ coqdep and coqc processes may run in parallel.
To enable the automatic compilation feature, you have to follow these points:
coq-compile-before-require
must be
turned on (menu Coq -> Settings -> Compile Before Require
).
coq-load-path
. -I
options in
coq-prog-name
or coq-prog-args
must be deleted.
coq-load-path
use strings "dir"
for -I
options and lists of two strings ("dir" "path")
for
-R "dir" -as "path"
(for more details see the
documentation of ‘coq-load-path’ or Customizing Coq Multiple File Support).
coq-compile-command
can be set to an external
compilation command. For standard dependency analysis with
coqdep
and compilation with coqc
the option
coq-compile-command
can be left empty. In this case Proof
General calls coqdep
and coqc
as needed.
Coq ->
Settings -> Compile Parallel In Background
). Configure
coq-max-background-compilation-jobs
if you want to limit
the number of parallel background jobs.
| 11.3.1 Automatic Compilation in Detail | ||
| 11.3.2 Locking Ancestors | ||
| 11.3.3 Customizing Coq Multiple File Support | ||
| 11.3.4 Current Limitations |
When coq-compile-before-require
is enabled, Proof
General looks for Require
commands in text that gets
asserted (i.e., in text that is moved from the editing region to
the queue region, Locked, queue, and editing regions). If
Proof General finds a Require
command, it checks the
dependencies and (re-)compiles files as necessary. The Require
command and the following text is only sent to Coq after the
compilation finished.
Declare ML Module
commands are currently not recognized.
Proof General uses coqdep
in order to translate the
qualified identifiers in Require
commands to coq library
file names. Therefore, in Coq version prior to 8.3pl2
,
Require Arith
works, while
Require Arith.Le
gives an error. The use of coqdep
is also the reason
why nonstandard load path elements must be configured in
coq-load-path
.
Once the library file name has been determined, its dependencies
must be checked and out-of-date files must be compiled. This can
either be done internally, by Proof General itself, or by an
external command. If coq-compile-command
is the empty
string, Proof General does dependency checking and compilation
itself. Otherwise the command in coq-compile-command
is
started as an external process after substituting certain keys,
Customizing Coq Multiple File Support.
For an external compilation command Proof General uses the
general compilation facilities of Emacs
(See (emacs)Compilation) with its own customization variables.
The compilation command must be customized in
coq-compile-command
and the flag
coq-confirm-external-compilation
(menu Coq ->
Settings -> Confirm External Compilation
)
determines
whether the user must confirm the compilation command. The output
of the compilation appears then in the *compilation*
buffer.
When Proof General compiles itself, output is only shown in case
of errors. It then appears in the buffer
*coq-compile-response*
. With internal as well as with external
compilation
one can use C-x `
(bound to next-error
,
See (emacs)Compilation Mode) to jump to error locations.
Note however, that coqdep
does not produce error messages
with location information, so C-x `
cannot work for errors
from coqdep
.
Proof General cannot know if some library files have been updated
outside of Proof General, therefore, it must perform the
dependency checking for each Require
command. If the
continuous confirmation of the external compilation commands
becomes tedious, disable
coq-confirm-external-compilation
(see menu Coq ->
Settings
).
When a Require
command causes a compilation of some files
one may wish to save some buffers to disk beforehand. The option
coq-compile-auto-save
controls how and which files are
saved. There are two orthogonal choices: One may wish to save all
or only the Coq source files, and, one may or may not want to
confirm the saving of each file.
With ‘coq-compile-parallel-in-background’ (menu Coq ->
Settings -> Compile Parallel In Background
) you can choose
between two implementations of internal compilation.
This is the stable version supported since Proof General version
4.1. This method starts coqdep and coqc processes one after each
other in synchronous subprocesses. Your Emacs session will be
locked until compilation finishes. Use C-g
to interrupt
compilation.
This is the new version added in Proof General version 4.3. It
runs up to coq-max-background-compilation-jobs
coqdep and
coqc jobs in parallel in asynchronous subprocesses (or uses all
your CPU cores if coq-max-background-compilation-jobs
equals 'all-cpus
). Your Emacs will stay responsive during
compilation. Use C-c C-c
or the tool bar icons for
interrupt or restart to interrupt compilation.
For the usual case, you have at most ‘coq-max-background-compilation-jobs’ parallel processes including your Proof General process. The usual case applies, when the Require commands are the first commands in the file. If you have other commands between two Require commands or before the first Require, then you may see Proof General and Coq running in addition to ‘coq-max-background-compilation-jobs’ compilation jobs.
Actually, even with this method, not everything runs asynchronously. To translate module identifiers from the Coq sources into file names, Proof General runs coqdep on an automatically generated, one-line file. These coqdep jobs run synchronously while the Require commands are parsed. The coqdep jobs on the real source files do run asynchronously in the background.
Locking ancestor files works as a side effect of dependency checking. This means that ancestor locking does only work when Proof General performs dependency checking and compilation itself. If an external command is used, Proof General does not see all dependencies and can therefore only lock direct ancestors.
In the default setting,
when you want to edit a locked ancestor, you are
forced to completely retract the current scripting buffer.
You can simplify this by setting proof-strict-read-only
to
'retract
(menu Proof-General -> Quick Options ->
Read Only -> Undo On Edit
). Then typing in some ancestor will
immediately retract you current scripting buffer and unlock that
ancestor.
You have two choices, if you don’t like ancestor locking in its
default way.
You can either switch ancestor locking completely off via
coq-lock-ancestors
(Customizing Coq Multiple File Support) or you can generally permit editing in locked
sections with selecting
Proof-General
-> Quick Options
-> Read Only
-> Freely Edit
(which will set the option
proof-strict-read-only
to nil
).
[The right behaviour for Coq, namely to retract the current
scripting buffer only up to the appropriate Require
command, would be quite difficult to implement in the current
Proof General infrastructure. Further, it has only dubious
benefit, as Require commands are usually on the top of each
file.]
The customization settings for multiple file support of Coq Proof
General are in a separate customization group, the
coq-auto-compile
group. To view all options in this
group do M-x customize-group coq-auto-compile
or select
menu entry Proof-General -> Advanced -> Customize -> Coq ->
Coq Auto Compile -> Coq Auto Compile
.
If non-nil, check dependencies of required modules and compile if necessary.
If non-nil ProofGeneral intercepts "Require" commands and checks if the
required library module and its dependencies are up-to-date. If not, they
are compiled from the sources before the "Require" command is processed.
This option can be set/reset via menu ‘Coq -> Settings -> Compile Before Require’.
Buffers to save before checking dependencies for compilation.
There are two orthogonal choices: Firstly one can save all or only the coq
buffers, where coq buffers means all buffers in coq mode except the current
buffer. Secondly, Emacs can ask about each such buffer or save all of them
unconditionally.
This makes four permitted values: 'ask-coq
to confirm saving all
modified Coq buffers, 'ask-all
to confirm saving all modified
buffers, 'save-coq
to save all modified Coq buffers without
confirmation and 'save-all
to save all modified buffers without
confirmation.
The following two options are for the parallel compilation method.
Choose the internal compilation method.
When Proof General compiles itself, you have the choice between
two implementations. If this setting is nil, then Proof General
uses the old implementation and compiles everything sequentially
with synchronous job. With this old method Proof General is
locked during compilation. If this setting is t, then the new
method is used and compilation jobs are dispatched in parallel in
the background. The maximal number of parallel compilation jobs
is set with ‘coq-max-background-compilation-jobs
’.
This option can be set/reset via menu ‘Coq -> Settings -> Compile Parallel In Background’.
Maximal number of parallel jobs, if parallel compilation is enabled.
Use the number of available CPU cores if this is set to
'all-cpus
. This variable is the user setting. The value that is
really used is ‘coq-internal-max-jobs
’. Use ‘coq-max-jobs-setter
’
or the customization system to change this variable. Otherwise
your change will have no effect, because ‘coq-internal-max-jobs
’
is not adapted.
The following two options deal with the load path. Proof General
divides the load path into the standard load path (which is
hardwired in the tools and need not be set explicitly), the
nonstandard load path (which must always be set explicitly), and
the current directory (which must be set explicitly for
coqdep
). The option coq-load-path
determines the
nonstandard load path and coq-load-path-include-current
determines whether the current directory is put into the load
path of coqdep
.
Non-standard coq library load path.
This list specifies the LoadPath extension for coqdep, coqc and
coqtop. Usually, the elements of this list are strings (for
"-I") or lists of two strings (for "-R" dir path and
"-Q" dir path).
The possible forms of elements of this list correspond to the 4 forms of include options (‘-I’ ‘-Q’ and ‘-R’). An element can be
- A list of the form ‘(’ocamlimport dir)', specifying (in 8.5) a
directory to be added to ocaml path (‘-I’).
- A list of the form ‘(’rec dir path)' (where dir and path are
strings) specifying a directory to be recursively mapped to the
logical path ‘path’ (‘-R dir path’).
- A list of the form ‘(’recnoimport dir path)' (where dir and
path are strings) specifying a directory to be recursively
mapped to the logical path ‘path’ (‘-Q dir path’), but not
imported (modules accessible for import with qualified names
only). Note that -Q dir "" has a special, nonrecursive meaning.
- A list of the form (8.4 only) ‘(’nonrec dir path)', specifying a
directory to be mapped to the logical path |
For convenience the symbol ‘rec’ can be omitted and entries of the form ‘(dir path)’ are interpreted as ‘(rec dir path)’.
A plain string maps to -Q ... "" in 8.5, and -I ... in 8.4.
Under normal circumstances this list does not need to
contain the coq standard library or "." for the current
directory (see ‘coq-load-path-include-current
’).
warning: if you use coq <= 8.4, the meaning of these options is not the same (-I is for coq path).
If ‘t’ let coqdep search the current directory too.
Should be ‘t’ for normal users. If ‘t’ pass -Q dir "" to coqdep when
processing files in directory "dir" in addition to any entries
in ‘coq-load-path
’.
This setting is only relevant with Coq < 8.5.
The following two options configure an external compilation process.
External compilation command. If empty ProofGeneral compiles itself.
If unset (the empty string) ProofGeneral computes the dependencies of
required modules with coqdep and compiles as necessary. This internal
dependency checking does currently not handle ML modules.
If a non-empty string, the denoted command is called to do the dependency checking and compilation. Before executing this command the following keys are substituted as follows:
%p the (physical) directory containing the source of the required module %o the Coq object file in the physical directory that will be loaded %s the Coq source file in the physical directory whose object will be loaded %q the qualified id of the "Require" command %r the source file containing the "Require" |
For instance, "make -C %p %o" expands to "make -C bar foo.vo" when module "foo" from directory "bar" is required.
After the substitution the command can be changed in the
minibuffer if ‘coq-confirm-external-compilation
’ is t.
If set let user change and confirm the compilation command.
Otherwise start the external compilation without confirmation.
This option can be set/reset via menu ‘Coq -> Settings -> Confirm External Compilation’.
Locking ancestors can be disabled with the following option.
If non-nil, lock ancestor module files.
If external compilation is used (via ‘coq-compile-command
’) then
only the direct ancestors are locked. Otherwise all ancestors are
locked when the "Require" command is processed.
The following option controls which warnings of coqdep
are treated as errors.
Regexp to match errors in the output of coqdep.
coqdep indicates errors not always via a non-zero exit status,
but sometimes only via printing warnings. This regular expression
is used for recognizing error conditions in the output of
coqdep (when coqdep terminates with exit status 0). Its default
value matches the warning that some required library cannot be
found on the load path and ignores the warning for finding a
library at multiple places in the load path. If you want to turn
the latter condition into an error, then set this variable to
"^\*\*\* Warning".
The following two options do only influence the behaviour if Proof General does dependency checking and compilation itself. These options determine whether Proof General should descend into other Coq libraries and into the Coq standard library.
Directories in which ProofGeneral should not compile modules.
List of regular expressions for directories in which ProofGeneral
should not compile modules. If a library file name matches one
of the regular expressions in this list then ProofGeneral does
neither compile this file nor check its dependencies for
compilation. It makes sense to include non-standard coq library
directories here if they are not changed and if they are so big
that dependency checking takes noticeable time.
If non-nil, ProofGeneral does not compile modules from the coq library.
Should be ‘t’ for normal coq users. If ‘nil’ library modules are
compiled if their sources are newer.
This option has currently no effect, because Proof General uses coqdep to translate qualified identifiers into library file names and coqdep does not output dependencies in the standard library.
The last three Emacs constants are internal parameters. They only need to be changed under very special, unforeseen circumstances. They can only be set in Emacs lisp code because they are no customizable user options.
Substitutions for ‘coq-compile-command
’.
Value must be a list of substitutions, where each substitution is
a 2-element list. The first element of a substitution is the
regexp to substitute, the second the replacement. The replacement
is evaluated before passing it to ‘replace-regexp-in-string
’, so
it might be a string, or one of the symbols 'physical-dir
,
'module-object
, 'module-source
, 'qualified-id
and
'requiring-file
, which are bound to, respectively, the physical
directory containing the source file, the Coq object file in
'physical-dir
that will be loaded, the Coq source file in
'physical-dir
whose object will be loaded, the qualified module
identifier that occurs in the "Require" command, and the file
that contains the "Require".
Regular expression matching Require commands in Coq.
Should match "Require" with its import and export variants up to (but not
including) the first character of the first required module. The required
modules are matched separately with ‘coq-require-id-regexp
’
Regular expression matching one Coq module identifier.
Should match precisely one complete module identifier and surrounding
white space. The module identifier must be matched with group number 1.
Note that the trailing dot in "Require A." is not part of the module
identifier and should therefore not be matched by this regexp.
In the current release some aspects of multiple file support have not been implemented. The following points will hopefully be addressed at some stage.
Declare ML Module
commands.
Coq allows the user to enter top-level commands while editing a proof script. For example, if the user realizes that the current proof will fail without an additional axiom, he or she can add that axiom to the system while in the middle of the proof. Similarly, the user can nest lemmas, beginning a new lemma while in the middle of an earlier one, and as the lemmas are proved or their proofs aborted they are popped off a stack.
Coq Proof General supports this feature of Coq. Top-level commands entered while in a proof are well backtracked. If new lemmas are started, Coq Proof General lets the user work on the proof of the new lemma, and when the lemma is finished it falls back to the previous one. This is supported to any nesting depth that Coq allows.
Warning! Using Coq commands for navigating inside the different proofs
(Resume
and especially Suspend
) are not supported,
backtracking will break syncronization.
Special note: The old feature that moved nested proofs outside the current proof is disabled.
Another feature that Coq allows is the extension of the grammar of the
proof assistant by new tactic commands. This feature interacts with the
proof script management of Proof General, because Proof General needs to
know when a tactic is called that alters the proof state. When the user
tries to retract across an extended tactic in a script, the algorithm
for calculating how far to undo has a default behavior that is not
always accurate in proof mode: do "Undo
".
Coq Proof General does not currently support dynamic tactic extension in Coq: this is desirable but requires assistance from the Coq core. Instead we provide a way to add tactic and command names in the ‘.emacs’ file. Four Configurable variables allows to register personal new tactics and commands into four categories:
Back
" to be backtracked;
Undo
" to be backtracked;
We give an example of existing commands that fit each category.
coq-user-state-preserving-commands
: example: "Print
"
coq-user-state-changing-commands
: example: "Require
"
coq-user-state-changing-tactics
: example: "Intro
"
coq-user-state-preserving-tactics
: example: "Idtac
"
This variables are regexp string lists. See their documentations in
emacs (C-h v coq-user...
) for details on how to set them in your
‘.emacs’ file.
Here is a simple example:
(setq coq-user-state-changing-commands '("MyHint" "MyRequire")) (setq coq-user-state-preserving-commands '("Show\\s-+Mydata")) |
The regexp character sequence \\s-+
means "one or more
whitespaces". See the Emacs documentation of regexp-quote
for the
syntax and semantics. WARNING: you need to restart Emacs to make the
changes to these variables effective.
In case of losing synchronization, the user can use C-c C-z to
move the locked region to the proper position,
(proof-frob-locked-end
, see section Escaping script management) or
C-c C-v to re-issue an erroneously back-tracked tactic without
recording it in the script.
Holes are an experimental feature for complex expression editing by filling in templates. It is inspired from other tools, like Pcoq (http://www-sop.inria.fr/lemme/pcoq/index.html). The principle is simple, holes are pieces of text that can be "filled" by various means. The Coq command insertion menu system makes use of the holes system. Almost all holes operations are available in the Holes menu.
Notes: Holes make use of the Emacs abbreviation mechanism, it will
work without problem if you don’t have an abbrev table defined for Coq
in your config files. Use C-h v abbrev-file-name
to see the name
of the abbreviation file.
If you already have such a table it won’t be automatically overwritten
(so that you keep your own abbreviations). But you must read the abbrev
file given in the Proof General sources to be able to use the command
insertion menus. You can do the following to merge your abbreviations
with ProofGeneral’s abbreviations: M-x read-abbrev-file
, then
select the file named coq-abbrev.el
in the
ProofGeneral/coq
directory. At Emacs exit you will be asked if
you want to save abbrevs; answer yes.
Starting with Proof General version 4.2 and Coq version 8.4, Coq Proof General has full support for proof-tree visualization, see section Graphical Proof-Tree Visualization. To find out which versions of Prooftree are compatible with this version of Proof General, see section Graphical Proof-Tree Visualization or the Prooftree website.
For the visualization to work properly, proofs must be started
with Proof
, which is encouraged practice anyway (see Coq Bug
#2776). Without Proof
you lose the initial proof goal,
possibly having two or more initial goals in the display.
To support Grab Existential Variables
Prooftree can
actually display several graphically independent proof trees in
several layers.
This document was generated by Erik Martin-Dorel on September 18, 2016 using texi2html 1.82.


[gecode-users] rtest_eq_dom doesnt lead to RT_TRUE !?!?!
Martin Mann
mmann at informatik.uni-freiburg.de
Thu Jun 8 13:35:55 CEST 2006
Greetings,
ok... i see, the costs for "normal" domain propagation is high. but if i
m right you are using several special cases during propagation too.
also there exists already the function
rtest_eq_dom(View x, int n)
so why isnt it used for the special case that one of the variables is
bound in the rtest_eq_dom(View x, View y) function? this would directly
handle the problem using the fast bound or range handling.
Thanks,
Martin
> Hi.
>
>> I found a strange behavior of the Gecode::rel function using IRT_NQ as
>> an reified constraint.
>>
>> I used 2 variables with the following domains:
>>
>> d1 = (1)
>> d2 = (0,2)
>>
>> also I ve got a reified constraint like that
>>
>> rel(home, d1, IRT_NQ, d2, isNQ, ICL_DOM)
>>
>> so isNQ should be true if d1 an d2 are unequal!
>>
>> BUT: isNQ is NOT assigned!
>
> Giving ICL_DOM as a parameter does not always mean that domain consistency is
> enforced. It only means that propagation will not be stronger than the level
> given.
> For (dis)equality, of course domain propagation is easy - nevertheless, it is
> significantly more expensive than bounds propagation. That's why it is
> currently not implemented.
>
> Cheers,
> Guido
>
More information about the gecode-users
mailing list


This document is meant to serve as a practical guide for learning useful concepts for building server side web applications with PHP. Although I've done my best to make the guide as easy to follow as possible, you may become frustrated trying to get set up and understand some of the concepts if you are not familiar enough with HTML, JavaScript, and using the command line and text editors. Of course there is no shortage of good documentation and tutorials for learning PHP, but the purpose of this guide is to provide a quick, easy to digest resource for setting up a local server running PHP, and learning some of the most useful concepts such as key language features and using javascript with PHP to process html forms and create dynamic web pages.
If you're eager to get to the code feel free to jump ahead to the next section, but it can be useful to get a little context on the origins of the language and why it's useful.
PHP is a powerful server side scripting language designed to allow you to write dynamically generated web pages. In practice, one of the most useful features of php is the simplicity of using its api to connect to a MYSQL database. By combing this functionality with javascript's XMLHttpRequest(), known commonly as AJAX, to make calls to your server side php script, dynamic web pages can be created with relative ease.
If you're wondering what the letters in PHP stand for, well according to the preface of the official php manual, the acronym stands for "PHP: Hypertext Preprocessor". Now, if you're like me and you're wondering what the hell is the point of a so called "recursive acronym" that refers to itself in the definition, then you may be more content to know that when the language was originally written by Rasmus Lerdorf in 1994, its acronym stood for "Personal Home Page." As more programmers became involved in developing the language, its acronym was changed, perhaps to reflect its broader scope.
You may be wondering what is the value of learning PHP at a time when much of the web development industry is focusing on languages such as JavaScript, Python, Ruby and others for server side programming. Well, PHP is still the most widely used server side language in the world, and this is reflected in the amount of documentation, tutorials, and frameworks available. In addition, learning web development is not an easy feat. There is a vast amount of technologies and concepts used in web development, and it's often difficult to understand why such technologies exist or how they should be used without having some historical context of how the internet has changed since the early days of the World Wide Web. By using PHP to learn some of the basic server side concepts such as handling HTTP requests, connecting to a database, and routing, it becomes easier to understand how to apply these concepts in newer frameworks and technologies.


--- link: layout: default screenshot: 'img/homepage.png' github: dvizzini.github.com description: I created this site using Jekyll and my fork of Twitter's Bootstrap, and deployed it using GitHub Pages. weight: 5 ---
This site showcases the open-source projects of Stuyvesant High School's alumni community. Please peruse and contibute.
If you are a Stuyvesant alum witha project of your own that's at least three-quarters baked, email zamansky at gmail.com so that it can be featured on this site.


--- layout: post title: 'Send To Dropbox: Email files to your Dropbox!' date: 2010-10-30 00:27:46.000000000 +05:30 type: post published: true status: publish categories: - Tech Bytes tags: - dropbox - free - stuff meta: _edit_last: '1' _aioseop_description: thisthisthis dsq_thread_id: '527546888' _thumbnail_id: '839' dsq_needs_sync: '1' author: login: satyadeep email<EMAIL_ADDRESS>display_name: Satyadeep first_name: Satyadeep last_name: K ---
If you have by an accident skimmed through my blog, you would have already realized that I am a big fan of Dropbox. Here's one more tip for Dropbox power users.
Ever thought, it would be nice if you can email files to your Dropbox. You may have several reasons for that
Send To Dropbox is a third party Dropbox app which achieves this functionality using the Dropbox API. You just need to connect your Dropbox account with Send To Dropbox, just like a twitter or facebook application - No password business! After authentication, it gives you a unique email id to which you can send the attachments to. Thats it! Any mail sent to this email will directly land in the new "Attachments" folder in your Dropbox.
You can also change settings to dump files in organized way - For example sorted by subject, or day as shown below. The app also has an option to automatically decompress .zip archives before putting into your Dropbox.
If you don’t know what Dropbox is, it is a popular file synchronization and backup tool which automatically syncs all your computers which are linked to your Dropbox to the cloud. It also gives a 2 GB free online storage space which can be expanded to a whopping 10 GB.


{{{editLink this}}} Register Agent Application Such as iModel Query Agent Machine to Machine communication with no human interaction Developer Contact Information The name of the developer who will own this application. This is the only individual who will be able to request updates to the client registrations. Developer Name: Note: Must match a valid Bentley profile. Developer Email: Note: Must match a valid Bentley profile. Must be a valid email address Application Information Client Name: Something users will recognize and trust Description of Application: This may be displayed to potential users of your application Submit {{>thank_you_message<EMAIL_ADDRESS>{{>loaderScript}}


Some languages, mostly notably C++, provide
support for marking instances of
objects as immutable, i.e. with the const
keyword. Whilst
C# supports a notion of const
, it only applies to primitive values and is essentially an alias
for a literal value. The best you can do with objects is to apply the Single
Assignment Pattern [1] to member variables using the readonly
keyword. Java’s final
keyword has a wider scope than C#’s readonly
for enforcing
single assignment, but it still falls short of enforcing mutability of the
referenced object.
Consequently in many languages immutability must be implemented through the design of the type, and as such every instance of that type will be immutable (use of reflection and other Machiavellian techniques notwithstanding). Generally speaking to create immutable objects you only pass any state at creation time through the constructor. Any properties that are exposed must only be readable and immutability must be deep, meaning that any types used in any exposed collections must themselves be immutable too. As it is with turtles [2] it should be immutability all the way down.
The most common examples of immutable types are the primitive types, such as integers and strings (at least in C#). But more complex types can easily be made immutable too with just a little thought. The benefits, as you shall hopefully see, are a significant reduction in accidental complexity [3]. Whilst the implementation of the type itself may not contain significantly less lines of code, far fewer tests will be required and significantly less grey matter exercised to drive out the behaviours that matter.
The basis for this article is a real class I recently decided to refactor to make it simpler by making it immutable. Hence what follows below was my rationale for doing the refactoring in the first place.
Imagine you are writing a service and you
have a need to provide a simple lookup to map one value to another. The data
changes pretty infrequently, but not so infrequently that you’re happy to hardcode
it. You decide to store the mapping data in a simple .
public class
ThingToWotsitMap
{
public ThingToWotsitMap()
{
_map = new Dictionary<string,
string>();
}
public void LoadMap(string filename)
{
_map.Clear();
using (var stream = new
StreamReader(filename))
{
// Parse .
. . .
}
}
public string LookupWotsit(string thing)
{
// Map thing to wotsit
}
private Dictionary<string, string>
_map;
}
If you are already screaming at the page because you spotted that the code touches the file-system and is therefore difficult to unit test, then have a gold star. But you’ll have to put that to the back of your mind as that is not what this article is about.
The class is very simple, surely there’s not much to say. Is there? Looking over the unit tests (which were written after) one pattern immediately leaps out – the use of two-phase construction:
[Test]
public void one_of_the_tests_for_the_map()
{
var filename = . . .;
var map = new ThingToWotsitMap();
map.LoadMap(filename);
Assert.That(. . .);
}
The solution is simple. All we need to do
is to add a constructor that takes a filename and then delegates to LoadMap()
for the heavy lifting, right?
That’s not the aspect of two-phase construction that bothered me; it was the fact that there was two-phase construction even to begin with. Adding another constructor does not take away the ability to mutate the class and it’s that mutability that starts to raise a number of questions about the behaviour of the class.
The first question I have is: what happens
if the client doesn’t even call LoadMap()
? Does the class behave
correctly if no data is loaded? This immediately leads to the question about LoadMap()
throwing an exception. Is the internal state consistent if that occurs, and
what happens if the client discards the error? We are back to the first
question again.
So off we go and merrily find out the answers to these questions and write a bunch more tests to make sure that the class is exception-safe and also behaves “safely” should something happen during its (two-phase) construction.
Time passes and our semi-static data becomes not quite so static. We decide that restarting the service every time we need to change the data is untenable and would like to detect when the file changes and load it again automatically at some convenient moment.
So we add a bit of code externally to the
class to watch for when the file changes and then just call LoadMap()
to
load the new data file.
But wait. Have we got any tests for calling
LoadMap()
on the class a second
time? What happens if this load fails
– is the internal structure still consistent, can we limp along with the old
data or should it behave as if freshly constructed and therefore no data was
loaded?
And all before we even get to questions
about thread safety. This is a multi-threaded service, is this class thread
safe? For example, what happens if one thread tries to lookup data whilst
another is calling LoadMap()
to refresh the data? Should existing callers be blocked and wait
for the new data or continue with the old data until the new set is fully
loaded?
Assuming you can answer all those questions, how confident are you in your ability to write thread-safe, exception-safe code? How confident are you that whatever techniques you’ve chosen to use will continue to be thread-safe as you move to new platforms in the future? Do you have adequate test coverage and/or documentation to show that you’ve even considered all these scenarios?
Let’s wind the clock back to the beginning where we noticed the two-phase construction and see if we can take a different path that doesn’t involve us writing so much production and test code, and lead to so many tricky questions too.
My personal preference is to create immutable types where possible. Essentially a type should start immutable by default and prove that adding mutability will provide some significant advantage – performance perhaps – that could not be obtained via immutability. There are some very obvious cases, such as the Builder pattern [5], where mutability is required up front, but that can often be as a stepping stone to an immutable form of the same type.
The changes I made to the example code above were fairly minor. Naturally there are many other changes we could make and so the result below is not intended to be the final word on the matter, it is only intended to show the minor transformations that were needed to achieve immutability.
The first change I made was to make the
constructor private
and to take the underlying container as a constructor argument:
private
ThingToWotsitMap(Dictionary<string, string> map)
{
_map = map;
}
The second step was to make the LoadMap()
method static
and change it to return an instance of the class; essentially
turning it into a Factory Method [6]:
public ThingToWotsitMap
LoadMap(string filename)
{
Dictionary<string, string> map = new
Dictionary<string, string>();
using (var stream = new
StreamReader(filename))
{
// Parse .
. . .
}
return new ThingToWotsitMap(map);
}
And that’s it really. One final step was to fix up the tests and production code to use this new factory method instead of the previous two-phase construction approach (I could lean heavily on the compiler here due to the nature of the refactoring):
[Test]
public void
one_of_the_tests_for_the_map()
{
var filename = . . .;
var map = ThingToWotsitMap.LoadMap(filename);
Assert.That(. . .);
}
With our new design in place let’s revisit
those earlier concerns and see how it stacks up. The first question around the
behaviour of a default initialised object is moot because you cannot create one
– you have to provide a filename. Likewise the second question around the
exception safety of the LoadMap()
method is also moot because if an exception is thrown you will not
have a fully constructed object to worry about. Essentially the whole issue of
state corruption is moot because the point of immutable types is that you can’t
change them.
So far so good, but what about our latter change in requirements where we need to reload the data on-the-fly when it changes whilst multiple threads might be accessing it? This is still largely a moot point because the type is immutable – you cannot change it, you can only create a different object with the new data in it.
From the perspective of the type itself there are no thread-safety issues, but that does not mean there are no thread-safety issues at all. Instead of putting all the effort into making the type internally thread-safe we have pushed the problem up to the owner, but their problem is almost trivial by comparison; the owner just needs to switch ownership of the object in a thread safe manner, e.g.
var newMap =
ThingToWotsitMap.LoadMap(filename);
// This
assignment needs to be thread-safe
_currentMap
= newMap;
In certain environments a write of a reference-sized value is already an atomic operation and so out-of-the-box this could already be enough, depending on how it is used. It is more likely that you’ll mark the member as “volatile” to introduce the relevant memory barrier and to ensure that the value is not aggressively cached. There shouldn’t be a need to use a heavyweight synchronization object like a mutex in this example as it’s just a single reference, but if you have to switch multiple references atomically it might be required.
Thinking about the performance of these two approaches they should be fairly similar, with the potential for the immutable version to win on the basis of needing less synchronization. Memory-wise reloading the data should be similar in both cases too, i.e. having two copies in memory at the point just before the switchover. You could choose to empty the internal container first in the mutable case before loading the file, but then you’d have to sacrifice exception safety which feels like a decision that needs serious consideration. On the face of it we don’t appear to have lost anything with our move to immutability.
Sadly there are some programming constructs
that make the design of immutable types less alluring; one is the Initializer
Syntax for objects and collections in C#. Both of these rely on the type being
mutable, with state being mutated through properties for the former case and an
Add()
method for the latter.
Here is an example of the object initializer syntax:
var point =
new Point { X = 1, Y = 2 };
Under the covers this is the same as writing:
var _point =
new Point();
_point.X =
1;
_point.Y =
2;
var point =
_point;
And this is the collection initializer syntax:
var points =
new List<Point> { new Point(1, 2) };
This is the same as writing:
var _points
= new List<Point>();
_points.Add(new
Point(1, 2));
var points =
_points;
Whilst we should not blame the language authors for providing us with a construct that allows more readable construction of objects, its over use possibly means mutability has become the de facto choice by accident. In a later version of C# the introduction of named arguments has meant that the invocation of a constructor was now also succinct and so mutability no longer had to be sacrificed for readability:
var point =
new Point( x: 1, y: 2 );
On the collection front the addition of
interfaces such as IReadOnlyList
and the new Immutable Collections library [4] means that the
runtime madness of ReadOnlyCollection
can be laid to rest.
Immutability is clearly not a panacea – one size never fits all – but hopefully following me through this thought exercise shows that it can vastly simplify the amount of time you spend thinking up scenarios to test, and therefore the amount of code you write to verify them. Given how tricky writing multi-threaded code already is, being able to reduce the amount you have to write will fill you with greater confidence that you haven’t missed some subtle race condition.
Thanks to final
keyword and its effects.
[1] http://www.bigbeeconsultants.co.uk/blog/single-assignment-pattern
[2] http://en.wikipedia.org/wiki/Turtles_all_the_way_down
[3] http://en.wikipedia.org/wiki/No_Silver_Bullet
[4] https://www.nuget.org/packages/Microsoft.Bcl.Immutable
[5] http://en.wikipedia.org/wiki/Builder_pattern
[6] http://c2.com/cgi/wiki?FactoryMethod
09 March 2015
Bio
Chris is a freelance developer who started out as a bedroom coder in the 80’s writing assembler on 8-bit micros; these days it’s C++ and C#. He also commentates on the Godmanchester duck race and can be contacted via<EMAIL_ADDRESS>or @chrisoldwood.