If you want to get started making language models as quickly as possible, you should install the toolkit and then read the Typical Use section.
Version 1 of the Carnegie Mellon University Statistical Language Modeling toolkit was written by Roni Rosenfeld, and released in 1994. It is available by ftp from here. Here is a excerpt from its README file:
Overview of the CMU SLM Toolkit, Rev 1.0 ======================================== The Carnegie Mellon Statistical Language Modeling (CMU SLM) Toolkit is a set of unix software tools designed to facilitate language modeling work in the research community. Some of the tools are used to process general textual data into: - word frequency lists and vocabularies - word bigram and trigram counts - vocabulary-specific word bigram and trigram counts - bigram- and trigram-related statistics - various Backoff bigram and trigram language models Others use the resulted language models to compute: - perplexity - Out-Of-Vocabulary (OOV) rate - bigram- and trigram-hit ratios - distribution of Backoff cases - annotation of test data with language scores
Version 2 of the toolkit seeks to maintain the structure of version 1, to include all (or very nearly all) of the functionality of version 1, and to provide useful improvements in terms of functionality and efficiency. The key differences between this version and version 1 are described in the next section.
The tools used to generate vocabulariesm, and to process the text stream which is used as training data into a id n-gram file to serve as input to idngram2lm have been completely re-written, in order to increase their efficiency.
All of the tools have been written in C, so there is no longer the reliance on shell scripts and UNIX tools such as sort and awk. The tools now run much faster, due to requiring much less disk I/O, although they do now require more RAM than the tools of version 1.
Version 1 of the toolkit allowed only Good-Turing discounting to be used in the construction of the models. Version 2 allows any of the following discounting strategies:
The tools in the toolkit are no longer limited to the construction and testing of bigram and trigram language models. As larger corpora, and faster machines with more memory become available, it is becoming more interesting to examine 4-grams, 5-grams, etc. The tools in version 2 of this toolkit enable these models to be constructed and evaluated.
The program evallm is used to test the language models produced by the toolkit. Commands to this program are read in from the standard input after the language model has been read, so the user can issue commands interactively, rather than simply from the shell command line. This means that if the user wants to calculate the perplexity of a particular language model with respect to several different texts, the language model only needs to be read once.
In version 1, the tags <s>, <p>, and <art> were all hard-wired to represent context cues, and the tag <s> was required to be in the vocabulary. In version 2, one may have any number of context cues (or none at all), and they may be represented by any symbols one chooses. The context cues are a subset of the vocabulary, and are specified in a context cue file.
In order to produce the same behaviour from version 2 as from version 1, the context cues file should contain the following lines:
<s> <p> <art>
The data structures used to store the n-grams are more compact than those of version 1, with the result that language models construction is a less memory intensive task. For example, for a trigram language model, version 1 required 12 bytes per bigram and 4 bytes per trigram. Version 2 requires only 8 bytes per bigram and 4 bytes per trigram.
As well as the compress data compression utility used in version 1 of the toolkit, there is now also support for gzip.
The evallm program allows the user to specify either inclusive or exclusive forced back-off, as well as a list of words from which to enforce back-off.
For "big-endian" machines (eg those running HP-UX, IRIX, SunOS, Solaris) the installation procedure is simply to change into the src/ directory and type
make installThe executables will then be copied into the bin/ directory, and the library file SLM2.a will be copied into the lib/ directory. For "little-endian" machines (eg those running Ultrix, Linux) the variable BYTESWAP_FLAG will need to be set in the Makefile. This can be done by editing src/Makefile directly, so that the line
#BYTESWAP_FLAG = -DSLM_SWAP_BYTESis changed to
BYTESWAP_FLAG = -DSLM_SWAP_BYTES
Then the program can be installed as before.
If you are unsure of the "endian-ness" of your machine, then the shell script endian.sh should be able to provide some assistance.
In case of problems, then more information can be found by examining src/Makefile.
Before building the executables, it might be worth adjusting the value of STD_MEM in the file src/toolkit.h. This value controls the default amount of memory (in MB) that the programs will attempt to assign for the large buffers used by some of the programs (this value can, of course, be overridden at the command line). The result is that the final process sizes will be a few MB bigger than this value. The more memory that can be grabbed, the faster the programs will run. The default value is 100, but if the machines which the tools will be run on contain less, or much more memory than this, then this value should be adjusted to reflect this.
Name Description Typical file extension An ASCII file containing text. It may Text stream or may not have markers to indicate .text context cues, and white space can be used freely. An ASCII file containing a list of Word words, and the number of times that frequency they occurred. This list is not sorted; .wfreq file it will generally be used as the input to wfreq2vocab, which does not require sorted input. Word n-gram ASCII file containing an alphabetically file sorted list of n-tuples of words, along .w3gram, .w4gram etc. with the number of occurrences ASCII file containing a list of .vocab.20K, Vocabulary vocabulary words. Comments may also be .vocab.60K etc., file included - any line beginning ## is depending on the size considered a comment. The vocabulary is of the vocabulary. limited in size to 65535 words. ASCII file containing the list of words which are to be considered "context cues". These are words which provide Context cues useful context information for the file n-grams, but which are not to be .ccs predicted by the language model. Typical examples would be <s> and <p>, the begin sentence, and begin paragraph tags. ASCII or binary (by default) file containing a numerically sorted list of Id n-gram n-tuples of numbers, corresponding to .id3gram.bin, file the mapping of the word n-grams .id4gram.ascii etc. relative to the vocabulary. Out of vocabulary (OOV) words are mapped to the number 0. Binary file containing all the n-gram Binary counts, together with discounting language information and back-off weights. Can .binlm model file be read by evallm and used to generate word probabilities quickly. ARPA ASCII file containing the language language model probabilities in ARPA-standard .arpa model file format. ASCII file containing a list of Probability probabilities (one per line). The .fprobs stream probabilities correspond the the probability for each word in a specific text stream, with context-cues and OOVs removed. ASCII file containing a list of Forced vocabulary words from which to enforce back-off back-off, together with either an 'i' .fblist file or an 'e' to indicate inclusive or exclusive forced back-off respectively.
These files may all be written are read by all the tools in compressed or uncompressed mode. Specifically, if a filename is given a .Z extension, then it will be read from the specified file via a zcat pipe, or written via a compress pipe. If a filename is given a .gz, it will be read from the specified file via a gunzip pipe, or written via a gzip pipe. If either of these compression schemes are to be used, then the relevant tools (ie zcat, and compress or gzip) must be available on the system, and pointed to by the path.
If a filename argument is given as - then it is assumed to represent either the standard input, or standard output (according to context). Any file read from the standard input is assumed to be uncompressed, and therefore, all desired compression and decompression should take place in a pipe: zcat < abc.Z | abc2xyz | compress > xyz.Z
Note that in addition to the command line options mentioned, all the tools also support -help and -version.
Input : Text stream
Output : List of every word which occurred in the text, along with its number of occurrences.
Notes : Uses a hash-table to provide an efficient method of counting word occurrences. Output list is not sorted (due to "randomness" of the hash-table), but can be easily sorted into the user's desired order by the UNIX sort command. In any case, the output does not need to be sorted in order to serve as input for wfreq2vocab.
Command Line Syntax:
text2wfreq [ -hash 1000000 ] [ -verbosity 2 ] < .text > .wfreq
Higher values for the -hash parameter require more memory, but can reduce computation time.
Input : A word unigram file, as produced by text2wfreq
Output : A vocabulary file.
Command Line Syntax:
wfreq2vocab [ -top 20000 | -gt 10] [ -records 1000000 ] [ -verbosity 2] < .wfreq > .vocab
The -top parameter allows the user to specify the size of the vocabulary; if the program is called with the command -top 20000, then the vocabulary will consist of the most common 20,000 words.
The -gt parameter allows the user to specify the number of times that a word must occur to be included in the vocabulary; if the program is called with the command -gt 10, then the vocabulary will consist of all the words which occurred more than 10 times.
If neither the -gt, nor the -top parameters are specified, then the program runs with the default setting of taking the top 20,000 words.
The -records parameter allows the user to specify how many of the word and count records to allocate memory for. If the number of words in the input exceeds this number, then the program will fail, but a high number will obviously result in a higher memory requirement.
Input : Text stream
Output : List of every word n-gram which occurred in the text, along with its number of occurrences.
Command Line Syntax:
text2wngram [ -n 3 ] [ -temp /usr/tmp/ ] [ -chars n ] [ -words m ] [ -verbosity 2 ] < .text > .wngram
The maximum numbers of charactors and words that can be stored in the buffer are given by the -chars and -words options. The default number of characters and words are chosen so that the memory requirement of the program is approximately that of STD_MEM, and the number of charactors is seven times greater than the number of words.
The -temp option allows the user to specify where the program should store its temporary files.
Input : Text stream, plus a vocabulary file.
Output : List of every id n-gram which occurred in the text, along with its number of occurrences.
Notes : Maps each word in the text stream to a short integer as soon as it has been read, thus enabling more n-grams to be stored and sorted in memory.
Command Line Syntax:
text2idngram -vocab .vocab [ -buffer 100 ] [ -temp /usr/tmp/ ] [ -files 25 ] [ -n 3 ] [ -write_ascii ] [ -fof_size 10 ] [ -verbosity 2 ] < .text > .idngram
By default, the id n-gram file is written out as binary file, unless the -write_ascii switch is used.
The size of the buffer which is used to store the n-grams can be specified using the -buffer parameter. This value is in megabytes, and the default value can be changed from 100 by changing the value of STD_MEM in the file src/toolkit.h before compiling the toolkit.
The program will also report the frequency of frequency of n-grams, and the corresponding recommended value for the -spec_num parameters of idngram2lm. The -fof_size parameter allows the user to specify the length of this list. A value of 0 will result in no list being displayed.
The -temp option allows the user to specify where the program should store its temporary files.
In the case of really huge quantities of data, it may be the case that more temporary files are generated than can be opened at one time by the filing system. In this case, the temporary files will be merged in chunks, and the -files parameter can be used to specify how many files are allowed to be open at one time.
Input : Either a word n-gram file, or an id n-gram file.
Output : Either a word m-gram file, or an id m-gram file, where m < n.
Command Line Syntax:
ngram2mgram -n N -m M [ -binary | -ascii | -words ] < .ngram > .mgram
The -binary, -ascii, -words correspond to the format of the input and output (Note that the output file will be in the same format as the input file). -ascii and -binary denote id n-gram files, in ASCII and binary formats respectively, and -words denotes a word n-gram file.
Input : Word n-gram file, plus a vocabulary file.
Output : List of every id n-gram which occurred in the text, along with its number of occurrences, in either ASCII or binary format.
Note : For this program to be successful, it is important that the vocabulary file is in alphabetical order. If you are using vocabularies generated by the wfreq2vocab tool then this should not be an issue, as they will already be alphabetically sorted.
Command Line Syntax:
wngram2idngram -vocab .vocab [ -buffer 100 ] [ -hash 200000 ] [ -temp /usr/tmp/ ] [ -files 30 ] [ -verbosity 2 ] [ -n 3 ] [ -write_ascii ] < .wngram > .idngram
The size of the buffer which is used to store the n-grams can be specified using the -buffer parameter. This value is in megabytes, and the default value can be changed from 100 by changing the value of STD_MEM in the file src/toolkit.h before compiling the toolkit.
The program will also report the frequency of frequency of n-grams, and the corresponding recommended value for the -spec_num parameters of idngram2lm. The -fof_size parameter allows the user to specify the length of this list. A value of 0 will result in no list being displayed.
Higher values for the -hash parameter require more memory, but can reduce computation time.
The -temp option allows the user to specify where the program should store its temporary files.
The -files parameter is used to specify the number of files which can be open at one time.
Input : An id n-gram file (in either binary (by default) or ASCII (if specified) mode).
Output : A list of the frequency-of-frequencies for each of the 2-grams, ... , n-grams, which can enable the user to choose appropriate cut-offs, and to specify appropriate memory requirements with the -spec_num option in idngram2lm.
Command Line Syntax:
idngram2stats [ -n 3 ] [ -fof_size 50 ] [ -verbosity 2 ] [ -ascii_input ] < .idngram > .stats
Input : A set of id n-gram files (in either binary (by default) or ASCII (if specified) format - note that they should all be in the same format, however).
Output : One id n-gram file (in either binary (by default) or ASCII (if specified) format), containing the merged id n-grams from the input files.
Notes : This utility can also be used to convert id n-gram files between ascii and binary formats.
Command Line Syntax:
mergeidngram [ -n 3 ] [ -ascii_input ] [ -ascii_output ] .idngram_1 .idngram_2 ... .idngram_N > .idngram
Input : An id n-gram file (in either binary (by default) or ASCII (if specified) format), a vocabulary file, and (optionally) a context cues file. Additional command line parameters will specify the cutoffs, the discounting strategy and parameters, etc.
Output : A language model, in either binary format (to be read by evallm), or in ARPA format.
Command Line Syntax:
idngram2lm -idngram .idngram -vocab .vocab -arpa .arpa | -binary .binlm [ -context .ccs ] [ -calc_mem | -buffer 100 | -spec_num y ... z ] [ -vocab_type 1 ] [ -oov_fraction 0.5 ] [ -linear | -absolute | -good_turing | -witten_bell ] [ -disc_ranges 1 7 7 ] [ -cutoffs 0 ... 0 ] [ -min_unicount 0 ] [ -zeroton_fraction 1.0 ] [ -ascii_input | -bin_input ] [ -n 3 ] [ -verbosity 2 ] [ -four_byte_counts ] [ -two_byte_bo_weights [ -min_bo_weight -3.2 ] [ -max_bo_weight 2.5 ] [ -out_of_range_bo_weights 10000 ] ]
The -context parameter allows the user to specify a file containing a list of words within the vocabulary which will serve as context cues (for example, markers which indicate the beginnings of sentences and paragraphs).
-calc_mem, -buffer and -spec_num x y ... z are options to dictate how it is decided how much memory should be allocated for the n-gram counts data structure. -calc_mem demands that the id n-gram file should be read twice, so that we can accurately calculate the amount of memory required. -buffer allows the user to specify an amount of memory to grab, and divides this memory equally between the 2,3, ..., n-gram tables. -spec_num allows the user to specify exactly how many 2-grams, 3-grams, ... , and n-grams will need to be stored. The default is -buffer STD_MEM.
The toolkit provides for three types of vocabulary, which each handle out-of-vocabulary (OOV) words in different ways, and which are specified using the -vocab_type flag.
A closed vocabulary (-vocab_type 0) model does not make any provision for OOVs. Any such words which appear in either the training or test data will cause an error. This type of model might be used in a command/control environment where the vocabulary is restricted to the number of commands that the system understands, and we can therefore guarantee that no OOVs will occur in the training or test data.
An open vocabulary model allows for OOVs to occur; out of vocabulary words are all mapped to the same symbol. Two types of open vocabulary model are implemented in the toolkit. The first type (-vocab_type 1) treats this symbol the same way as any other word in the vocabulary. The second type (-vocab_type 2) of open vocabulary model is to cover situations where no OOVs occurred in the training data, but we wish to allow for the situation where they could occur in the test data. This situation could occur, for example, if we have a limited amount of training data, and we choose a vocabulary which provides 100% coverage of the training set. In this case, an arbitrary proportion of the discount probability mass (specified by the -oov_fraction option) is reserved for OOV words.
The discounting strategy and its parameters are specified by the -linear, -absolute, -good_turing and -witten_bell options. With Good Turing discounting, one can also specify the range over which discounting occurs, using the -disc_ranges option.
The user can specify the cutoffs for the 2-grams, 3-grams, ..., n-grams by using the -cutoffs parameter. A cutoff of K means that > n-grams occurring K or fewer times are discarded. If the parameter is omitted, then all the cutoffs are set to zero.
The -zeroton_fraction option specifies that P(zeroton) (the unigram probability assigned to a vocabulary word that did not occurred at all in the training data) will be at least that fraction of P(singleton) (the probability assigned to a vocabulary word that occurred exactly once in the training data).By default, the n-gram counts are stored in two bytes by use of a count table (this allows the counts to exceed 65535, while keeping the data structures used to store the model compact). However, if more than 65535 distinct counts need to be stored (very unlikely, unless constructing 4-gram or higher language models using Good-Turing discounting), the -four_byte_counts option will need to be used.
The floating point values of the back-off weights may be stored as two-byte integers, by using the -two_byte_alphas switch. This will introduce slight rounding errors, and so should only be used if memory is short. The -min_alpha, -max_alpha and -out_of_range_alphas are parameters used by the functions for using two-byte alphas. Their values should only be altered if the program instructs it. For further details, see the comments in the source file src/two_byte_alphas.c.
Input : A binary format language model, as generated by idngram2lm.
Output : An ARPA format language model.
Command Line Syntax:
binlm2arpa -binary .binlm -arpa .arpa [ -verbosity 2 ]
Input : A binary or ARPA format language model, as generated by idngram2lm. In addition, one may also specify a text stream to be used to compute the perplexity of the language model. The ARPA format language model does not contain information as to which words are context cues, so if an ARPA format lanaguage model is used, then a context cues file may be specified as well.
Output : The program can run in one of two modes.
Command Line Syntax:
evallm [ -binary .binlm | -arpa .arpa [ -context .ccs ] ]
Notes: evallm can receive and process commands interactively. When it is run, it loads the language model specified at the command line, and waits for instructions from the user. The user may specify one of the following commands:
perplexity -text .text [ -probs .fprobs ] [ -oovs .oov_file ] [ -annotate .annotation_file ] [ -backoff_from_unk_inc | -backoff_from_unk_exc ] [ -backoff_from_ccs_inc | -backoff_from_ccs_exc ] [ -backoff_from_list .fblist ] [ -include_unks ]If the -probs parameter is specified, then each individual word probability will be written out to the specified probability stream file.
validate [ -backoff_from_unk_inc | -backoff_from_unk_exc ] [ -backoff_from_ccs_inc | -backoff_from_ccs_exc ] [ -backoff_from_list .fblist ] word1 word2 ... word_(n-1)Where n is the n in n-gram.
help
quit
Since the commands are read from standard input, a command file can be piped into it directly, thus removing the need for the program to run interactively:
echo "perplexity -text b.text" | evallm -binary a.binlm
Input : Files containing probability streams, as generated by the -probs option of the perplexity command of evallm. Alternatively these probabilities could be generated from a seperate piece of code, which assigns word probabilities according to some other language model, for example a cache-based LM. This probability stream can then be linearly interpolated with one from a standard n-gram model using this tool.
Output : An optimal set of interpolation weights for these probability streams, and (optionally) a probability stream corresponding to the linear combination of all the input streams, according to the optimal weights. The optimal weights are calculated using the expectation maximisation (EM) algorithm.
Command Line Syntax :
interpolate +[-] model1.fprobs +[-] model2.fprobs ... [ -test_all | -test_first n | -test_last n | -cv ] [ -tag .tags ] [ -captions .captions ] [ -in_lambdas .lambdas ] [ -out_lambdas .lambdas ] [ -stop_ratio 0.999 ] [ -probs .fprobs ] [ -max_probs 6000000 ]
The probability stream filenames are prefaced with a + (or a +- to indicate that the weighting of that model should be fixed).
There are a range of options to determine which part of the data is used to calculate the weights, and which is used to test them. One can test the perplexity of the interpolated model based on all the data, using the -test_all option, in which case a set of lambdas must also be specified with the -lambda option (ie the lambdas are pre-specified, and not calculated by the program). One can specify that the first or last n items are the test set by use of the -test_first n or -test_last n options. Or one can perform two-way cross validation using the -cv option. If none of these are specified then the whole of the data is used for weight estimation.
By default, the initial interpolation weights are fixed as 1/number_of_models, but alternative values can be stored in a file and used via the -in_lambdas option.
The -probs switch allows the user to specify a filename in which to store the combined probability stream. The optimal lambdas can also be stored in a file by use of the -out_lambdas command.
The program stops when the ratio of the test-set perplexity between two successive iterations is above the value specified in the -stop_ratio option.
The data can be partitioned into different classes (with optimisation being performed seperately on each class) using the -tags parameter. The tags file will contain an integer for each item in the probability streams corresponding to the class that the item belongs to. A file specified using the -captions option will allow the user to attach names to each of the classes. There should be one line in the captions file for each tag, with each line corresponding to the name of the tag.
The amount of memory allocated to store the probability streams is dictated by the -max_probs option, which indicates the maximum number of probabilities allowed in one stream.
Note: For an example use and output of a previous version of this program (with slightly different syntax), see Appendix B of R. Rosenfeld Adaptive Statistical Language Modeling: A Statistical Approach PhD Thesis, School of Computer Science, Carnegie Mellon University, April 1994. Published as Techical Report CMU-CS-94-138
Given a large corpus of text in a file a.text, but no specified vocabulary
Alternatively, some of these processes can be piped together:
cat a.text | text2wfreq | wfreq2vocab -top 20000 > a.vocab cat a.text | text2idngram -vocab a.vocab | \ idngram2lm -vocab a.vocab -idngram - \ -binary a.binlm -spec_num 5000000 15000000 echo "perplexity -text b.text" | evallm -binary a.binlm
Discounting is the process of replacing the original counts with modified counts so as to redistribute the probability mass from the more commonly observed events to the less frequent and unseen events. If the actual number of occurrences of an event E (such as a bigram or trigram occurrence) is c(E), then the modified count is d(c(E))c(E), where d(c(E)) is known as the discount ratio.
Good Turing discounting defines d(r) = (r+1)n(r+1) / rn(r) where n(r) is the number of events which occur r times.
The discounting is only applied to counts which occur fewer than K times, where typically K is chosen to be around 7. This is the "discounting range" which is specified using the -disc_ranges parameter of the idngram2lm program.
For further details see "Estimation of Probabilities from Sparse Data for the Language Model Component of a Speech Recognizer", Slava M. Katz, in "IEEE Transactions on Acoustics, Speech and Signal Processing", volume ASSP-35, pages 400-401, March 1987.
The discounting scheme which we refer to here as "Witten Bell discounting" is that which is referred to as type C in "The Zero-Frequency Problem: Estimating the Probabilities of Novel Events in Adaptive Text Compression", Ian H. Witten and Timothy C. Bell, in "IEEE Transactions on Information Theory, Vol 37, No. 4, July 1991".
The discounting ratio is not dependent on the event's count, but on t, the number of types which followed the particular context. It defines d(r,t) = n/(n + t), where n is the size of the training set in words. This is equivalent to setting P(w | h) = c / (n + t) (where w is a word, h is the history and c is the number of occurrences of w in the context h), for events that have been seen, and P(w | h) = t / (n + t) for unseen events.
Absolute discounting defines d(r) = (r-b)/r. Typically b=n(1)/(n(1)+2n(2)). The discounting is applied to all counts.
This is, of course, equivalent to simply subtracting the constant b from each count.
Linear discounting defines d(r) = 1 - (n(1)/C), where C is the total number of events. The discounting is applied to all counts.
For further details of both linear and absolute discounting, see "On structuring probabilistic dependencies in stochastic language modeling", H. Ney, U. Essen and R. Kneser in "Computer Speech and Language", volume 8(1), pages 1-28, 1994.
Any comments, questions or bug reports concerning the toolkit should be addressed to Philip Clarkson.


Class TextAnnotation (v2.2.2)
TextAnnotation contains a structured representation of OCR extracted text.
The hierarchy of an OCR extracted text structure is like this: TextAnnotation -> Page -> Block -> Paragraph -> Word -> Symbol Each structural component, starting from Page, may further have their own properties. Properties describe detected languages, breaks etc.. Please refer to the TextAnnotation.TextProperty message definition below for more detail.
Generated from protobuf message google.cloud.vision.v1.TextAnnotation
Methods
__construct
Constructor.
| Name | Description |
| data |
array
Optional. Data for populating the Message object. |
| ↳ pages |
array<Google\Cloud\Vision\V1\Page>
List of pages detected by OCR. |
| ↳ text |
string
UTF-8 text detected on the pages. |
getPages
List of pages detected by OCR.
Generated from protobuf field repeated .google.cloud.vision.v1.Page pages = 1;
| Type | Description |
| Google\Protobuf\Internal\RepeatedField |
setPages
List of pages detected by OCR.
Generated from protobuf field repeated .google.cloud.vision.v1.Page pages = 1;
| Name | Description |
| var |
array<Google\Cloud\Vision\V1\Page>
|
| Type | Description |
| $this |
getText
UTF-8 text detected on the pages.
Generated from protobuf field string text = 2;
| Type | Description |
| string |
setText
UTF-8 text detected on the pages.
Generated from protobuf field string text = 2;
| Name | Description |
| var |
string
|
| Type | Description |
| $this |


Metrics
Metrics are of particular importance to software architects and designers who are responsible for planning future development and remediating code structural problems. But metrics can be of interest to any developer seeking to write better source code. Metric data can assist you in writing more efficient code based on the size and scope of your overall source code. For example, you may ask: Is this function too complex? How many bytes is this file? How many loops, defaultless switches, or lines of code are present? Metrics provide answers to these questions, letting you display this information or perform queries based on metrics criteria.
This book covers the following topics:


Enter the network:
Enter the node labels:
Alpha parameter:
The similarity matrix and the labels are both white-space-separated files. The names thus cannot contain speces. The similarity matrix can be specified as a sparse matrix; missing pairs are assumed to have a similarity of zero. The names in the labels file must match those in the matrix file, but not all names in the matrix need to have a label score. The scores in the label file are optional; if only names are given they are assumed to all have the same score.


{% load staticfiles i18n %} {% load humanize %}
Use this document as a way to quick start any new project.


Does a journey to the edge of the world sound like your idea of paradise? Velkominn to the land of fire and ice. Velkominn to Eldur Fjall. Situated upon an striking island off the coast of Reykjavik amidst a landscape dotted with natural hot springs and geysers fueled by the mighty heat of Viti, a slumbering volcano. Book soon for the summer season!
Follow the links below to have a look around- then follow your heart to Eldur Fjall!


Back
Background checks
The background check on a child is the same as an adult check, this means we need to ask about criminal convictions.
The background check on a child is the same as an adult check, this means we need to ask about criminal convictions.


@(userName: String, explVar : List[(Option[String], Int, Int)])(implicit request: RequestHeader) @import helper._
Please wait, study is being created


| GIO Reference Manual | ||||
|---|---|---|---|---|
| Top | Description | Object Hierarchy | Properties |
GTcpWrapperConnectionGTcpWrapperConnection — wrapper for non-GSocketConnection-based, GSocket-based GIOStreams |
GTcpWrapperConnection; GSocketConnection * g_tcp_wrapper_connection_new (GIOStream *base_io_stream
,GSocket *socket
); GIOStream * g_tcp_wrapper_connection_get_base_io_stream (GTcpWrapperConnection *conn
);
GObject +----GIOStream +----GSocketConnection +----GTcpConnection +----GTcpWrapperConnection
A GTcpWrapperConnection can be used to wrap a GIOStream that is based on a GSocket, but which is not actually a GSocketConnection. This is used by GSocketClient so that it can always return a GSocketConnection, even when the connection it has actually created is not directly a GSocketConnection.
GSocketConnection * g_tcp_wrapper_connection_new (GIOStream *base_io_stream
,GSocket *socket
);
Wraps base_io_stream
and socket
together as a GSocketConnection.
|
the GIOStream to wrap |
|
the GSocket associated with base_io_stream
|
Returns : |
the new GSocketConnection. |
Since 2.28
GIOStream * g_tcp_wrapper_connection_get_base_io_stream
(GTcpWrapperConnection *conn
);
Get's conn
's base GIOStream
|
a GTcpWrapperConnection |
Returns : |
conn 's base GIOStream. [transfer none]
|
"base-io-stream"
property"base-io-stream" GIOStream* : Read / Write / Construct Only
The wrapped GIOStream.


Note: To complete these procedures, you must be assigned a role having the necessary permissions. To determine your role, follow the directions in Participant roles. For a basic understanding of roles and permissions, see Permissions and roles: Overview.
Note: This feature does not work with Safari.
To create and display an HTML page in your Resources area:
Resources
.
Add
menu, click Create HTML Page
.
Continue
.
Note: Pasting text from Microsoft Word directly into
the WYSIWYG editor may result in garbled output, even if the text
appears correct in the editor. Instead, to insert formatted text from
a Word document, click the Paste from Word
icon, and paste
using Ctrl-v
or Command-v
. For details, see
Pasting from Microsoft Word.
Some users have reported problems using Paste from Word
in
Internet Explorer 9; for best results, use a supported browser. See
Which browser should I use?
Use copyright below
, a text box will appear
in which you can add information about the copyright.
more
info
.
Display copyright alert and require
acknowledgment when accessed by others
. This option will require
users to agree to the copyright terms to view the resource. To see the
alert, click what's this?
. You cannot edit this alert.
Only members
of this site can see this file
. (This option is not available if
the folder to which you're adding the resource is publicly viewable.)
This file is publicly viewable
. (This option
is not available if the folder to which you're adding the resource is
publicly viewable.)
Display
this file to selected groups only.
, and then select the
group(s) that should have access. (This option does not appear if you
don't have any groups in your site; for more, see Managing groups.)
Optional properties
. You
can then add information to the following fields:
Finish
.
To edit the name, description, copyright status, or availability
and access settings for an HTML page, from the Actions
menu
next to your page's name, click Edit Details
. Make your
changes, and then click Update
to save them.
To update the content of an HTML page, from the Actions
menu next to your page's name, click Edit Content
. Make your
change, and then click Update
.


Background
I'm working on a reimplementation of Sixten, a dependently typed programming language that supports unboxed data. The reimplementation currently lives in a separate repository, and is called Sixty, though the intention is that it going to replace Sixten eventually. The main reason for doing a reimplementation is to try out some implementation techniques to make the type checker faster, inspired by András Kovács' smalltt.
In this post I'm going to show some optimisations that I implemented recently. I will also show the workflow and profiling tools that I use to find what to optimise in Haskell programs such as Sixty.
A benchmark
What set me off was that I was curious to see how Sixty would handle programs with many modules. The problem was that no one had ever written any large programs in the language so far.
As a substitute, I added a command to generate nonsense programs of a given size. The programs that I used for the benchmarks in this post consist of just over 10 000 lines divided into 100 modules that all look like this:
module Module60 exposing (..)
import Module9
import Module24
import Module35
import Module16
import Module46
import Module37
import Module50
import Module47
import Module46
import Module3
f1 : Type
f1 = Module46.f10 -> Module46.f20
f2 : Type
f2 = Module50.f24 -> Module47.f13
[...]
f30 : Type
f30 = Module37.f4 -> Module24.f24
Each module is about 100 lines of code, of which a third or so are newlines, and has thirty definitions that refer to definitions from other modules. The definitions are simple enough to be type checked very quickly, so the benchmark makes us focus mostly on other parts of the compiler.
I'd also like to write about the type checker itself, but will save that for other posts.
Profiling
I use three main tools to try to identify bottlenecks and other things to improve:
bench is a replacement for the Unix
time
command that I use to get more reliable timings, especially useful for comparing the before and after time of some change.GHC's built-in profiling support, which gives us a detailed breakdown of where time is spent when running the program.
When using Stack, we can build with profiling by issuing:
Then we can run the program with profiling enabled:
This produces a file
sixty.prof
that contains the profiling information.I also really like to use ghc-prof-flamegraph to turn the profiling output into a flamegraph:
Threadscope is a visual tool for debugging the parallelism in a Haskell program. It also shows when the garbage collector runs, so can be used when tuning garbage collector parameters.
Baseline and initial profiling
We start out on this commit.
Running sixty check
on the 100 module project on my machine gives us our baseline:
| Time | |
|---|---|
| Baseline | 1.30 s |
The flamegraph of the profiling output looks like this:
Two things stick out to me in the flamegraph:
- Parsing takes about 45 % of the time.
- Operations on
Data.Dependent.Map
take about 15 % of the time, and a large part of that is calls toQuery.gcompare
when the map is doing key comparisons during lookups and insertions.
Here's what a run looks like in ThreadScope:
And here's a more zoomed in ThreadScope picture:
I note the following in the ThreadScope output:
- One core is doing almost all of the work, with other cores only occasionally performing very short tasks.
- Garbage collection runs extremely often and takes just over 20 % of the time.
Optimisation 1: Better RTS flags
As we saw in the ThreadScope output, garbage collection runs often and takes a large part of the total runtime of the type checker.
In this commit I most notably introduce the RTS option -A50m
, which sets the default allocation area size used by the garbage collector to 50 MB, instead of the default 1 MB, which means that GC can run less often, potentially at the cost of worse cache behaviour and memory use. The value 50m
was found to be the sweet spot for performance on my machine by trying some different values.
The result of this change is this:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
The ThreadScope output shows that the change has a very noticeable effect of decreasing the number of garbage collections:
Also note that the proportion of time used by the GC went from 20 % to 3 %, which seems good to me.
Optimisation 2: A couple of Rock library improvements
Rock is a library that's used to implement query-based compilation in Sixty. I made two improvements to it that made Sixty almost twice as fast at the task:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
The changes are:
- Using
IORef
s and atomic operations instead ofMVar
s: Rock uses a cache e.g. to keep track of what queries have already been executed. This cache is potentially accessed and updated from different threads. Before this change this state was stored in anMVar
, but since it's only doing fairly simple updates, the atomic operations ofIORef
are sufficient. - Being a bit more clever about the automatic parallelisation: We'll get back to this, but at this point in time Rock uses a Haxl-like automatic parallelisation scheme, running queries done in an
Applicative
context in parallel. The change here is to only trigger parallel query execution if both sides of an application of the<*>
operator do queries that are not already cached. Before this change even the cache lookup part of the queries was done in parallel, which is likely far too fine-grained to pay off.
We can clearly see in ThreadScope that the parallelisation has a seemingly good effect for part of the runtime, but not all of it:
Unfortunately I didn't update Sixty in between the two changes, so I don't really know how much each one contributes.
Optimisation 3: Manual query parallelisation
I wasn't quite happy with the automatic parallelism since it mostly resulted in sequential execution. To improve on that, I removed the automatic parallelism support from the Rock library, and started doing it manually instead.
Code wise this change is quite small. It's going from
to
where pooledForConcurrently_
is a variant of forM_
that runs in parallel, using pooling to keep the number of threads the same as the number of cores on the machine it's run on.
Here are the timings:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
Being able to type check modules in parallel on a whim like this seems to be a great advantage of using a query-based architecture. The modules can be processed in any order, and any non-processed dependencies that are missing are processed and cached on an as-needed basis.
ThreadScope shows that the CPU core utilisation is improved, even though the timings aren't as much better as one might expect from the image:
The flamegraph is also interesting, because the proportion of time that goes to parsing has gone down to about 17 % without having made any changes to the parser, which can be seen in the top-right part of the image:
This might indicate that that part of the compiler parallelises well.
Optimisation 4: Parser lookahead
Here's an experiment that only helped a little. As we just saw, parsing still takes quite a large proportion of the total time spent, almost 17 %, so I wanted to make it faster.
 Something like this:
term :: Parser Term
term =
parenthesizedTerm -- (t)
<|> letExpression -- let x = t in t
<|> caseExpression -- case t of branches
<|> lambdaExpression -- \x. t
<|> forallExpression -- forall x. t
<|> var -- x
These alternatives are tried in order, which means that to reach e.g. the forall
case, the parser will try to parse the first token of each of the four preceding alternatives.
But note that the first character of each alternative rules out all other cases, save for (sometimes) the var
case.
So the idea here is to rewrite the parser like this:
term :: Parser Term
term = do
firstChar <- lookAhead anyChar
case firstChar of
'(' ->
parenthesizedTerm
'l' ->
letExpression
<|> var
'c' ->
caseExpression
<|> var
'\\' ->
lambdaExpression
'f' ->
forallExpression
<|> var
_ ->
var
Now we just have to look at the first character to rule out the first four alternatives when parsing a forall
.
Here are the results:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
| Parser lookahead | 0.442 s | -2 % |
Not great, but it's something.
Optimisation 5: Dependent hashmap
At this point, around 68 % of the time goes to operations on Data.Dependent.Map
:
Note that this was 15 % when we started out, so it has become the bottleneck only because we've fixed several others.
Data.Dependent.Map
implements a kind of dictionary data structure that allows the type of values to depend on the key, which is crucial for caching the result of queries, since each query may return a different type.
Data.Dependent.Map
is implemented as a clone of Data.Map
from the containers
package, adding this key-value dependency, so it's a binary tree that uses comparisons on the key type when doing insertions and lookups.
In the flamegraph above we can also see that around 21 % of the time goes to comparing the Query
type. The reason for this slowness is likely that queries often contain strings, because most are things like "get the type of [name]". Strings are slow to compare because you need to traverse at least part of the string for each comparison.
It would be a better idea to use a hash map, because then the string usually only has to be traversed once, to compute the hash, but the problem is that there is no dependent hash map library in Haskell. Until now that is. I implemented a dependent version of the standard Data.HashMap
type from the unordered-containers
as a thin wrapper around it. The results are as follows:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
| Parser lookahead | 0.442 s | -2 % |
| Dependent hashmap | 0.257 s | -42 % |
Having a look at the flamegraph after this change, we can see that HashMap
operations take about 20 % of the total run time which is a lot better than 68 % (though there's still room for improvement). We can also see that the main bottleneck is now the parser:
Optimisation 6: ReaderT
-based Rock library
Here's one that I did by ear, since it wasn't obvious from the profiling.
I mentioned that the Rock library used to support automatic parallelisation, but that I switched to doing it manually. A remnant from that is that the Task
type in Rock is implemented in a needlessly inefficient way. Task
is a monad that allows fetching queries, and is used throughout most of the Sixty compiler.
Before this change, Task
was implemented roughly as follows:
newtype Task query a = Task { unTask :: IO (Result query a) }
data Result query a where
Done :: a -> Result query a
Fetch :: query a -> (a -> Task query b) -> Result query b
So to make a Task
that fetches a query q
, you need to create an IO
action that returns a Fetch q pure
. When doing automatic parallelisation, this allows introspecting whether a Task
wants to do a fetch, such that independent fetches can be identified and run in parallel.
But actually, since we no longer support automatic parallelisation, this type might as well be implemented like this:
newtype Task query a = Task { unTask :: ReaderT (Fetch query) IO a }
newtype Fetch query = Fetch (forall a. query a -> IO a)
The ReaderT
-based implementation turns out to be a bit faster:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
| Parser lookahead | 0.442 s | -2 % |
| Dependent hashmap | 0.257 s | -42 % |
ReaderT in Rock |
0.245 s | -5 % |
Optimisation 7: Separate lexer
Let's have a look at the flamegraph at this point in time:
The parser now takes almost 30 % of the total run time. The parser is written using parser combinators that work directly on characters, so it's also doing tokenisation, or lexing, on the fly.
I've been wondering about the performance impact of this practice, since it's quite common in the Haskell world. So the change I made here is to write a faster lexer that's separate from the parser, and then make the parser work on the list of tokens that the lexer spits out.
This turns out to be a great idea:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
| Parser lookahead | 0.442 s | -2 % |
| Dependent hashmap | 0.257 s | -42 % |
ReaderT in Rock |
0.245 s | -5 % |
| Separate lexer | 0.154 s | -37 % |
The "inner loop" of the parser that I tried optimising in the "Parser lookahead" step has now become a case expression on the next token, visible here. Essentially, it's gone from matching on characters to this:
term :: Parser Term
term = do
token <- getNextToken
case token of
Lexer.LeftParen -> parenthesizedTerm
Lexer.Let -> letExpression
Lexer.Identifier ident -> pure (Var ident)
Lexer.Case -> caseExpression
Lexer.Lambda -> lambdaExpression
Lexer.Forall -> forallExpression
Lexer.Number int -> pure (Lit int)
Optimisation 8: Faster hashing
The flamegraph at this point contains mostly things I don't really know what to do with, but there's one thing left, and that's hashing of queries, which now takes just short of 18 % of the total runtime:
The change I made here is to write some Hashable
instances by hand instead of deriving them, and to add couple of inlining pragmas. This gives a 5 % speedup:
| Time | Delta | |
|---|---|---|
| Baseline | 1.30 s | |
| RTS flags | 1.08 s | -17 % |
| Rock | 0.613 s | -43 % |
| Manual parallelisation | 0.451 s | -26 % |
| Parser lookahead | 0.442 s | -2 % |
| Dependent hashmap | 0.257 s | -42 % |
ReaderT in Rock |
0.245 s | -5 % |
| Separate lexer | 0.154 s | -37 % |
| Faster hashing | 0.146 s | -5 % |
The new flamegraph shows that query hashing is now down to around 11 % of the time.
Conclusion
I was able to make the Sixty compiler nine times faster for this benchmark by using the excellent profiling tools that we have for Haskell. There's no reason to be optimising in the dark here.
As a reminder, here's what the compiler looked like in ThreadScope to start with:
Here's where we're at now:
It looks faster and it is faster.


MLA chairs meeting on Paryaya festival
by SPECIAL CORRESPONDENTUDUPIK. Raghupati Bhat, MLA, chaired a meeting of municipal officers and office-bearers of the paryaya festival committee at the Udupi municipal office here on Monday.
The meeting focused on the ways and means of successful conduct of the Paryaya festival on January 18, 2020.
Mr. Bhat directed the officers to ensure that basic facilities were provided to the people and devotees who arrived in the city to attend the Paryaya festival.
The issues of maintenance of roads and cleanliness, and ensuring proper water supply in the city during the Paryaya were discussed at the meeting.
He also directed the officers to put in all efforts during the Paryaya festival.
Anand C. Kallolikar, municipal commissioner, and other officers were present.


{% load static %}
Curling scoreboard
end: {{ round.end }}
throw: {{ round.throw }}
Your browser does not support the canvas element.
Previous
{% if next != None %}
Next
{% else %}
Next
{% endif %}
Live


This system allows you to download your timetable in the two most common calendar formats known:
Warning #1 You must select a single week, date ranges exceeding the length of a week will not work!
Warning #2 You must use List Timetable as the type of report!
Run this every week late on Sunday as the University sometimes may change schedules last moment.
Google Calendar users: create an additional calendar, this allows you to set custom items such as event colours & notifications.
This tool was written by Dominic Cobo due to his laziness for checking the Brunel's Timetable website & an alternative to the shitty alternatives out there.
Credits due to Eli Grey for FileSaver.js & blob.js libraries.
Credits due to Travis Krause (nwcell) for his ics.js library.
*The tool is in no way affiliated with the University and does not store/harvest any personal data at all.
The Brunel University London logo belongs exclusively to Brunel University London
The source code is available at https://github.com/dominiccobo/BrunelTimetableDownload and may be built upon provided credits are given where due.


Hearthstone
15
30
60
90
900
Cards Type
Hero
Minion
Spell
Weapon
Cards Faction
Horde
Alliance
Cards Race
Dragon
Demon
Cards Qualities
Legendary
Rare


One of the practices that forms part of the Toyota Production System is called the improvement blitz (or sometimes a kaizen blitz), defined as a dedicated and concentrated period of time to address a particular issue, often over the course of a several days. Dr. Spear explains, “...blitzes often take this form: A group is gathered to focus intently on a process with problems…The blitz lasts a few days, the objective is process improvement, and the means are the concentrated use of people from outside the process to advise those normally inside the process.”
Spear observes that the output of the improvement blitz team will often be a new approach to solving a problem, such as new layouts of equipment, new means of conveying material and information, a more organized workspace, or standardized work. They may also leave behind a to-do list of changes to be made down the road.
An example of a DevOps improvement blitz is the Monthly Challenge program at the Target DevOps Dojo. Ross Clanton, Director of Operations at Target, is responsible for accelerating the adoption of DevOps. One of his primary mechanisms for this is the Technology Innovation Center, more popularly known as the DevOps Dojo.
The DevOps Dojo occupies about eighteen thousand square feet of open office space, where DevOps coaches help teams from across the Target technology organization elevate the state of their practice. The most intensive format is what they call “30-Day Challenges,” where internal development teams come in for a month and work together with dedicated Dojo coaches and engineers. The team brings their work with them, with the goal of solving an internal problem they have been struggling with and to create a breakthrough in thirty days.
Throughout the thirty days, they work intensively with the Dojo coaches on the problem—planning, working, and doing demos in two-day sprints. When the 30-Day Challenge is complete, the internal teams return to their lines of business, not only having solved a significant problem, but bringing their new learnings back to their teams.
Clanton describes, “We currently have capacity to have eight teams doing 30-Day Challenges concurrently, so we are focused on the most strategic projects of the organization. So far, we’ve had some of our most critical capabilities come through the Dojo, including teams from Point Of Sale (POS), Inventory, Pricing, and Promotion.”
By having full-time assigned Dojo staff and being focused on only one objective, teams going through a 30-Day Challenge make incredible improvements.
Ravi Pandey, a Target development manager who went through this program, explains, “In the old days, we would have to wait six weeks to get a test environment. Now, we get it in minutes, and we’re working side by side with Ops engineers who are helping us increase our productivity and building tooling for us to help us achieve our goals.” Clanton expands on this idea, “It is not uncommon for teams to achieve in days what would usually take them three to six months. So far, two hundred learners have come through the Dojo, having completed fourteen challenges.”
The Dojo also supports less intensive engagement models, including Flash Builds, where teams come together for one- to three-day events, with the goal of shipping a minimal viable product (MVP) or a capability by the end of the event. They also host Open Labs every two weeks, where anyone can visit the Dojo to talk to the Dojo coaches, attend demos, or receive training.
In this chapter, we will describe this and other ways of reserving time for organizational learning and improvement, further institutionalizing the practice of dedicating time for improving daily work.
In this section, we schedule rituals that help enforce the practice of reserving Dev and Ops time for improvement work, such as non-functional requirements, automation, etc. One of the easiest ways to do this is to schedule and conduct day- or week-long improvement blitzes, where everyone on a team (or in the entire organization) self-organizes to fix problems they care about—no feature work is allowed. It could be a problematic area of the code, environment, architecture, tooling, and so forth. These teams span the entire value stream, often combining Development, Operations, and Infosec engineers. Teams that typically don’t work together combine their skills and effort to improve a chosen area and then demonstrate their improvement to the rest of the company.
In addition to the Lean-oriented terms kaizen blitz and improvement blitz, the technique of dedicated rituals for improvement work has also been called spring or fall cleanings and ticket queue inversion weeks. Other terms have also been used, such as hack days, hackathons, and 20% innovation time. Unfortunately, these specific rituals sometimes focus on product innovation and prototyping new market ideas, rather than on improvement work, and worse, they are often restricted to developers—which is considerably different than the goals of an improvement blitz.†
Our goal during these blitzes is not to simply experiment and innovate for the sake of testing out new technologies, but to improve our daily work, such as solving our daily workarounds. While experiments can also lead to improvements, improvement blitzes are very focused on solving specific problems we encounter in our daily work.
We may schedule week-long improvement blitzes that prioritize Dev and Ops working together toward improvement goals. These improvement blitzes are simple to administer: One week is selected where everyone in the technology organization works on an improvement activity at the same time. At the end of the period, each team makes a presentation to their peers that discusses the problem they were tackling and what they built. This practice reinforces a culture in which engineers work across the entire value stream to solve problems. Furthermore, it reinforces fixing problems as part of our daily work and demonstrates that we value paying down technical debt.
What makes improvement blitzes so powerful is that we are empowering those closest to the work to continually identify and solve their own problems. Consider for a moment that our complex system is like a spider web, with intertwining strands that are constantly weakening and breaking. If the right combination of strands breaks, the entire web collapses. There is no amount of command-and-control management that can direct workers to fix each strand one by one. Instead, we must create the organizational culture and norms that lead to everyone continually finding and fixing broken strands as part of our daily work. As Dr. Spear observes, “No wonder then that spiders repair rips and tears in the web as they occur, not waiting for the failures to accumulate.”
A great example of the success of the improvement blitz concept is described by Mark Zuckerberg, Facebook CEO. In an interview with Jessica Stillman of Inc.com, he says, “Every few months we have a hackathon, where everyone builds prototypes for new ideas they have. At the end, the whole team gets together and looks at everything that has been built. Many of our most successful products came out of hackathons, including Timeline, chat, video, our mobile development framework and some of our most important infrastructure like the HipHop compiler.”
Of particular interest is the HipHop PHP compiler. In 2008, Facebook was facing significant capacity problems, with over one-hundred million active users and rapidly growing, creating tremendous problems for the entire engineering team. During a hack day, Haiping Zhao, Senior Server Engineer at Facebook, started experimenting with converting PHP code to compilable C++ code, with the hope of significantly increasing the capacity of their existing infrastructure. Over the next two years, a small team was assembled to build what became known as the HipHop compiler, converting all Facebook production services from interpreted PHP to compiled C++ binaries. HipHop enabled Facebook’s platform to handle six times higher production loads than the native PHP.
In an interview with Cade Metz of Wired, Drew Paroski, one of the engineers who worked on the project, noted, “There was a moment where, if HipHop hadn’t been there, we would have been in hot water. We would probably have needed more machines to serve the site than we could have gotten in time. It was a Hail Mary pass that worked out.”
Later, Paroski and fellow engineers Keith Adams and Jason Evans decided that they could beat the performance of the HipHop compiler effort and reduce some of its limitations that reduced developer productivity. The resulting project was the HipHop virtual machine project (“HHVM”), taking a just-in-time compilation approach. By 2012, HHVM had completely replaced the HipHop compiler in production, with nearly twenty engineers contributing to the project.
By performing regularly scheduled improvement blitzes and hack weeks, we enable everyone in the value stream to take pride and ownership in the innovations they create, and we continually integrate improvements into our system, further enabling safety, reliability, and learning.
A dynamic culture of learning creates conditions so that everyone can not only learn, but also teach, whether through traditional didactic methods (e.g., people taking classes, attending training) or more experiential or open methods (e.g., conferences, workshops, mentoring). One way that we can foster this teaching and learning is to dedicate organizational time to it.
Steve Farley, VP of Information Technology at Nationwide Insurance, said, “We have five thousand technology professionals, who we call ‘associates.’ Since 2011, we have been committed to create a culture of learning—part of that is something we call Teaching Thursday, where each week we create time for our associates to learn. For two hours, each associate is expected to teach or learn. The topics are whatever our associates want to learn about—some of them are on technology, on new software development or process improvement techniques, or even on how to better manage their career. The most valuable thing any associate can do is mentor or learn from other associates.”
As has been made evident throughout this book, certain skills are becoming increasingly needed by all engineers, not just by developers. For instance, it is becoming more important for all Operations and Test engineers to be familiar with Development techniques, rituals, and skills, such as version control, automated testing, deployment pipelines, configuration management, and creating automation. Familiarity with Development techniques helps Operations engineers remain relevant as more technology value streams adopt DevOps principles and patterns.
Although the prospect of learning something new may be intimidating or cause a sense of embarrassment or shame, it shouldn’t. After all, we are all lifelong learners, and one of the best ways to learn is from our peers. Karthik Gaekwad, who was part of the National Instruments DevOps transformation, said, “For Operations people who are trying to learn automation, it shouldn’t be scary—just ask a friendly developer, because they would love to help.”
We can help further help teach skills through our daily work by jointly performing code reviews that include both parties so that we learn by doing, as well as by having Development and Operations work together to solve small problems. For instance, we might have Development show Operations how to authenticate an application, and login and run automated tests against various parts of the application to ensure that critical components are working correctly (e.g., key application functionality, database transactions, message queues). We would then integrate this new automated test into our deployment pipeline and run it periodically, sending the results to our monitoring and alerting systems so that we get earlier detection when critical components fail.
As Glenn O’Donnell from Forrester Research quipped in his 2014 DevOps Enterprise Summit presentation, “For all technology professionals who love innovating, love change, there is a wonderful and vibrant future ahead of us.”
In many cost-focused organizations, engineers are often discouraged from attending conferences and learning from their peers. To help build a learning organization, we should encourage our engineers (both from Development and Operations) to attend conferences, give talks at them, and, when necessary, create and organize internal or external conferences themselves.
DevOpsDays remains one of the most vibrant self-organized conference series today. Many DevOps practices have been shared and promulgated at these events. It has remained free or nearly free, supported by a vibrant community of practitioner communities and vendors.
The DevOps Enterprise Summit was created in 2014 for technology leaders to share their experiences adopting DevOps principles and practices in large, complex organizations. The program is organized primarily around experience reports from technology leaders on the DevOps journey, as well as subject matter experts on topics selected by the community.
Case Study
Internal Technology Conferences at Nationwide Insurance, Capital One, and Target (2014)
Along with attending external conferences, many companies, including those described in this section, have internal conferences for their technology employees.
Nationwide Insurance is a leading provider of insurance and financial services, and operates in heavily regulated industries. Their many offerings include auto and homeowners insurance, and they are the top provider of public-sector retirement plans and pet insurance. As of 2014, $195 billion in assets, with $24 billion in revenue. Since 2005, Nationwide has been adopting Agile and Lean principles to elevate the state of practice for their five thousand technology professionals, enabling grassroots innovation.
Steve Farley, VP of Information Technology, remembers, “Exciting technology conferences were starting to appear around that time, such as the Agile national conference. In 2011, the technology leadership at Nationwide agreed that we should create a technology conference, called TechCon. By holding this event, we wanted to create a better way to teach ourselves, as well as ensure that everything had a Nationwide context, as opposed to sending everyone to an external conference.”
Capital One, one of the largest banks in the US with over $298 billion in assets and $24 billion in revenue in 2015, held their first internal software engineering conference in 2015 as part of their goal to create a world-class technology organization. The mission was to promote a culture of sharing and collaboration, and to build relationships between the technology professionals and enable learning. The conference had thirteen learning tracks and fifty-two sessions, and over 1,200 internal employees attended.
Dr. Tapabrata Pal, a technical fellow at Capital One and one of the organizers of the event, describes, “We even had an expo hall, where we had twenty-eight booths, where internal Capital One teams were showing off all the amazing capabilities they were working on. We even decided very deliberately that there would be no vendors there, because we wanted to keep the focus on Capital One goals.”
Target is the sixth-largest retailer in the US, with $72 billion in revenue in 2014 and 1,799 retail stores and 347,000 employees worldwide. Heather Mickman, a director of Development, and Ross Clanton have held six internal DevOpsDays events since 2014 and have over 975 followers inside their internal technology community, modeled after the DevOpsDays held at ING in Amsterdam in 2013.‡
After Mickman and Clanton attended the DevOps Enterprise Summit in 2014, they held their own internal conference, inviting many of the speakers from outside firms so that they could re-create their experience for their senior leadership. Clanton describes, “2015 was the year when we got executive attention and when we built up momentum. After that event, tons of people came up to us, asking how they could get involved and how they could help.”
Creating an internal coaching and consulting organization is a method commonly used to spread expertise across an organization. This can come in many different forms. At Capital One, designated subject matter experts hold office hours where anyone can consult with them, ask questions, etc.
Earlier in the book, we began the story of how the Testing Grouplet built a world-class automated testing culture at Google starting in 2005. Their story continues here, as they try to improve the state of automated testing across all of Google by using dedicated improvement blitzes, internal coaches, and even an internal certification program.
Bland said, at that time, there was a 20% innovation time policy at Google, enabling developers to spend roughly one day per week on a Google-related project outside of their primary area of responsibility. Some engineers chose to form grouplets, ad hoc teams of like-minded engineers who wanted to pool their 20% time, allowing them to do focused improvement blitzes.
A testing grouplet was formed by Bharat Mediratta and Nick Lesiecki, with the mission of driving the adoption of automated testing across Google. Even though they had no budget or formal authority, as Mike Bland described, “There were no explicit constraints put upon us, either. And we took advantage of that.”
They used several mechanisms to drive adoption, but one of the most famous was Testing on the Toilet (or TotT), their weekly testing periodical. Each week, they published a newsletter in nearly every bathroom in nearly every Google office worldwide. Bland said, “The goal was to raise the degree of testing knowledge and sophistication throughout the company. It’s doubtful an online-only publication would’ve involved people to the same degree.”
Bland continues, “One of the most significant TotT episodes was the one titled, ‘Test Certified: Lousy Name, Great Results,’ because it outlined two initiatives that had significant success in advancing the use of automated testing.”
Test Certified (TC) provided a road map to improve the state of automated testing. As Bland describes, “It was intended to hack the measurement-focused priorities of Google culture...and to overcome the first, scary obstacle of not knowing where or how to start. Level 1 was to quickly establish a baseline metric, Level 2 was setting a policy and reaching an automated test coverage goal, and Level 3 was striving towards a long-term coverage goal.”
The second capability was providing Test Certified mentors to any team who wanted advice or help, and Test Mercenaries (i.e., a full-time team of internal coaches and consultants) to work hands-on with teams to improve their testing practices and code quality. The Mercenaries did so by applying the Testing Grouplet’s knowledge, tools, and techniques to a team’s own code, using TC as both a guide and a goal. Bland was eventually a leader of the Testing Grouplet from 2006 to 2007, and a member of the Test Mercenaries from 2007 to 2009.
Bland continues, “It was our goal to get every team to TC Level 3, whether they were enrolled in our program our not. We also collaborated closely with the internal testing tools teams, providing feedback as we tackled testing challenges with the product teams. We were boots on the ground, applying the tools we built, and eventually, we were able to remove ‘I don’t have time to test’ as a legitimate excuse.”
He continues, “The TC levels exploited the Google metrics-driven culture—the three levels of testing were something that people could discuss and brag about at performance review time. The Testing Grouplet eventually got funding for the Test Mercenaries, a staffed team of full-time internal consultants. This was an important step, because now management was fully onboard, not with edicts, but by actual funding.”
Another important construct was leveraging company-wide “Fixit” improvement blitzes. Bland describes Fixits as “when ordinary engineers with an idea and a sense of mission recruit all of Google engineering for one-day, intensive sprints of code reform and tool adoption.” He organized four company-wide Fixits, two pure Testing Fixits and two that were more tools-related, the last involving more than one hundred volunteers in over twenty offices in thirteen countries. He also led the Fixit Grouplet from 2007 to 2008.
These Fixits, as Bland describes means that we should provide focused missions at critical points in time to generate excitement and energy, which helps advance the state-of-the-art. This will help the long-term culture change mission reach a new plateau with every big, visible effort.
The results of the testing culture are self-evident in the amazing results Google has achieved, presented throughout the book.
This chapter described how we can institute rituals that help reinforce the culture that we are all lifelong learners and that we value the improvement of daily work over daily work itself. We do this by reserving time to pay down technical debt, create forums that allow everyone to learn from and teach each other, both inside our organization and outside it. And we make experts available to help internal teams, either by coaching or consulting or even just holding office hours to answer questions.
By having everyone help each other learn in our daily work, we out-learn the competition, helping us win in the marketplace. But also we help each other achieve our full potential as human beings.
Throughout Part V, we explored the practices that help create a culture of learning and experimentation in your organization. Learning from incidents, creating shared repositories, and sharing learnings is essential when we work in complex systems, helping to make our work culture more just and our systems safer and more resilient.
In Part VI, we’ll explore how to extend flow, feedback, and learning and experimentation by using them to simultaneously help us achieve our Information Security goals.


https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html - amazing article explaining everything in detail
Complete
https://dirkjanm.io/worst-of-both-worlds-ntlm-relaying-and-kerberos-delegation/


Subclass of current user's
FriendsList
that contains subset of Friends that the
current user is tracking. When the current user chooses to track a friend in the
FriendsProfileActivity
then that
Friend
is added to the current user's TrackedFriendsList.
Note that the tracked friend will now be in both the user's FriendsList and trackedFriendsList. The
current user can also remove friends from their TrackedFriendsList by setting that friend's tracked status
to "untracked" in the friend's FriendsProfileActivity, in the event of which that friend will be removed
from the TrackedFriendsList but will remain in the FriendsList. Deleting the friend altogether (also done
in he FriendsProfileActivity) will remove the friend from both the FriendsList and TrackedFriendsList.
This class has exactly the same attributes and method implementations as FriendsList, and exists in
order to better organise a user's friends as tracked and untracked.


{% extends 'base.html' %} {% load staticfiles %} {% block body %}
Zombies on Campus is a quick fun choice-based game where a user can play a variety of stories and make choices that affect the ending.
The development team
University of Glasgow, March 2016
We would like to thank our lecturer Dr Leif Azzopardi web for his guidance and his valuable online guide Tango With Django .
The project was built with the help of a variety of technologies
If you wish, watch or star the project on GitHub
GitHub


Nationalization in the UK: Labour's plans for companies
BIRMINGHAM, England (Reuters) - Britain’s opposition Labour Party unveiled its election manifesto on Thursday, including a sweeping programme of nationalization to reverse decades of pro-privatisation public policy.
Below are the private utility and infrastructure companies that Labour, currently lagging in opinion polls, says it wants to take back under state control:
BROADBAND
Labour has said it will nationalize telecoms provider BT’s fixed line network to provide free full-fibre broadband for all.
It will create British Digital Infrastructure to roll out a full-fibre network, including acquiring access to existing assets, and British Broadband Services to deliver free broadband.
Labour said last week the plan would require a sweeping upgrade of Britain’s internet infrastructure that would be paid for by raising taxes on tech firms such as Alphabet’s Google, Amazon and Facebook.
Labour said the proposal would cost about 20 billion pounds ($26 billion) but the chief executive of BT said the plan could cost taxpayers as much as 100 billion pounds.
RAIL
Labour wants to nationalize the rail industry within five years of winning power. The party says this will allow fares to be capped, improve the reliability of services and mean free wi-fi across the network.
Britain’s railways are already partly nationalized with the infrastructure operator Network Rail, which controls stations as well as tracks, tunnels and level crossings, in the public sector.
But the train operating companies are mainly privately run under limited-term contracts. Under Labour’s plans, the government would wait for the contracts to expire and then take operations back into public hands.
POSTAL SERVICE
Labour wants to return Royal Mail, one of the world’s oldest postal services, to state control six years after the company was privatised, saying this was a “historic mistake” and that the company was sold off too cheaply.
The Conservative government’s handling of the sale of the 503-year-old company has come under renewed scrutiny after Britain’s spending watchdog concluded the government had set the price too low.
WATER
Labour has proposed renationalising water companies, which have been criticized for prioritizing dividends and executive pay over preventing leaks and improving water quality.
Labour’s second most powerful man, John McDonnell, said earlier this year the government would pay less than 15 billion pounds to investors when it renationalizes the companies.
ENERGY
Labour wants to nationalize the energy networks which transport electricity and gas to homes and businesses.
The party’s membership wants to go one step further and passed a motion at its annual conference in September proposing to nationalize Britain’s largest energy suppliers.
PRIVATE SECTOR CONTRACTS
Labour has vowed to nationalize all private finance contracts - which fund public infrastructure with private capital.
There are 700 private finance contracts in existence worth about 60 billion pounds, a parliamentary watchdog said last year.
OIL COMPANY WINDFALL TAX
Labour said it will introduce a windfall tax on oil companies so that companies that knowingly damage the climate will help cover the costs.


PCA - PCU Full Time - Festus, MO 63028
We’re a Little Different
Our mission is clear. We bring to life a healing ministry through our compassionate care and exceptional service.
We don’t believe in jobs at Mercy, we believe in careers that match the unique gifts of unique individuals; careers that not only make the most of your skills and talents, but also your heart.
At Mercy, you’ll feel our supportive community every step of your day, especially the tough ones. We’re a team and love working that way. That team is expanding, and we currently have exceptional opportunities to help our communities grow.
Under the direction of the RN or LPN, assists in the individualized care of the patient to achieve the patients highest level of wellness. Works cooperatively with others as part of a team; recognizes the importance of group goals. Performs designated clinical procedures and nonclinical support tasks essential to providing care to the patient. Assists in unit operational support tasks or duties.
Because you’re committed to excellence, you understand the importance of being properly prepared for your role at Mercy. That’s why you’ll bring to your role the right set of qualifications:
Education: High school diploma, G.E.D. and/or current co-worker of Mercy. Successful completion of PCA course.
a. Administers daily hygiene measures.
b. Performs routines daily activities: ambulation, passes trays, snacks, water, feeds patients, turns and
positions patients, observes for skin breakdown.
c. Gathers and records patient data.
d. Performs bedside glucose monitoring.
e. Observes changes or unusual occurrences in patient condition and reports them immediately to the appropriate personnel.
f. Provides patients and their families with explanation of care and psychological support under the direction of the nurse.
g. Participates in the admission, discharge and transfer of patients and their belongings.
h. Applies knowledge of cost effectiveness without jeopardizing patient outcome.
i. Assures all patient charges/credits are entered appropriately.
j. Demonstrates flexibility regarding workload, assignments and change.
We’ll Support You at Work and Home
Our foundations are built on dignity and respect. Modern Healthcare Magazine named us as a “top 100 places to work.” We go out of our way to help people feel welcomed. We offer day-one comprehensive health, vision and dental coverage, PTO, tuition reimbursement and employer-matched retirement funds to benefit-eligible co-workers, including those working 48 hours or more per pay period!
What Makes a Good Match for Mercy
Compassion and professionalism go hand-in-hand with us, along with exceptional quality care. Having a positive outlook and a strong sense of advocacy is in perfect step with our mission and vision. We’re also collaborative and are not afraid to do a little extra to deliver excellent care – that’s just part of our commitment. If that sounds like a fit for you as well, we encourage you to apply.
Mercy has determined this is a safety-sensitive position. The ability to work in a constant state of alertness and in a safe manner is an essential function of this job.


Date-based navigation (roll days, months) in BIAL script directly, format days to own formats.
Link to blog: Design Studio SDK: Simple Date Object Component


No properties have been computed for the selected element. Either the element has no properties or you might have to run a property computing analyses.


version
2.0.5
help
|
about
|
report issue
Load Base
Load Comp
Compare
< Prev Pair
Next Pair >
Zoom
0.4X (shrink)
0.8X (shrink)
2X (magnify)
3X (magnify)
4X (magnify)
8X (magnify)
Base
Comp
Toggle
Speed: Very Slow
Speed: Slow
Speed: Medium
Speed: Fast
Speed: Very Fast
Base
Comp
Compare Type
Flat book pages
Curved book pages
Save
Current Visualisation
Reference Line
Toggle
Update
Change Base
Change Comp
Base
<
>
↔
↕
↶
↷
Comp.
<
>
↔
↕
↶
↷
Base (full image)
Base (cropped)
Overlap
Comp.
Diff
Comp. (full image)
Comp. (cropped)
Overlap
Base (cropped)


{% extends "layout.html" %} {% block body %}
Search
[clear all results]
(A preview of this document is not available.)


I am attempting to do a spot of Hooting Yard housekeeping, delving into the terrifying innards of WordPress to tweak this website here & there. Frankly, I find my brain befuddled, but progress is being made, albeit slowly.
Thus far, I have managed to make a couple of updates to the sidebar. A while ago, ResonanceFM discontinued its podcasts and, as far as I know, erased them from history. I haven't worked out how to remove the podcasty links over to your right, but I have inserted a link to the Hooting Yard audio archive on Mixcloud. Shows are available there almost as soon as they have been broadcast.
I recently trod in the puddle of Instagram, and have added a sidebar link so you lot can go and look at pictures posted by out_of_print_pamphleteer.
I shall keep you informed of further refinements if my brain doers not overheat in the meantime.
UPDATE : I've also inserted a sidebar Archives section, where you can browse through the morass of potsages [sic] month by month.
FURTHER UPDATE : Those podcast links have now been excised. See the Comments, however, for Old Resonance Hooting Yard Podcasts News, and watch this space …


DriverTarget(bpy_struct)¶
base class — bpy_struct
-
class
bpy.types.
DriverTarget
(bpy_struct)¶ Source of input values for driver variables
-
bone_target
¶ Name of PoseBone to use as target
Type: string, default “”, (never None)
-
data_path
¶ RNA Path (from ID-block) to property used
Type: string, default “”, (never None)
-
id
¶ ID-block that the specific property used can be found from (id_type property must be set first)
Type: ID
-
id_type
¶ Type of ID-block that can be used
Type: enum in [‘ACTION’, ‘ARMATURE’, ‘BRUSH’, ‘CAMERA’, ‘CACHEFILE’, ‘CURVE’, ‘FONT’, ‘GREASEPENCIL’, ‘COLLECTION’, ‘IMAGE’, ‘KEY’, ‘LIGHT’, ‘LIBRARY’, ‘LINESTYLE’, ‘LATTICE’, ‘MASK’, ‘MATERIAL’, ‘META’, ‘MESH’, ‘MOVIECLIP’, ‘NODETREE’, ‘OBJECT’, ‘PAINTCURVE’, ‘PALETTE’, ‘PARTICLE’, ‘LIGHT_PROBE’, ‘SCENE’, ‘SOUND’, ‘SPEAKER’, ‘TEXT’, ‘TEXTURE’, ‘WINDOWMANAGER’, ‘WORLD’, ‘WORKSPACE’], default ‘OBJECT’
-
rotation_mode
¶ Mode for calculating rotation channel values
AUTO
Auto Euler, Euler using the rotation order of the target.XYZ
XYZ Euler, Euler using the XYZ rotation order.XZY
XZY Euler, Euler using the XZY rotation order.YXZ
YXZ Euler, Euler using the YXZ rotation order.YZX
YZX Euler, Euler using the YZX rotation order.ZXY
ZXY Euler, Euler using the ZXY rotation order.ZYX
ZYX Euler, Euler using the ZYX rotation order.QUATERNION
Quaternion, Quaternion rotation.SWING_TWIST_X
Swing and X Twist, Decompose into a swing rotation to aim the X axis, followed by twist around it.SWING_TWIST_Y
Swing and Y Twist, Decompose into a swing rotation to aim the Y axis, followed by twist around it.SWING_TWIST_Z
Swing and Z Twist, Decompose into a swing rotation to aim the Z axis, followed by twist around it.
Type: enum in [‘AUTO’, ‘XYZ’, ‘XZY’, ‘YXZ’, ‘YZX’, ‘ZXY’, ‘ZYX’, ‘QUATERNION’, ‘SWING_TWIST_X’, ‘SWING_TWIST_Y’, ‘SWING_TWIST_Z’], default ‘AUTO’
-
transform_space
¶ Space in which transforms are used
WORLD_SPACE
World Space, Transforms include effects of parenting/restpose and constraints.TRANSFORM_SPACE
Transform Space, Transforms don’t include parenting/restpose or constraints.LOCAL_SPACE
Local Space, Transforms include effects of constraints but not parenting/restpose.
Type: enum in [‘WORLD_SPACE’, ‘TRANSFORM_SPACE’, ‘LOCAL_SPACE’], default ‘WORLD_SPACE’
-
transform_type
¶ Driver variable type
Type: enum in [‘LOC_X’, ‘LOC_Y’, ‘LOC_Z’, ‘ROT_X’, ‘ROT_Y’, ‘ROT_Z’, ‘ROT_W’, ‘SCALE_X’, ‘SCALE_Y’, ‘SCALE_Z’, ‘SCALE_AVG’], default ‘LOC_X’
-
classmethod
bl_rna_get_subclass
(id, default=None)¶ Parameters: id (string) – The RNA type identifier. Returns: The RNA type or default when not found. Return type: bpy.types.Struct
subclass
-
classmethod
bl_rna_get_subclass_py
(id, default=None)¶ Parameters: id (string) – The RNA type identifier. Returns: The class or default when not found. Return type: type
-
Inherited Properties
Inherited Functions
References


Adjustment
public class Adjustment: Object
The Adjustment
object represents a value which has an associated lower and
upper bound, together with step and page increments, and a page size. It is
used within several GTK+ widgets, including SpinButton
, Viewport
, and
Range
(which is a base class for Scrollbar
and Scale
).
The Adjustment
object does not update the value itself. Instead it is left
up to the owner of the Adjustment
to control the value.
-
Parameter
Parameter box: the object which received the signalDeclaration
Swift
public typealias ChangedCallback = (
Parameters
box
the object which received the signal
-
Parameter
Parameter box: the object which received the signalDeclaration
Swift
public typealias ValueChangedCallback = (
Parameters
box
the object which received the signal
-
Creates a new
Adjustment
.Parameter
Parameter value: the initial valueParameter
Parameter lower: the minimum valueParameter
Parameter upper: the maximum valueParameter
Parameter stepIncrement: the step incrementParameter
Parameter pageIncrement: pageIncrementParameter
Parameter pageSize: the page sizeDeclaration
Swift
public convenience init(value: Double, lower: Double, upper: Double, stepIncrement: Double, pageIncrement: Double, pageSize: Double)
Parameters
value
the initial value
lower
the minimum value
upper
the maximum value
stepIncrement
the step increment
pageIncrement
pageIncrement
pageSize
the page size
-
The value of the adjustment.
Declaration
Swift
public var value: Double
-
Updates the
value
property to ensure that the range betweenlower
andupper
is in the current page (i.e. betweenvalue
andvalue
+pageSize
). If the range is larger than the page size, then only the start of it will be in the current page.A
valueChangedSignal
will be emitted if the value is changed.Parameter
Parameter lower: the lower valueParameter
Parameter upper: the upper valueDeclaration
Swift
public func clampPage(lower: Double, upper: Double)
Parameters
lower
the lower value
upper
the upper value
-
Sets all properties of the adjustment at once.
Use this function to avoid multiple emissions of the
changedSignal
. Seelower
property for an alternative way of compressing multiple emissions ofchangedSignal
into one.Parameter
Parameter value: the new valueParameter
Parameter lower: the new minimum valueParameter
Parameter upper: the new maximum valueParameter
Parameter stepIncrement: the new step incrementParameter
Parameter pageIncrement: the new page incrementParameter
Parameter pageSize: the new page sizeDeclaration
Swift
public func configure(value: Double, lower: Double, upper: Double, stepIncrement: Double, pageIncrement: Double, pageSize: Double)
Parameters
value
the new value
lower
the new minimum value
upper
the new maximum value
stepIncrement
the new step increment
pageIncrement
the new page increment
pageSize
the new page size
-
The minimum value of the adjustment.
Declaration
Swift
public var lower: Double
-
The page increment of the adjustment.
Declaration
Swift
public var pageIncrement: Double
-
The page size of the adjustment. Note that the page-size is irrelevant and should be set to zero if the adjustment is used for a simple scalar value, e.g. in a
SpinButton
.Declaration
Swift
public var pageSize: Double
-
The step increment of the adjustment.
Declaration
Swift
public var stepIncrement: Double
-
The maximum value of the adjustment. Note that values will be restricted by
upper - pageSize
if the page-size property is nonzero.Declaration
Swift
public var upper: Double
-
The smaller of step increment and page increment.
Declaration
Swift
public var minimumIncrement: Double
-
Emitted when one or more of the
Adjustment
properties have been changed, other than thevalue
property.Declaration
Swift
public lazy var changedSignal:
-
Emitted when the
value
property has been changed.Declaration
Swift
public lazy var valueChangedSignal: