--- layout: post title: "Amazing Playoff Moments" external-url: http://www.youtube.com/watch?v=JZGEzREaYRA&fmt=22 ---
One HD, Australia’s new free-to-air 24 hour sports channel has been running similar but slightly different commercials. Same music, slow motion and single continuous shot but with the crowd in place and the colour removed. In a world of overly aggressive, awkward and plain uninteresting commercials these really stand out. Kottke has links to a few more and a side story.


--- layout: post title: Then... date: '2015-05-18T19:30:28+02:00' categories: - Storyboards picture_url: https://film-Storyboards.tumblr.com/post/119319284693/then-i-realised-i-couldnt-draw-shoes ---
Then I realised I couldn’t draw shoes…


| PostgreSQL 9.0.10 Documentation | ||||
|---|---|---|---|---|
| Prev | Up | Chapter 7. Queries | Next |
A table expression computes a table. The table expression contains a FROM clause that is optionally followed by WHERE, GROUP BY, and HAVING clauses. Trivial table expressions simply refer to a table on disk, a so-called base table, but more complex expressions can be used to modify or combine base tables in various ways.
The optional WHERE, GROUP BY, and HAVING clauses in the table expression specify a pipeline of successive transformations performed on the table derived in the FROM clause. All these transformations produce a virtual table that provides the rows that are passed to the select list to compute the output rows of the query.
The FROM Clause derives a table from one or more other tables given in a comma-separated table reference list.
FROM table_reference [, table_reference [, ...]]
A table reference can be a table name (possibly schema-qualified), or a derived table such as a subquery, a table join, or complex combinations of these. If more than one table reference is listed in the FROM clause they are cross-joined (see below) to form the intermediate virtual table that can then be subject to transformations by the WHERE, GROUP BY, and HAVING clauses and is finally the result of the overall table expression.
When a table reference names a table that is the parent of a table inheritance hierarchy, the table reference produces rows of not only that table but all of its descendant tables, unless the key word ONLY precedes the table name. However, the reference produces only the columns that appear in the named table — any columns added in subtables are ignored.
Instead of writing ONLY before the table name, you can write * after the table name to explicitly specify that descendant tables are included. Writing * is not necessary since that behavior is the default (unless you have changed the setting of the sql_inheritance configuration option). However writing * might be useful to emphasize that additional tables will be searched.
A joined table is a table derived from two other (real or derived) tables according to the rules of the particular join type. Inner, outer, and cross-joins are available.
Join Types
T1 CROSS JOIN T2
For every possible combination of rows from T1 and T2 (i.e., a Cartesian product), the joined table will contain a row consisting of all columns in T1 followed by all columns in T2. If the tables have N and M rows respectively, the joined table will have N * M rows.
FROM T1 CROSS JOIN T2 is equivalent to FROM T1, T2. It is also equivalent to FROM T1 INNER JOIN T2 ON TRUE (see below).
T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 ON boolean_expression T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 USING ( join column list ) T1 NATURAL { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2
The words INNER and OUTER are optional in all forms. INNER is the default; LEFT, RIGHT, and FULL imply an outer join.
The join condition is specified in the ON or USING clause, or implicitly by the word NATURAL. The join condition determines which rows from the two source tables are considered to "match", as explained in detail below.
The ON clause is the most general kind of join condition: it takes a Boolean value expression of the same kind as is used in a WHERE clause. A pair of rows from T1 and T2 match if the ON expression evaluates to true for them.
USING is a shorthand notation: it takes a comma-separated list of column names, which the joined tables must have in common, and forms a join condition specifying equality of each of these pairs of columns. Furthermore, the output of JOIN USING has one column for each of the equated pairs of input columns, followed by the remaining columns from each table. Thus, USING (a, b, c) is equivalent to ON (t1.a = t2.a AND t1.b = t2.b AND t1.c = t2.c) with the exception that if ON is used there will be two columns a, b, and c in the result, whereas with USING there will be only one of each (and they will appear first if SELECT * is used).
Finally, NATURAL is a shorthand form of USING: it forms a USING list consisting of all column names that appear in both input tables. As with USING, these columns appear only once in the output table.
The possible types of qualified join are:
For each row R1 of T1, the joined table has a row for each row in T2 that satisfies the join condition with R1.
First, an inner join is performed. Then, for each row in T1 that does not satisfy the join condition with any row in T2, a joined row is added with null values in columns of T2. Thus, the joined table always has at least one row for each row in T1.
First, an inner join is performed. Then, for each row in T2 that does not satisfy the join condition with any row in T1, a joined row is added with null values in columns of T1. This is the converse of a left join: the result table will always have a row for each row in T2.
First, an inner join is performed. Then, for each row in T1 that does not satisfy the join condition with any row in T2, a joined row is added with null values in columns of T2. Also, for each row of T2 that does not satisfy the join condition with any row in T1, a joined row with null values in the columns of T1 is added.
Joins of all types can be chained together or nested: either or both T1 and T2 can be joined tables. Parentheses can be used around JOIN clauses to control the join order. In the absence of parentheses, JOIN clauses nest left-to-right.
To put this together, assume we have tables t1:
num | name -----+------ 1 | a 2 | b 3 | c
and t2:
num | value -----+------- 1 | xxx 3 | yyy 5 | zzz
then we get the following results for the various joins:
=> SELECT * FROM t1 CROSS JOIN t2; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 1 | a | 3 | yyy 1 | a | 5 | zzz 2 | b | 1 | xxx 2 | b | 3 | yyy 2 | b | 5 | zzz 3 | c | 1 | xxx 3 | c | 3 | yyy 3 | c | 5 | zzz (9 rows) => SELECT * FROM t1 INNER JOIN t2 ON t1.num = t2.num; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 3 | c | 3 | yyy (2 rows) => SELECT * FROM t1 INNER JOIN t2 USING (num); num | name | value -----+------+------- 1 | a | xxx 3 | c | yyy (2 rows) => SELECT * FROM t1 NATURAL INNER JOIN t2; num | name | value -----+------+------- 1 | a | xxx 3 | c | yyy (2 rows) => SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 2 | b | | 3 | c | 3 | yyy (3 rows) => SELECT * FROM t1 LEFT JOIN t2 USING (num); num | name | value -----+------+------- 1 | a | xxx 2 | b | 3 | c | yyy (3 rows) => SELECT * FROM t1 RIGHT JOIN t2 ON t1.num = t2.num; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 3 | c | 3 | yyy | | 5 | zzz (3 rows) => SELECT * FROM t1 FULL JOIN t2 ON t1.num = t2.num; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 2 | b | | 3 | c | 3 | yyy | | 5 | zzz (4 rows)
The join condition specified with ON can also contain conditions that do not relate directly to the join. This can prove useful for some queries but needs to be thought out carefully. For example:
=> SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num AND t2.value = 'xxx'; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx 2 | b | | 3 | c | | (3 rows)
Notice that placing the restriction in the WHERE clause produces a different result:
=> SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num WHERE t2.value = 'xxx'; num | name | num | value -----+------+-----+------- 1 | a | 1 | xxx (1 row)
This is because a restriction placed in the ON clause is processed before the join, while a restriction placed in the WHERE clause is processed after the join.
A temporary name can be given to tables and complex table references to be used for references to the derived table in the rest of the query. This is called a table alias.
To create a table alias, write
FROM table_reference AS alias
or
FROM table_reference alias
The AS key word is optional noise. alias can be any identifier.
A typical application of table aliases is to assign short identifiers to long table names to keep the join clauses readable. For example:
SELECT * FROM some_very_long_table_name s JOIN another_fairly_long_name a ON s.id = a.num;
The alias becomes the new name of the table reference so far as the current query is concerned — it is not allowed to refer to the table by the original name elsewhere in the query. Thus, this is not valid:
SELECT * FROM my_table AS m WHERE my_table.a > 5; -- wrong
Table aliases are mainly for notational convenience, but it is necessary to use them when joining a table to itself, e.g.:
SELECT * FROM people AS mother JOIN people AS child ON mother.id = child.mother_id;
Additionally, an alias is required if the table reference is a subquery (see Section <IP_ADDRESS>).
Parentheses are used to resolve ambiguities. In the following example, the first statement assigns the alias b to the second instance of my_table, but the second statement assigns the alias to the result of the join:
SELECT * FROM my_table AS a CROSS JOIN my_table AS b ... SELECT * FROM (my_table AS a CROSS JOIN my_table) AS b ...
Another form of table aliasing gives temporary names to the columns of the table, as well as the table itself:
FROM table_reference [AS] alias ( column1 [, column2 [, ...]] )
If fewer column aliases are specified than the actual table has columns, the remaining columns are not renamed. This syntax is especially useful for self-joins or subqueries.
When an alias is applied to the output of a JOIN clause, the alias hides the original name(s) within the JOIN. For example:
SELECT a.* FROM my_table AS a JOIN your_table AS b ON ...
is valid SQL, but:
SELECT a.* FROM (my_table AS a JOIN your_table AS b ON ...) AS c
is not valid; the table alias a is not visible outside the alias c.
Subqueries specifying a derived table must be enclosed in parentheses and must be assigned a table alias name. (See Section <IP_ADDRESS>.) For example:
FROM (SELECT * FROM table1) AS alias_name
This example is equivalent to FROM table1 AS alias_name. More interesting cases, which cannot be reduced to a plain join, arise when the subquery involves grouping or aggregation.
A subquery can also be a VALUES list:
FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow')) AS names(first, last)
Again, a table alias is required. Assigning alias names to the columns of the VALUES list is optional, but is good practice. For more information see Section 7.7.
Table functions are functions that produce a set of rows, made up of either base data types (scalar types) or composite data types (table rows). They are used like a table, view, or subquery in the FROM clause of a query. Columns returned by table functions can be included in SELECT, JOIN, or WHERE clauses in the same manner as a table, view, or subquery column.
If a table function returns a base data type, the single result column name matches the function name. If the function returns a composite type, the result columns get the same names as the individual attributes of the type.
A table function can be aliased in the FROM clause, but it also can be left unaliased. If a function is used in the FROM clause with no alias, the function name is used as the resulting table name.
Some examples:
CREATE TABLE foo (fooid int, foosubid int, fooname text); CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$ SELECT * FROM foo WHERE fooid = $1; $$ LANGUAGE SQL; SELECT * FROM getfoo(1) AS t1; SELECT * FROM foo WHERE foosubid IN ( SELECT foosubid FROM getfoo(foo.fooid) z WHERE z.fooid = foo.fooid ); CREATE VIEW vw_getfoo AS SELECT * FROM getfoo(1); SELECT * FROM vw_getfoo;
In some cases it is useful to define table functions that can return different column sets depending on how they are invoked. To support this, the table function can be declared as returning the pseudotype record. When such a function is used in a query, the expected row structure must be specified in the query itself, so that the system can know how to parse and plan the query. Consider this example:
SELECT * FROM dblink('dbname=mydb', 'SELECT proname, prosrc FROM pg_proc') AS t1(proname name, prosrc text) WHERE proname LIKE 'bytea%';
The dblink function executes a remote query (see contrib/dblink). It is declared to return record since it might be used for any kind of query. The actual column set must be specified in the calling query so that the parser knows, for example, what * should expand to.
The syntax of the WHERE Clause is
WHERE search_condition
where search_condition is any value expression (see Section 4.2) that returns a value of type boolean.
After the processing of the FROM clause is done, each row of the derived virtual table is checked against the search condition. If the result of the condition is true, the row is kept in the output table, otherwise (i.e., if the result is false or null) it is discarded. The search condition typically references at least one column of the table generated in the FROM clause; this is not required, but otherwise the WHERE clause will be fairly useless.
Note: The join condition of an inner join can be written either in the WHERE clause or in the JOIN clause. For example, these table expressions are equivalent:
FROM a, b WHERE a.id = b.id AND b.val > 5and:
FROM a INNER JOIN b ON (a.id = b.id) WHERE b.val > 5or perhaps even:
FROM a NATURAL JOIN b WHERE b.val > 5Which one of these you use is mainly a matter of style. The JOIN syntax in the FROM clause is probably not as portable to other SQL database management systems, even though it is in the SQL standard. For outer joins there is no choice: they must be done in the FROM clause. The ON or USING clause of an outer join is not equivalent to a WHERE condition, because it results in the addition of rows (for unmatched input rows) as well as the removal of rows in the final result.
Here are some examples of WHERE clauses:
SELECT ... FROM fdt WHERE c1 > 5 SELECT ... FROM fdt WHERE c1 IN (1, 2, 3) SELECT ... FROM fdt WHERE c1 IN (SELECT c1 FROM t2) SELECT ... FROM fdt WHERE c1 IN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10) SELECT ... FROM fdt WHERE c1 BETWEEN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10) AND 100 SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 > fdt.c1)
fdt is the table derived in the FROM clause. Rows that do not meet the search condition of the WHERE clause are eliminated from fdt. Notice the use of scalar subqueries as value expressions. Just like any other query, the subqueries can employ complex table expressions. Notice also how fdt is referenced in the subqueries. Qualifying c1 as fdt.c1 is only necessary if c1 is also the name of a column in the derived input table of the subquery. But qualifying the column name adds clarity even when it is not needed. This example shows how the column naming scope of an outer query extends into its inner queries.
After passing the WHERE filter, the derived input table might be subject to grouping, using the GROUP BY clause, and elimination of group rows using the HAVING clause.
SELECT select_list FROM ... [WHERE ...] GROUP BY grouping_column_reference [, grouping_column_reference]...
The GROUP BY Clause is used to group together those rows in a table that have the same values in all the columns listed. The order in which the columns are listed does not matter. The effect is to combine each set of rows having common values into one group row that represents all rows in the group. This is done to eliminate redundancy in the output and/or compute aggregates that apply to these groups. For instance:
=> SELECT * FROM test1; x | y ---+--- a | 3 c | 2 b | 5 a | 1 (4 rows) => SELECT x FROM test1 GROUP BY x; x --- a b c (3 rows)
In the second query, we could not have written SELECT * FROM test1 GROUP BY x, because there is no single value for the column y that could be associated with each group. The grouped-by columns can be referenced in the select list since they have a single value in each group.
In general, if a table is grouped, columns that are not listed in GROUP BY cannot be referenced except in aggregate expressions. An example with aggregate expressions is:
=> SELECT x, sum(y) FROM test1 GROUP BY x; x | sum ---+----- a | 4 b | 5 c | 2 (3 rows)
Here sum is an aggregate function that computes a single value over the entire group. More information about the available aggregate functions can be found in Section 9.18.
Tip: Grouping without aggregate expressions effectively calculates the set of distinct values in a column. This can also be achieved using the DISTINCT clause (see Section 7.3.3).
Here is another example: it calculates the total sales for each product (rather than the total sales of all products):
SELECT product_id, p.name, (sum(s.units) * p.price) AS sales FROM products p LEFT JOIN sales s USING (product_id) GROUP BY product_id, p.name, p.price;
In this example, the columns product_id, p.name, and p.price must be in the GROUP BY clause since they are referenced in the query select list. (Depending on how the products table is set up, name and price might be fully dependent on the product ID, so the additional groupings could theoretically be unnecessary, though this is not implemented.) The column s.units does not have to be in the GROUP BY list since it is only used in an aggregate expression (sum(...)), which represents the sales of a product. For each product, the query returns a summary row about all sales of the product.
In strict SQL, GROUP BY can only group by columns of the source table but PostgreSQL extends this to also allow GROUP BY to group by columns in the select list. Grouping by value expressions instead of simple column names is also allowed.
If a table has been grouped using GROUP BY, but only certain groups are of interest, the HAVING clause can be used, much like a WHERE clause, to eliminate groups from the result. The syntax is:
SELECT select_list FROM ... [WHERE ...] GROUP BY ... HAVING boolean_expression
Expressions in the HAVING clause can refer both to grouped expressions and to ungrouped expressions (which necessarily involve an aggregate function).
Example:
=> SELECT x, sum(y) FROM test1 GROUP BY x HAVING sum(y) > 3; x | sum ---+----- a | 4 b | 5 (2 rows) => SELECT x, sum(y) FROM test1 GROUP BY x HAVING x < 'c'; x | sum ---+----- a | 4 b | 5 (2 rows)
Again, a more realistic example:
SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit FROM products p LEFT JOIN sales s USING (product_id) WHERE s.date > CURRENT_DATE - INTERVAL '4 weeks' GROUP BY product_id, p.name, p.price, p.cost HAVING sum(p.price * s.units) > 5000;
In the example above, the WHERE clause is selecting rows by a column that is not grouped (the expression is only true for sales during the last four weeks), while the HAVING clause restricts the output to groups with total gross sales over 5000. Note that the aggregate expressions do not necessarily need to be the same in all parts of the query.
If a query contains aggregate function calls, but no GROUP BY clause, grouping still occurs: the result is a single group row (or perhaps no rows at all, if the single row is then eliminated by HAVING). The same is true if it contains a HAVING clause, even without any aggregate function calls or GROUP BY clause.
If the query contains any window functions (see Section 3.5, Section 9.19 and Section 4.2.8), these functions are evaluated after any grouping, aggregation, and HAVING filtering is performed. That is, if the query uses any aggregates, GROUP BY, or HAVING, then the rows seen by the window functions are the group rows instead of the original table rows from FROM/WHERE.
When multiple window functions are used, all the window functions having syntactically equivalent PARTITION BY and ORDER BY clauses in their window definitions are guaranteed to be evaluated in a single pass over the data. Therefore they will see the same sort ordering, even if the ORDER BY does not uniquely determine an ordering. However, no guarantees are made about the evaluation of functions having different PARTITION BY or ORDER BY specifications. (In such cases a sort step is typically required between the passes of window function evaluations, and the sort is not guaranteed to preserve ordering of rows that its ORDER BY sees as equivalent.)
Currently, window functions always require presorted data, and so the query output will be ordered according to one or another of the window functions' PARTITION BY/ORDER BY clauses. It is not recommendable to rely on this, however. Use an explicit top-level ORDER BY clause if you want to be sure the results are sorted in a particular way.


| 1068 | (A) | and sayde allas in this lyfe how lange schałł we lenge |
| 1072 | (C) | Alas þey seyde in þis lyfe . how longe schałł we lyfe |
| 1055 | (D) | & seyd alas in þis lyf how long shul we dure |
| 1035 | (E) | & seyde alaas in this lyf . how longe schal we dure |
| (Ex) | ---- no text ---- | |
| 1093 | (L) | & sayn a-las in þis lif how longe schul we dwelle |
| 1007 | (P) | ? ?? ???? ???? ?? ??? ??? ??? ????? sałł we ???? |
| 1044 | (U) | Said allas in this lyf / how longe shal we duren |
| 133 | (V) | And said allas in þis liffe . howe longe shułł we dwelle |


| Week 1 | |
|---|---|
| T 8-27 | Welcome to the course! Intro to science fiction and H. G. Wells. Introduce Project 1 and set up Hypothes.is accounts. Context:
|
| H 8-29 | Read H. G. Wells, War of the Worlds, Book I, Ch. I through Ch. VIII., pp. 41-68 Slides: |
| Week 2 | |
|---|---|
| T 9-03 | War of the Worlds, to the end of Book II Ch. III (to p. 154). |
| H 9-05 | Finish War of the Worlds. Finish Hypothes.is annotations for Digital Project 1. In class: introduce Digital Project 2 (Note: Add/drop period ends F 9-06.) |
| Week 3 | |
|---|---|
| T 9-10 | Before class:
Context: Slides: Background and Concepts in Do Androids Dream of Electric Sheep? Introduce DADES Discussion Assignment on Courseweb (counts in Quizzes portion of grade). |
| H 9-12 | Do Androids Dream of Electric Sheep? Chs. 5-13 (to p. 153) |
| Week 4 | |
|---|---|
| T 9-17 | Reading/online discussion day. Work on your own on Digital Project 2 (due Tuesday 9/24). |
| H 9-19 | In class: discuss ending of Do Androids Dream of Electric Sheep?. Post last contributions to online threaded discussions. |
| Week 5 | |
|---|---|
| T 9-24 | For class: Read Alan Moore, Watchmen, to the end of Ch. III (including the prose segments at the ends of the chapters) Intro slides on Watchmen and the history of comics and graphic novels By 11:59pm: Complete, export and submit Digital Project 2 (as mp3 file) |
| H 9-26 |
Watchmen, to the end of Ch. VI
|
| Week 6 | |
|---|---|
| T 10-01 | Watchmen through Chapter IX. In class: Watchmen Analysis Exercise |
| H 10-03 | Finish Watchmen. Watchmen: “in the final analysis” Context Slides: Alien Invasions, Pulp Comics, and Watchmen Start Margaret Atwood, The Handmaid’s Tale Chs. I - III (to p. 40) |
| Week 7 | |
|---|---|
| T 10-08 |
The Handmaid’s Tale Chs. IV - VII (to p. 106) Context Slides: The Handmaid’s Tale Digital Project 3 due. |
| H 10-10 | The Handmaid’s Tale Chs. VIII - X (to p. 188) |
| Week 8 | |
|---|---|
| T 10-15 | The Handmaid’s Tale Chs. XI- XII (to p. 255). Introduce Digital Project 4. |
| H 10-17 | Finish The Handmaid’s Tale including the |
| Week 9 | |
|---|---|
| T 10-22 | Octavia Butler, Lilith’s Brood: Dawn, Part I, pp. 5 - 44. Watch together: Star Trek Season 5 Episode 3: Take-home Midterm Exam due by 11:59pm. |
| H 10-24 | Lilith’s Brood: Dawn, Part II just up to p. 112. Context Slides: Octavia Butler, Science Fiction, and Lilith's Brood |
| Week 10 | |
|---|---|
| T 10-29 | Lilith’s Brood: Adulthood Rites: Part II (Phoenix) through Ch. 9 (pp. 313-417) |
| H 10-31 | Finish Lilith’s Brood: Adulthood Rites (pp. 421-477) + last two chapters of Lilith’s Brood: Imago, pp. 741-746. |
| Week 11 | |
|---|---|
| T 11-05 | Digital Project 4: Complete Kumu network visualizations and make sure all links are recorded and updated. |
| H 11-07 | Start Neal Stephenson, Snow Crash, Chs. 1-8. |
| Week 12 | |
|---|---|
| T 11-12 | **Reading Day** (no class meeting). Continue reading Snow Crash, Chs. 9-20 Digital Project 4 Essay due (by 11:59pm) on Courseweb. |
| H 11-14 | Snow Crash, Chs. 21-35. Dr. B’s Guide to Human-Computer Fusions in Snow Crash |
| Week 13 | |
|---|---|
| T 11-19 | Snow Crash, Chs. 36-45. Introduce Digital Project 5. |
| H 11-21 | Snow Crash, Chs. 46-56. Start indie science fiction game analysis via https://itch.io. |
| Week 14: | |
|---|---|
| T 11-26 - H 11/28 | Thanksgiving break |
| Week 15 | |
|---|---|
| T 12-03 | Finish Snow Crash. Games as SF narration and world development: Work on and share indie science fiction game analysis |
| H 12-05 | Last day: Conclude class exercise on indie science fiction game analysis. Finish visualization for Digital Project 5. Initiate Optional Take-Home Final Exam. |
| Finals Week | |
|---|---|
|


doctype html html head body h1 Application Documentaion ul each page in locals.pages li a(href= 'pages/' + page +'.html')= page


Example: Default
This tree uses default options.
It is initialized from a hidden <ul> element on this page.
Skin:
jquery.fancytree.js project home
Link to this page
Example Browser
View source code


You want to be a big God.
All of the Tiny Worlds are misbehaving. It's time to destroy them all.
Tiny God is a turn-based game.
Click on Tiny Worlds so that you can cause miracles and expand your total belief.
As your belief expands, you can continue on to bigger worlds. Over time, belief in your miracles subsides, so you must go back to previous worlds where you performed miracles.
Press h anytime for help.
Tiny God is a turn-based game. Click on Tiny Worlds so that you can cause miracles and expand your total belief. As your belief expands, you can continue on to bigger worlds. Over time, belief in your miracles subsides, so you must go back to previous worlds where you performed miracles.
Press h anytime for help


All connection only with 500 bits. We can help you build better websites and running in no time. We coding with love these days!
I was set up by KINH LUÂN.
He's a software engineer living on the Ho Chi Minh City/ Vietnam.


{% extends "main.html" %}
{% block body %}
If you wish to get in touch with us to discuss one or more variants found in our beacon please write and email to
Chiara Rasi.
We can't disclose sensitive information on the search engine,
but we can put you in contact with the researcher/clinician who uploaded the case.


Add Model Metadata
If you are a Standard Development Organization (SDO), an open source project, or an organization such as a vendor that creates proprietary models,
and you want to add your models' metadata to the Catalog, do the following. NOTE: the Catalog is not a clearing house for model
downloads. While it provides metadata about models, it only provides links to external sites from which the models themselves can be download.
- Check your modules into GitHub. Ideally submit your modules directly to the
https://github.com/YangModels/yang repository via a pull request. Alternatively, you can use any public repository, and then also add a git sub-module to the
https://github.com/YangModels/yang repository via a pull request.
- Request a new YANG Catalog API account if you do not have one already.
- Once the account is requested, wait until confirmation before proceeding.
- Use an HTTP PUT request to https://yangcatalog.org/api/modules with a JSON payload modeled after the
model-metadata.yang model (current revision: 2017-07-27). Note, this module requires the
yang-catalog module. The module-metadata.yang has the following tree structure:
module: module-metadata
+--rw modules
+--rw module* [name revision organization]
+--rw name yang:yang-identifier
+--rw revision union
+--rw generated-from? enumeration
+--rw maturity-level? enumeration
+--rw document-name? string
+--rw author-email? yc:email-address
+--rw reference? inet:uri
+--rw module-classification enumeration
+--rw organization string
+--rw ietf
| +--rw ietf-wg? string
+--rw source-file
+--rw owner string
+--rw repository string
+--rw path path
+--rw branch? string
For example:
PUT https://yangcatalog.org/api/modules
Content-type: application/json
{
"modules": {
"module": [
{
"name": "example-jukebox",
"revision": "2014-01-20",
"organization": "example",
"maturity-level": "ratified",
"author-email"<EMAIL_ADDRESS>"module-classification": "network-element",
"source-file": {
"repository": "foo",
"owner": "bar",
"path": "standard/ietf/DRAFT/example-jukebox.yang"
}
}
]
}
}
- After submitting the request, if you are authorized, you will receive a job ID in the JSON-formatted reply. For example:
{
"info": "Verification successful",
"job-id": "88bd8c4c-8809-4de8-85c8-39d522d4bcdf"
}
- Perform an HTTP GET request to https://yangcatalog.org/api/job/{job_id} to get the status of the job. The job result will remain "In progress" until the job completes. When the job has completed you will receive either a "Finished"
(on success) or "Failed" (on failure) result. Reason will remain null if the result is other then "Failed, otherwise it will give a information on why it failed. For example, after obtaining the job ID above, perform an HTTP GET to https://yangcatalog.org/api/job/88bd8c4c-8809-4de8-85c8-39d522d4bcdf to get the current status:
{
"info": {
"job-id": "88bd8c4c-8809-4de8-85c8-39d522d4bcdf",
"reason": null,
"result": "In progress"
}
}
- Once the job has completed successfully, test the result by querying the search API.
- Contact<EMAIL_ADDRESS>if you run into problems.
While some metadata can be extracted from models by the API backend (these are called extractable fields), metadata such as "maturity-level" and "conformance-type" must be provided by the model creator (these are the non-extractable fields). The reason the module-metadata model is broken out from the main yang-catalog module is to focus more on the non-extractable fields. The more metadata from the module-metadata model that can be included the more robust and detailed
the Catalog will be.
Add Implementation Metadata
If you are a vendor that implements YANG models in your product, then you can upload platform metadata to the Catalog in order to specify what platforms (and software releases) implement which YANG models. This is done using the following
steps:
- Request a new YANG Catalog API account if you do not have one already.
- Once the account is requested, wait until confirmation before proceeding.
- Use an HTTP PUT request to https://yangcatalog.org/api/platforms with a JSON payload modeled after the
platform-implementation-metadata.yang model (current revision: 2017-09-27). Note, his module requires the
yang-catalog module. The platform-implementation-metadata module has the following tree structure:
module: platform-implementation-metadata
+--rw platforms
+--rw platform* [vendor name software-version software-flavor]
+--rw vendor string
+--rw name string
+--rw netconf-capabilities* string
+--rw product-ids* string
+--rw software-version string
+--rw software-flavor string
+--rw os-version? string
+--rw feature-set? string
+--rw os-type? string
+--rw module-list-file
+--rw type? enumeration
+--rw owner string
+--rw repository string
+--rw path yc:path
+--rw branch? string
For example:
PUT https://yangcatalog.org/api/platforms
Content-type: application/json
{
"platforms" {
"platform": [
{
"vendor": "example",
"name": "baz",
"module-list-file": {
"type": "capabilities",
"repository": "foo",
"owner": "bar",
"path": "vendor/example/baz/baz-netconf-capability.xml"
},
"platform-ids": [
"BAZ4000", "BAZ4100"
],
"software-flavor": "ALL",
"software-version": "1.2.3",
"os-type": "bazOS"
}
]
}
}
- After submitting the request, if you are authorized, you will receive a job ID in the JSON-formatted reply. For example:
{
"info": "Verification successful",
"job-id": "88bd8c4c-8809-4de8-85c8-39d522d4bcdf"
}
- Perform an HTTP GET request to https://yangcatalog.org/api/job/{job_id} to get the status of the job. The job result will remain "In progress" until the job completes. When the job has completed you will receive either a "Finished"
(on success) or "Failed" (on failure) result. For example, after obtaining the job ID above, perform an HTTP GET to https://yangcatalog.org/api/job/88bd8c4c-8809-4de8-85c8-39d522d4bcdf to get the current status:
{
"info": {
"job-id": "88bd8c4c-8809-4de8-85c8-39d522d4bcdf",
"reason": null,
"result": "In progress"
}
}
- Once the job has completed successfully, test the result by querying the search API.
- Contact<EMAIL_ADDRESS>if you run into problems.
Get Module and Implementation Metadata
If you want to search for metadata on a specific module, or you are looking for modules that contain specific metadata, you can do the following:
- Use an HTTP GET request to
https://yangcatalog.org/api/search/modules/{name},{revision},{organization} to receive all the metadata for a specific module and revision.
- Use an HTTP GET request to
https://yangcatalog.org/api/search/{key}/{value} to receive all the modules that contain a specific metadata.
For example, to find all modules with a successful compilation status:
https://yangcatalog.org/api/search/compilation-status/passed
To find all modules from the netconf working group in the IETF:
https://yangcatalog.org/api/search/ietf/ietf-wg/netconf
This method will work for any node within the
yang-catalog:
+--rw catalog
+--rw modules
| +--rw module* [name revision organization]
| +--rw name yang:yang-identifier
| +--rw revision union
| +--rw organization string
| +--rw ietf
| | +--rw ietf-wg? string
| +--rw namespace inet:uri
| +--rw schema? inet:uri
| +--rw generated-from? enumeration
| +--rw maturity-level? enumeration
| +--rw document-name? string
| +--rw author-email? yc:email-address
| +--rw reference? inet:uri
| +--rw module-classification enumeration
| +--rw compilation-status? enumeration
| +--rw compilation-result? inet:uri
| +--rw prefix? string
| +--rw yang-version? enumeration
| +--rw description? string
| +--rw contact? string
| +--rw module-type? enumeration
| +--rw belongs-to? yang:yang-identifier
| +--rw tree-type? enumeration
| +--rw submodule* [name revision]
| | +--rw name yang:yang-identifier
| | +--rw revision union
| | +--rw schema? inet:uri
| +--rw dependencies* [name]
| | +--rw name yang:yang-identifier
| | +--rw revision? union
| | +--rw schema? inet:uri
| +--rw dependents* [name]
| | +--rw name yang:yang-identifier
| | +--rw revision? union
| | +--rw schema? inet:uri
| +--rw semantic-version? yc:semver
| +--rw derived-semantic-version? yc:semver
| +--rw implementations
| +--rw implementation* [vendor platform software-version software-flavor]
| +--rw vendor string
| +--rw platform string
| +--rw software-version string
| +--rw software-flavor string
| +--rw os-version? string
| +--rw feature-set? string
| +--rw os-type? string
| +--rw feature* yang:yang-identifier
| +--rw deviation* [name revision]
| | +--rw name yang:yang-identifier
| | +--rw revision union
| +--rw conformance-type? enumeration
+--rw vendors
+--rw vendor* [name]
+--rw name string
+--rw platforms
+--rw platform* [name]
+--rw name string
+--rw software-versions
+--rw software-version* [name]
+--rw name string
+--rw software-flavors
+--rw software-flavor* [name]
+--rw name string
+--rw protocols
| +--rw protocol* [name]
| +--rw name identityref
| +--rw protocol-version* string
| +--rw capabilities* string
+--rw modules
+--rw module* [name revision organization]
+--rw name -> /catalog/modules/module/name
+--rw revision -> /catalog/modules/module/revision
+--rw organization -> /catalog/modules/module/organization
+--rw os-version? string
+--rw feature-set? string
+--rw os-type? string
+--rw feature* yang:yang-identifier
+--rw deviation* [name revision]
| +--rw name yang:yang-identifier
| +--rw revision union
+--rw conformance-type? enumeration
Delete Module Metadata
If you need to delete metadata relative to one of your specific modules, do the following:
- Request a new YANG Catalog API account if you do not have one already.
- Once the account is requested, wait until confirmation before proceeding.
- Use an HTTP DELETE request to delete specific module
https://yangcatalog.org/api/modules/module/{name},{revision},{organization}
- Use an HTTP DELETE request to delete modules on specific implementation metadata
https://yangcatalog.org/api/vendors/vendor/{name}.
You can continue deeper on the vendors branch up to software-flavor
NOTE: Deleting implementation metadata is currently not possible.
Hacking Yangcatalog.org
All of the code behind yangcatalog.org is Open Source. However, it is spread out across multiple
GitHub repositories. If you are interested in hacking the code that directly drives the YANG Catalog, pick your repository from the list below:
In order to contribute back to YANG Catalog, checkout one of the repositories, make your changes, and then create a
pull request to have your code merged.
To get updates about changes with YANG Catalog, subscribe
to<EMAIL_ADDRESS>Download a YangCatalog postman collection
here to
explore the API with examples.


Public Types | |
Public constants | |
| enum | ValSchemes { Val_Never, Val_Always, Val_Auto } |
| ValScheme enum used in setValidationScheme Val_Never: Do not report validation errors. More... | |
Public Member Functions | |
Constructors and Destructor | |
| SAX2XMLReader () | |
| The default constructor. | |
| virtual | ~SAX2XMLReader () |
| The destructor. | |
Implementation of SAX 2.0 XMLReader interface's. | |
| virtual ContentHandler * | getContentHandler () const =0 |
| This method returns the installed content handler. | |
| virtual DTDHandler * | getDTDHandler () const =0 |
| This method returns the installed DTD handler. | |
| virtual EntityResolver * | getEntityResolver () const =0 |
| This method returns the installed entity resolver. | |
| virtual ErrorHandler * | getErrorHandler () const =0 |
| This method returns the installed error handler. | |
| virtual bool | getFeature (const XMLCh *const name) const =0 |
| Query the current state of any feature in a SAX2 XMLReader. | |
| virtual void * | getProperty (const XMLCh *const name) const =0 |
| Query the current value of a property in a SAX2 XMLReader. | |
| virtual void | setContentHandler (ContentHandler *const handler)=0 |
| Allow an application to register a document event handler. | |
| virtual void | setDTDHandler (DTDHandler *const handler)=0 |
| Allow an application to register a DTD event handler. | |
| virtual void | setEntityResolver (EntityResolver *const resolver)=0 |
| Allow an application to register a custom entity resolver. | |
| virtual void | setErrorHandler (ErrorHandler *const handler)=0 |
| Allow an application to register an error event handler. | |
| virtual void | setFeature (const XMLCh *const name, const bool value)=0 |
| Set the state of any feature in a SAX2 XMLReader. | |
| virtual void | setProperty (const XMLCh *const name, void *value)=0 |
| Set the value of any property in a SAX2 XMLReader. | |
| virtual void | parse (const InputSource &source)=0 |
| Parse an XML document. | |
| virtual void | parse (const XMLCh *const systemId)=0 |
| Parse an XML document from a system identifier (URI). | |
| virtual void | parse (const char *const systemId)=0 |
| Parse an XML document from a system identifier (URI). | |
SAX 2.0-ext | |
| virtual DeclHandler * | getDeclarationHandler () const =0 |
| This method returns the installed declaration handler. | |
| virtual LexicalHandler * | getLexicalHandler () const =0 |
| This method returns the installed lexical handler. | |
| virtual void | setDeclarationHandler (DeclHandler *const handler)=0 |
| Allow an application to register a declaration event handler. | |
| virtual void | setLexicalHandler (LexicalHandler *const handler)=0 |
| Allow an application to register a lexical event handler. | |
Getter Methods (Xerces-C specific) | |
| virtual XMLValidator * | getValidator () const =0 |
| This method is used to get the current validator. | |
| virtual XMLSize_t | getErrorCount () const =0 |
| Get error count from the last parse operation. | |
| virtual bool | getExitOnFirstFatalError () const =0 |
| This method returns the state of the parser's exit-on-First-Fatal-Error flag. | |
| virtual bool | getValidationConstraintFatal () const =0 |
| This method returns the state of the parser's validation-constraint-fatal flag. | |
| virtual Grammar * | getGrammar (const XMLCh *const nameSpaceKey)=0 |
| Retrieve the grammar that is associated with the specified namespace key. | |
| virtual Grammar * | getRootGrammar ()=0 |
| Retrieve the grammar where the root element is declared. | |
| virtual const XMLCh * | getURIText (unsigned int uriId) const =0 |
| Returns the string corresponding to a URI id from the URI string pool. | |
| virtual XMLFilePos | getSrcOffset () const =0 |
| Returns the current src offset within the input source. | |
Setter Methods (Xerces-C specific) | |
| virtual void | setValidator (XMLValidator *valueToAdopt)=0 |
| This method is used to set a validator. | |
| virtual void | setExitOnFirstFatalError (const bool newState)=0 |
| This method allows users to set the parser's behaviour when it encounters the first fatal error. | |
| virtual void | setValidationConstraintFatal (const bool newState)=0 |
| This method allows users to set the parser's behaviour when it encounters a validation constraint error. | |
Progressive scan methods | |
| virtual bool | parseFirst (const XMLCh *const systemId, XMLPScanToken &toFill)=0 |
| Begin a progressive parse operation. | |
| virtual bool | parseFirst (const char *const systemId, XMLPScanToken &toFill)=0 |
| Begin a progressive parse operation. | |
| virtual bool | parseFirst (const InputSource &source, XMLPScanToken &toFill)=0 |
| Begin a progressive parse operation. | |
| virtual bool | parseNext (XMLPScanToken &token)=0 |
| Continue a progressive parse operation. | |
| virtual void | parseReset (XMLPScanToken &token)=0 |
| Reset the parser after a progressive parse. | |
Grammar preparsing interface's. | |
| virtual Grammar * | loadGrammar (const InputSource &source, const Grammar::GrammarType grammarType, const bool toCache=false)=0 |
| Preparse schema grammar (XML Schema, DTD, etc. | |
| virtual Grammar * | loadGrammar (const XMLCh *const systemId, const Grammar::GrammarType grammarType, const bool toCache=false)=0 |
| Preparse schema grammar (XML Schema, DTD, etc. | |
| virtual Grammar * | loadGrammar (const char *const systemId, const Grammar::GrammarType grammarType, const bool toCache=false)=0 |
| Preparse schema grammar (XML Schema, DTD, etc. | |
| virtual void | resetCachedGrammarPool ()=0 |
| Clear the cached grammar pool. | |
| virtual void | setInputBufferSize (const XMLSize_t bufferSize) |
| Set maximum input buffer size. | |
Advanced document handler list maintenance methods | |
| virtual void | installAdvDocHandler (XMLDocumentHandler *const toInstall)=0 |
| This method installs the specified 'advanced' document callback handler, thereby allowing the user to customize the processing, if they choose to do so. | |
| virtual bool | removeAdvDocHandler (XMLDocumentHandler *const toRemove)=0 |
| This method removes the 'advanced' document handler callback from the underlying parser scanner. |
ValScheme enum used in setValidationScheme Val_Never: Do not report validation errors.
Val_Always: The parser will always report validation errors. Val_Auto: The parser will report validation errors only if a grammar is specified.
The schemes map to these feature values: Val_Never: parser->setFeature(XMLUni::fgSAX2CoreValidation, false);
Val_Always: parser->setFeature(XMLUni::fgSAX2CoreValidation, true); parser->setFeature(XMLUni::fgXercesDynamic, false);
Val_Auto: parser->setFeature(XMLUni::fgSAX2CoreValidation, true); parser->setFeature(XMLUni::fgXercesDynamic, true);
| SAX2XMLReader::SAX2XMLReader | ( | ) |
The default constructor.
| virtual SAX2XMLReader::~SAX2XMLReader | ( | ) | [virtual] |
The destructor.
| virtual ContentHandler* SAX2XMLReader::getContentHandler | ( | ) | const [pure virtual] |
This method returns the installed content handler.
| virtual DTDHandler* SAX2XMLReader::getDTDHandler | ( | ) | const [pure virtual] |
This method returns the installed DTD handler.
| virtual EntityResolver* SAX2XMLReader::getEntityResolver | ( | ) | const [pure virtual] |
This method returns the installed entity resolver.
| virtual ErrorHandler* SAX2XMLReader::getErrorHandler | ( | ) | const [pure virtual] |
This method returns the installed error handler.
| virtual bool SAX2XMLReader::getFeature | ( | const XMLCh *const | name | ) | const [pure virtual] |
Query the current state of any feature in a SAX2 XMLReader.
| name | The unique identifier (URI) of the feature being set. |
| SAXNotRecognizedException | If the requested feature is not known. |
| virtual void* SAX2XMLReader::getProperty | ( | const XMLCh *const | name | ) | const [pure virtual] |
Query the current value of a property in a SAX2 XMLReader.
The parser owns the returned pointer. The memory allocated for the returned pointer will be destroyed when the parser is deleted.
To ensure accessibility of the returned information after the parser is deleted, callers need to copy and store the returned information somewhere else; otherwise you may get unexpected result. Since the returned pointer is a generic void pointer, see the SAX2 Programming Guide to learn exactly what type of property value each property returns for replication.
| name | The unique identifier (URI) of the property being set. |
| SAXNotRecognizedException | If the requested property is not known. |
| virtual void SAX2XMLReader::setContentHandler | ( | ContentHandler *const | handler | ) | [pure virtual] |
Allow an application to register a document event handler.
If the application does not register a document handler, all document events reported by the SAX parser will be silently ignored (this is the default behaviour implemented by HandlerBase).
Applications may register a new or different handler in the middle of a parse, and the SAX parser must begin using the new handler immediately.
| handler | The document handler. |
| virtual void SAX2XMLReader::setDTDHandler | ( | DTDHandler *const | handler | ) | [pure virtual] |
Allow an application to register a DTD event handler.
If the application does not register a DTD handler, all DTD events reported by the SAX parser will be silently ignored (this is the default behaviour implemented by HandlerBase).
Applications may register a new or different handler in the middle of a parse, and the SAX parser must begin using the new handler immediately.
| handler | The DTD handler. |
| virtual void SAX2XMLReader::setEntityResolver | ( | EntityResolver *const | resolver | ) | [pure virtual] |
Allow an application to register a custom entity resolver.
If the application does not register an entity resolver, the SAX parser will resolve system identifiers and open connections to entities itself (this is the default behaviour implemented in DefaultHandler).
Applications may register a new or different entity resolver in the middle of a parse, and the SAX parser must begin using the new resolver immediately.
| resolver | The object for resolving entities. |
| virtual void SAX2XMLReader::setErrorHandler | ( | ErrorHandler *const | handler | ) | [pure virtual] |
Allow an application to register an error event handler.
If the application does not register an error event handler, all error events reported by the SAX parser will be silently ignored, except for fatalError, which will throw a SAXException (this is the default behaviour implemented by HandlerBase).
Applications may register a new or different handler in the middle of a parse, and the SAX parser must begin using the new handler immediately.
| handler | The error handler. |
| virtual void SAX2XMLReader::setFeature | ( | const XMLCh *const | name, | |
| const bool | value | |||
| ) | [pure virtual] |
Set the state of any feature in a SAX2 XMLReader.
Supported features in SAX2 for xerces-c are:
(See the SAX2 Programming Guide for detail description).
http://xml.org/sax/features/validation (default: true)
http://xml.org/sax/features/namespaces (default: true)
http://xml.org/sax/features/namespace-prefixes (default: false)
http://apache.org/xml/features/validation/dynamic (default: false)
http://apache.org/xml/features/validation/reuse-grammar (default: false)
http://apache.org/xml/features/validation/schema (default: true)
http://apache.org/xml/features/validation/schema-full-checking (default: false)
http://apache.org/xml/features/validating/load-schema (default: true)
http://apache.org/xml/features/nonvalidating/load-external-dtd (default: true)
http://apache.org/xml/features/continue-after-fatal-error (default: false)
http://apache.org/xml/features/validation-error-as-fatal (default: false)
| name | The unique identifier (URI) of the feature. | |
| value | The requested state of the feature (true or false). |
| SAXNotRecognizedException | If the requested feature is not known. | |
| SAXNotSupportedException | Feature modification is not supported during parse |
| virtual void SAX2XMLReader::setProperty | ( | const XMLCh *const | name, | |
| void * | value | |||
| ) | [pure virtual] |
Set the value of any property in a SAX2 XMLReader.
Supported properties in SAX2 for xerces-c are:
(See the SAX2 Programming Guide for detail description).
http://apache.org/xml/properties/schema/external-schemaLocation
http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation.
It takes a void pointer as the property value. Application is required to initialize this void pointer to a correct type. See the SAX2 Programming Guide to learn exactly what type of property value each property expects for processing. Passing a void pointer that was initialized with a wrong type will lead to unexpected result. If the same property is set more than once, the last one takes effect.
| name | The unique identifier (URI) of the property being set. | |
| value | The requested value for the property. See the SAX2 Programming Guide to learn exactly what type of property value each property expects for processing. Passing a void pointer that was initialized with a wrong type will lead to unexpected result. |
| SAXNotRecognizedException | If the requested property is not known. | |
| SAXNotSupportedException | Property modification is not supported during parse |
| virtual void SAX2XMLReader::parse | ( | const InputSource & | source | ) | [pure virtual] |
Parse an XML document.
The application can use this method to instruct the SAX parser to begin parsing an XML document from any valid input source (a character stream, a byte stream, or a URI).
Applications may not invoke this method while a parse is in progress (they should create a new Parser instead for each additional XML document). Once a parse is complete, an application may reuse the same Parser object, possibly with a different input source.
| source | The input source for the top-level of the XML document. |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. |
| virtual void SAX2XMLReader::parse | ( | const XMLCh *const | systemId | ) | [pure virtual] |
Parse an XML document from a system identifier (URI).
This method is a shortcut for the common case of reading a document from a system identifier. It is the exact equivalent of the following:
parse(new URLInputSource(systemId));
If the system identifier is a URL, it must be fully resolved by the application before it is passed to the parser.
| systemId | The system identifier (URI). |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. |
| virtual void SAX2XMLReader::parse | ( | const char *const | systemId | ) | [pure virtual] |
Parse an XML document from a system identifier (URI).
This method is a shortcut for the common case of reading a document from a system identifier. It is the exact equivalent of the following:
parse(new URLInputSource(systemId));
If the system identifier is a URL, it must be fully resolved by the application before it is passed to the parser.
| systemId | The system identifier (URI). |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. |
| virtual DeclHandler* SAX2XMLReader::getDeclarationHandler | ( | ) | const [pure virtual] |
This method returns the installed declaration handler.
| virtual LexicalHandler* SAX2XMLReader::getLexicalHandler | ( | ) | const [pure virtual] |
This method returns the installed lexical handler.
| virtual void SAX2XMLReader::setDeclarationHandler | ( | DeclHandler *const | handler | ) | [pure virtual] |
Allow an application to register a declaration event handler.
If the application does not register a declaration handler, all events reported by the SAX parser will be silently ignored. (this is the default behaviour implemented by DefaultHandler).
Applications may register a new or different handler in the middle of a parse, and the SAX parser must begin using the new handler immediately.
| handler | The DTD declaration handler. |
| virtual void SAX2XMLReader::setLexicalHandler | ( | LexicalHandler *const | handler | ) | [pure virtual] |
Allow an application to register a lexical event handler.
If the application does not register a lexical handler, all events reported by the SAX parser will be silently ignored. (this is the default behaviour implemented by HandlerBase).
Applications may register a new or different handler in the middle of a parse, and the SAX parser must begin using the new handler immediately.
| handler | The error handler. |
| virtual XMLValidator* SAX2XMLReader::getValidator | ( | ) | const [pure virtual] |
This method is used to get the current validator.
SAX2XMLReader assumes responsibility for the validator. It will be deleted when the XMLReader is destroyed.
| virtual XMLSize_t SAX2XMLReader::getErrorCount | ( | ) | const [pure virtual] |
Get error count from the last parse operation.
This method returns the error count from the last parse operation. Note that this count is actually stored in the scanner, so this method simply returns what the scanner reports.
| virtual bool SAX2XMLReader::getExitOnFirstFatalError | ( | ) | const [pure virtual] |
This method returns the state of the parser's exit-on-First-Fatal-Error flag.
Or you can query the feature "http://apache.org/xml/features/continue-after-fatal-error" which indicates the opposite state.
| virtual bool SAX2XMLReader::getValidationConstraintFatal | ( | ) | const [pure virtual] |
This method returns the state of the parser's validation-constraint-fatal flag.
Or you can query the feature "http://apache.org/xml/features/validation-error-as-fatal" which means the same thing.
| virtual Grammar* SAX2XMLReader::getGrammar | ( | const XMLCh *const | nameSpaceKey | ) | [pure virtual] |
Retrieve the grammar that is associated with the specified namespace key.
| nameSpaceKey | Namespace key |
| virtual Grammar* SAX2XMLReader::getRootGrammar | ( | ) | [pure virtual] |
Retrieve the grammar where the root element is declared.
| virtual const XMLCh* SAX2XMLReader::getURIText | ( | unsigned int | uriId | ) | const [pure virtual] |
Returns the string corresponding to a URI id from the URI string pool.
| uriId | id of the string in the URI string pool. |
| virtual XMLFilePos SAX2XMLReader::getSrcOffset | ( | ) | const [pure virtual] |
Returns the current src offset within the input source.
To be used only while parsing is in progress.
| virtual void SAX2XMLReader::setValidator | ( | XMLValidator * | valueToAdopt | ) | [pure virtual] |
This method is used to set a validator.
SAX2XMLReader assumes responsibility for the validator. It will be deleted when the XMLReader is destroyed.
| valueToAdopt | A pointer to the validator that the reader should use. |
| virtual void SAX2XMLReader::setExitOnFirstFatalError | ( | const bool | newState | ) | [pure virtual] |
This method allows users to set the parser's behaviour when it encounters the first fatal error.
If set to true, the parser will exit at the first fatal error. If false, then it will report the error and continue processing.
The default value is 'true' and the parser exits on the first fatal error.
Or you can set the feature "http://apache.org/xml/features/continue-after-fatal-error" which has the opposite behaviour.
If both the feature above and this function are used, the latter takes effect.
| newState | The value specifying whether the parser should continue or exit when it encounters the first fatal error. |
| virtual void SAX2XMLReader::setValidationConstraintFatal | ( | const bool | newState | ) | [pure virtual] |
This method allows users to set the parser's behaviour when it encounters a validation constraint error.
If set to true, and the the parser will treat validation error as fatal and will exit depends on the state of "getExitOnFirstFatalError". If false, then it will report the error and continue processing.
Note: setting this true does not mean the validation error will be printed with the word "Fatal Error". It is still printed as "Error", but the parser will exit if "setExitOnFirstFatalError" is set to true.
The default value is 'false'.
Or you can set the feature "http://apache.org/xml/features/validation-error-as-fatal" which means the same thing.
If both the feature above and this function are used, the latter takes effect.
| newState | If true, the parser will exit if "setExitOnFirstFatalError" is set to true. |
| virtual bool SAX2XMLReader::parseFirst | ( | const XMLCh *const | systemId, | |
| XMLPScanToken & | toFill | |||
| ) | [pure virtual] |
Begin a progressive parse operation.
This method is used to start a progressive parse on a XML file. To continue parsing, subsequent calls must be to the parseNext method.
It scans through the prolog and returns a token to be used on subsequent scanNext() calls. If the return value is true, then the token is legal and ready for further use. If it returns false, then the scan of the prolog failed and the token is not going to work on subsequent scanNext() calls.
| systemId | A pointer to a Unicode string representing the path to the XML file to be parsed. | |
| toFill | A token maintaing state information to maintain internal consistency between invocation of 'parseNext' calls. |
parseFirst(char*,...)
parseFirst(InputSource&,...)
| virtual bool SAX2XMLReader::parseFirst | ( | const char *const | systemId, | |
| XMLPScanToken & | toFill | |||
| ) | [pure virtual] |
Begin a progressive parse operation.
This method is used to start a progressive parse on a XML file. To continue parsing, subsequent calls must be to the parseNext method.
It scans through the prolog and returns a token to be used on subsequent scanNext() calls. If the return value is true, then the token is legal and ready for further use. If it returns false, then the scan of the prolog failed and the token is not going to work on subsequent scanNext() calls.
| systemId | A pointer to a regular native string representing the path to the XML file to be parsed. | |
| toFill | A token maintaing state information to maintain internal consistency between invocation of 'parseNext' calls. |
parseFirst(XMLCh*,...)
parseFirst(InputSource&,...)
| virtual bool SAX2XMLReader::parseFirst | ( | const InputSource & | source, | |
| XMLPScanToken & | toFill | |||
| ) | [pure virtual] |
Begin a progressive parse operation.
This method is used to start a progressive parse on a XML file. To continue parsing, subsequent calls must be to the parseNext method.
It scans through the prolog and returns a token to be used on subsequent scanNext() calls. If the return value is true, then the token is legal and ready for further use. If it returns false, then the scan of the prolog failed and the token is not going to work on subsequent scanNext() calls.
| source | A const reference to the InputSource object which points to the XML file to be parsed. | |
| toFill | A token maintaing state information to maintain internal consistency between invocation of 'parseNext' calls. |
parseFirst(XMLCh*,...)
parseFirst(char*,...)
| virtual bool SAX2XMLReader::parseNext | ( | XMLPScanToken & | token | ) | [pure virtual] |
Continue a progressive parse operation.
This method is used to continue with progressive parsing of XML files started by a call to 'parseFirst' method.
It parses the XML file and stops as soon as it comes across a XML token (as defined in the XML specification). Relevant callback handlers are invoked as required by the SAX specification.
| token | A token maintaing state information to maintain internal consistency between invocation of 'parseNext' calls. |
parseFirst(char*,...)
parseFirst(InputSource&,...)
| virtual void SAX2XMLReader::parseReset | ( | XMLPScanToken & | token | ) | [pure virtual] |
Reset the parser after a progressive parse.
If a progressive parse loop exits before the end of the document is reached, the parser has no way of knowing this. So it will leave open any files or sockets or memory buffers that were in use at the time that the parse loop exited.
The next parse operation will cause these open files and such to be closed, but the next parse operation might occur at some unknown future point. To avoid this problem, you should reset the parser if you exit the loop early.
If you exited because of an error, then this cleanup will be done for you. Its only when you exit the file prematurely of your own accord, because you've found what you wanted in the file most likely.
| token | A token maintaing state information to maintain internal consistency between invocation of 'parseNext' calls. |
| virtual Grammar* SAX2XMLReader::loadGrammar | ( | const InputSource & | source, | |
| const Grammar::GrammarType | grammarType, | |||
| const bool | toCache = false | |||
| ) | [pure virtual] |
Preparse schema grammar (XML Schema, DTD, etc.
) via an input source object.
This method invokes the preparsing process on a schema grammar XML file specified by the SAX InputSource parameter. If the 'toCache' flag is enabled, the parser will cache the grammars for re-use. If a grammar key is found in the pool, no caching of any grammar will take place.
| source | A const reference to the SAX InputSource object which points to the schema grammar file to be preparsed. | |
| grammarType | The grammar type (Schema or DTD). | |
| toCache | If true , we cache the preparsed grammar, otherwise, no caching. Default is false . |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. | |
| DOMException | A DOM exception as per DOM spec. |
| virtual Grammar* SAX2XMLReader::loadGrammar | ( | const XMLCh *const | systemId, | |
| const Grammar::GrammarType | grammarType, | |||
| const bool | toCache = false | |||
| ) | [pure virtual] |
Preparse schema grammar (XML Schema, DTD, etc.
) via a file path or URL
This method invokes the preparsing process on a schema grammar XML file specified by the file path parameter. If the 'toCache' flag is enabled, the parser will cache the grammars for re-use. If a grammar key is found in the pool, no caching of any grammar will take place.
| systemId | A const XMLCh pointer to the Unicode string which contains the path to the XML grammar file to be preparsed. | |
| grammarType | The grammar type (Schema or DTD). | |
| toCache | If true , we cache the preparsed grammar, otherwise, no caching. Default is false . |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. | |
| DOMException | A DOM exception as per DOM spec. |
| virtual Grammar* SAX2XMLReader::loadGrammar | ( | const char *const | systemId, | |
| const Grammar::GrammarType | grammarType, | |||
| const bool | toCache = false | |||
| ) | [pure virtual] |
Preparse schema grammar (XML Schema, DTD, etc.
) via a file path or URL
This method invokes the preparsing process on a schema grammar XML file specified by the file path parameter. If the 'toCache' flag is enabled, the parser will cache the grammars for re-use. If a grammar key is found in the pool, no caching of any grammar will take place.
| systemId | A const char pointer to a native string which contains the path to the XML grammar file to be preparsed. | |
| grammarType | The grammar type (Schema or DTD). | |
| toCache | If true , we cache the preparsed grammar, otherwise, no caching. Default is false . |
| SAXException | Any SAX exception, possibly wrapping another exception. | |
| XMLException | An exception from the parser or client handler code. | |
| DOMException | A DOM exception as per DOM spec. |
| virtual void SAX2XMLReader::resetCachedGrammarPool | ( | ) | [pure virtual] |
Clear the cached grammar pool.
| void SAX2XMLReader::setInputBufferSize | ( | const XMLSize_t | bufferSize | ) | [virtual] |
Set maximum input buffer size.
This method allows users to limit the size of buffers used in parsing XML character data. The effect of setting this size is to limit the size of a ContentHandler::characters() call.
The parser's default input buffer size is 1 megabyte.
| bufferSize | The maximum input buffer size |
| virtual void SAX2XMLReader::installAdvDocHandler | ( | XMLDocumentHandler *const | toInstall | ) | [pure virtual] |
This method installs the specified 'advanced' document callback handler, thereby allowing the user to customize the processing, if they choose to do so.
Any number of advanced callback handlers maybe installed.
The methods in the advanced callback interface represent Xerces-C extensions. There is no specification for this interface.
| toInstall | A pointer to the users advanced callback handler. |
| virtual bool SAX2XMLReader::removeAdvDocHandler | ( | XMLDocumentHandler *const | toRemove | ) | [pure virtual] |
This method removes the 'advanced' document handler callback from the underlying parser scanner.
If no handler is installed, advanced callbacks are not invoked by the scanner.
| toRemove | A pointer to the advanced callback handler which should be removed. |


“No, I want to give this to you.”
John, also known as Juan Tumani
“I went to the Women’s March, and I was wearing my clown nose and everything. I thought this lady was trying to show me her smiley face pin, but she said, “No, I want to give this to you.” So now I’m wearing it on my badge everyday as a reminder.
It’s hard to be happy now with all the stuff in the world going on, but I’m trying.”
4 Questions to Make You Think is a quarterly zine of stories about big questions.
Each issue gathers an assortment of illustrations, interviews, and excerpts surrounding the theme of the season.
Learn more about 4 Questions to Make You Think →Spring 2017
What makes you happy?
Summer 2017
What are your irrational habits?
Fall 2017
How do you deal with loneliness?
Winter 2017
Who is your hero?


Get the logger information to the given name. Default is emptystring
The default output - set this via watch options: output
The default output - set this via watch options: output
Requests a logger output to the given logger uuid
Register the mCAP logger once: only wait until the first log has a response. Do not catch further logs filePath: the path to the mCAP file to watch output: a function the logs are send to - default is console.log name: the name of the logger: default is '' level: the log level: default is 20000 Log Level Overview: FATAL: 50000 ERROR: 40000 WARN: 30000 INFO: 20000 DEBUG: 10000 TRACE: 5000
Stop the live logger
Start watching a live logger. Will stop every other live logger before. options: once: only wait until the first log has a response. Do not catch further logs filePath: the path to the mCAP file to watch output: a function the logs are send to - default is console.log name: the name of the logger: default is ''
Resolve a level string, name (upper or lowercase) to a level number value.
Resolve a level number, name (upper or lowercase) to a level number value.
Generated using TypeDoc
Logs the response from the logger, if watching is set to true keep watching after the log


Loading...
LIST
MAP
SORT BY
Severity Level
Severity Level
Category
Service
Region
{{:name}}
{{:resultsCount}} RESULTS
View all
{{:title}}
AlertId: {{:id}}
{{:level}}
{{:resources}} Resources
+ view details
Category
{{:category}}
Description
{{:description}}
Suggested Fix
{{:fix}}
{{:resources}} Resources
more info
share


My Team
John Smith
Manager
ID: 123
Email:
<EMAIL_ADDRESS>Office number: 1
Susan Jackson
Engineer
ID: 345
Email:
<EMAIL_ADDRESS>GitHub:
susan
Bob Frank
Intern
ID: 456
Email:
<EMAIL_ADDRESS>School: UConn


Winton
This page contains an index of all the individuals in the database with the surname of Winton. Selecting the person’s name will take you to that person’s individual page.
| Given Name | Birth | Death | Partner | Parents |
|---|---|---|---|---|
| Alfred Owen | 1936 | 1995-07-27 | Tracey, [Living] | Winton, Charles Owen Floyd, Hilda |
| Alice May | 1886-09-18 | 1976-02-12 | Miller, James | Winton, Harry (Farmer) Booth, Susannah |
| Amy Beatrice | 1874-03-22 | 1887-10-25 | Winton, Harry (Farmer) Booth, Susannah | |
| Aubrey Edward | 2 Nov 1908(twin) | 1987-08-09 | Frost, Winifred Ada | Winton, Edward Booth Collett, Emily Ella |
| Catherine | Lowe, Simon | Winton, Douglas Collett Bain, Ruth Holland (Tonko) | ||
| Charles Owen | 1893-02-28 | 1977-04-05 | Floyd, Hilda | Winton, Harry (Farmer) Booth, Susannah |
| Doris Emily | 2 Nov 1908(twin) | 1950-02-09 | Coulton, Raymond Wesley | Winton, Edward Booth Collett, Emily Ella |
| Douglas Collett | 1917-01-09 | 1992-01-15 | Bain, Ruth Holland (Tonko) | Winton, Edward Booth Collett, Emily Ella |
| Edith Jessie | 1884 | 1888-11-29 | Winton, Harry (Farmer) Booth, Susannah | |
| Edward Booth | 1876-05-04 | 1945-07-17 | Collett, Emily Ella | Winton, Harry (Farmer) Booth, Susannah |
| Florence Henrietta | 1871 | 1919-12-06 | Winton, Harry (Farmer) Booth, Susannah | |
| Gladys Myee | 1907-02-06 | 1995-05-11 | Winton, Edward Booth Collett, Emily Ella | |
| Harry, (Farmer) | 1843-05-21 | 1921-03-21 | Booth, Susannah | Winton, William & Mary Ann Larkin Larkin, Mary Ann |
| Harry “Hilder” | 1879-05-08 | 1975-05-15 | Dawes, May | Winton, Harry (Farmer) Booth, Susannah |
| Heather Dawn | 1925 | 1996-08-30 | Dinnie, Burton William John | Winton, William "Leslie" Ross, Ellen |
| Nellie Susannah Myee | 1890-12-23 | 1953-07-14 | Winton, Harry (Farmer) Booth, Susannah | |
| Stuart James | c1955 | 1973-08-22 | Winton, Douglas Collett Bain, Ruth Holland (Tonko) | |
| Thomas Tebbutt | 1881-08-02 | 1883-11-11 | Winton, Harry (Farmer) Booth, Susannah | |
| William, & Mary Ann Larkin | Larkin, Mary Ann | |||
| William “Leslie” | 1889-01-12 | 1972-08-17 | Ross, Ellen | Winton, Harry (Farmer) Booth, Susannah |
| [Living] | Winton, [Living] Bone, [Living] | |||
| [Living] | Bone, [Living] | |||
| [Living] | Rickard, Frederick Charles | Winton, Edward Booth Collett, Emily Ella | ||
| [Living] | Bursill, [Living] | Winton, Harry "Hilder" Dawes, May | ||
| [Living] | Winton, Alfred Owen Tracey, [Living] | |||
| [Living] | Winton, Aubrey Edward Frost, Winifred Ada | |||
| [Living] | Winton, Aubrey Edward Frost, Winifred Ada | |||
| [Living] | Winton, [Living] Bursill, [Living] |


My day for donut pickup at work... in early and wells-sugared. 1/4/2008, 9:05:12 AM Favs: 0 Retweets: 0 link


View On GitHub
Kevins Bobo
<EMAIL_ADDRESS>Project maintained by
KevinsBobo
Hosted on GitHub Pages — Theme by
mattgraham


| Parameter Name | Value | Type |
|---|---|---|
| ID_WIDTH | 12 | Signed Integer |
| ADDR_WIDTH | 21 | Signed Integer |
| RDATA_WIDTH | 32 | Signed Integer |
| WDATA_WIDTH | 32 | Signed Integer |
| ADDR_USER_WIDTH | 1 | Signed Integer |
| DATA_USER_WIDTH | 1 | Signed Integer |
| AXI_LOCK_WIDTH | 2 | Signed Integer |
| AXI_BURST_LENGTH_WIDTH | 4 | Signed Integer |
| WRITE_ISSUING_CAPABILITY | 8 | Signed Integer |
| READ_ISSUING_CAPABILITY | 8 | Signed Integer |
| AXI_VERSION | AXI3 | String |
| PKT_THREAD_ID_H | 110 | Signed Integer |
| PKT_THREAD_ID_L | 99 | Signed Integer |
| PKT_QOS_H | 96 | Signed Integer |
| PKT_QOS_L | 96 | Signed Integer |
| PKT_BEGIN_BURST | 95 | Signed Integer |
| PKT_CACHE_H | 117 | Signed Integer |
| PKT_CACHE_L | 114 | Signed Integer |
| PKT_ADDR_SIDEBAND_H | 93 | Signed Integer |
| PKT_ADDR_SIDEBAND_L | 93 | Signed Integer |
| PKT_DATA_SIDEBAND_H | 94 | Signed Integer |
| PKT_DATA_SIDEBAND_L | 94 | Signed Integer |
| PKT_PROTECTION_H | 113 | Signed Integer |
| PKT_PROTECTION_L | 111 | Signed Integer |
| PKT_BURST_SIZE_H | 90 | Signed Integer |
| PKT_BURST_SIZE_L | 88 | Signed Integer |
| PKT_BURST_TYPE_H | 92 | Signed Integer |
| PKT_BURST_TYPE_L | 91 | Signed Integer |
| PKT_RESPONSE_STATUS_L | 118 | Signed Integer |
| PKT_RESPONSE_STATUS_H | 119 | Signed Integer |
| PKT_BURSTWRAP_H | 87 | Signed Integer |
| PKT_BURSTWRAP_L | 81 | Signed Integer |
| PKT_BYTE_CNT_H | 80 | Signed Integer |
| PKT_BYTE_CNT_L | 74 | Signed Integer |
| PKT_ADDR_H | 67 | Signed Integer |
| PKT_ADDR_L | 36 | Signed Integer |
| PKT_TRANS_EXCLUSIVE | 73 | Signed Integer |
| PKT_TRANS_LOCK | 72 | Signed Integer |
| PKT_TRANS_COMPRESSED_READ | 68 | Signed Integer |
| PKT_TRANS_POSTED | 69 | Signed Integer |
| PKT_TRANS_WRITE | 70 | Signed Integer |
| PKT_TRANS_READ | 71 | Signed Integer |
| PKT_DATA_H | 31 | Signed Integer |
| PKT_DATA_L | 0 | Signed Integer |
| PKT_BYTEEN_H | 35 | Signed Integer |
| PKT_BYTEEN_L | 32 | Signed Integer |
| PKT_SRC_ID_H | 97 | Signed Integer |
| PKT_SRC_ID_L | 97 | Signed Integer |
| PKT_DEST_ID_H | 98 | Signed Integer |
| PKT_DEST_ID_L | 98 | Signed Integer |
| PKT_ORI_BURST_SIZE_H | 122 | Signed Integer |
| PKT_ORI_BURST_SIZE_L | 120 | Signed Integer |
| ST_DATA_W | 123 | Signed Integer |
| ST_CHANNEL_W | 3 | Signed Integer |
| ID | 0 | Signed Integer |
| PKT_BURSTWRAP_W | 7 | Signed Integer |
| PKT_BYTE_CNT_W | 7 | Signed Integer |
| PKT_ADDR_W | 32 | Signed Integer |
| PKT_DATA_W | 32 | Signed Integer |
| PKT_BYTEEN_W | 4 | Signed Integer |
| PKT_SRC_ID_W | 1 | Signed Integer |
| PKT_DEST_ID_W | 1 | Signed Integer |


#include <BL3_Engine_structs.hpp>
◆ bAlignToGroundNormal
| bool bAlignToGroundNormal |
◆ bCancelIfGroundNotFound
| bool bCancelIfGroundNotFound |
◆ bComputeTransformWhenSpawned
| bool bComputeTransformWhenSpawned |
◆ bDeferConstruction
◆ bSkipOnClients
◆ bTransformIgnorePitch
| bool bTransformIgnorePitch |
◆ Class
◆ CollisionHandling
◆ Delay
◆ ExposeOnSpawnCache
◆ Failed
| struct FScriptDelegate Failed |
◆ ForceSpawnTimer
◆ InstanceCount
◆ InstanceDelay
◆ Instigator
◆ Name
◆ Owner
◆ SnapToGroundSearchExtent
| float SnapToGroundSearchExtent |
◆ Spawned
| struct FScriptDelegate Spawned |
◆ Template
◆ Transform
◆ TransformActor
◆ TransformComponent
◆ TransformSocketName
| struct FName TransformSocketName |
◆ TransformSocketNames
| TArray<struct FName> TransformSocketNames |
◆ UnknownData00
| unsigned char UnknownData00[0x8] |
◆ UnknownData01
| unsigned char UnknownData01[0x6] |
◆ UnknownData02
| unsigned char UnknownData02[0x3] |
◆ UnknownData03
| unsigned char UnknownData03[0x5] |
◆ UnknownData04
| unsigned char UnknownData04[0x7] |
◆ UnknownData05
| unsigned char UnknownData05[0x10] |
◆ UnknownData06
| unsigned char UnknownData06[0x38] |


The best solution for finding information on the University of British Columbia
Allows users to sort UBC courses by section size, department, course number, instructor, title, highest/lowest average, most sections, most passes, or most fails.
Allows users to sort UBC rooms by room number, size, type, building name, furniture type, and location.
Provides a usable interface for scheduling specific courses into specific rooms.
By Patrick Lin & Naing Phyo


Zip Doctor
Find a Dr. near you
Please Enter Your Symptom
Please select a city
Los Angeles
Seattle
Chicago
Search!


音频字幕生成
X is an impressive, slightly scary CEO. You will have heard of him. Y is a smartish, youngish man who works for his company. You won’t have heard of him, unless you work there too — in which case the very sound of his name will have you grinding your teeth. When Y was hired about three years ago, X took to him at once, decided he was a man of extraordinary talent and in no time at all, Y was given a big department to run. Because Y has neither the experience nor the personality for the job, he is screwing it up. Various senior colleagues have protested, but they have been silenced. The CEO cannot and will not see that his protégé is a dog. He is too smitten. This story, which I’ve had to doctor a little to avoid getting myself into trouble, is a common one, yet it isn’t an issue that leadership experts ever talk about. Instead they obsess over unconscious bias — the latest fashionable way in which all managers take bad decisions about people — and pack executives off on training courses to try to conquer their subtle, buried prejudices. But no one seems to worry about what happens when a boss’s bias is neither subtle nor buried but outrageous, and there for everyone to see — apart from the boss himself, who is blind to his own bias and instead congratulates himself on his prescience in spotting someone extraordinary. The syndrome, which is a major character flaw of some of the world’s finest managers, needs a name and so I’m calling it boss crush. It is when an executive falls for someone, loses all judgment, refuses to listen and ensures that disaster will follow. A version of this was played out recently between David Cameron and Camila Batmanghelidjh. The prime minister developed a crush on the mesmerising, rainbow-turbaned head of Kids Company; large quantities of cash were shovelled into her charity; civil servants asked questions, but nothing happened — until things went so spectacularly wrong the plug had to be pulled. I first became aware of the boss crush phenomenon more than 30 years ago, when I was the love object myself. I was singled out by a cantankerous manager who got it into his head that I was all-round wonderful. I was given a job which I had no idea how to do, yet despite my manifestly indifferent performance, I was repeatedly told I was doing brilliantly. In some ways I found this nice as I’m a sucker for being told I’m a genius. What was less nice was the feeling of being over-promoted, and what was even less nice was how little my colleagues seemed to like me. I have no idea how it would have ended: the man in question got fired for assorted misdemeanours and shortly afterwards I quit myself. Since then I’ve taken a keen interest in the boss crush phenomenon, and tried to draw some conclusions. First, it has little to do with sex, and everything to do with power. The objects of the crush of a powerful man are as often men as women. Second, it is as random as real love. Sometimes the older boss falls for someone who reminds him of himself — but sometimes the object of the love is quite different. Sometimes the loved one is brilliant. Other times they are a liability. Most often they are a mixture of both.  (Anyone who doesn’t believe that sucking up works, should read a blog post written by Marshall Goldsmith about the love we feel for our dogs, who are the most successful suckers-up ever invented.) But some crush objects have never invited such attention. I can think of one who I used to know, who was grumpy, taciturn and viewed all power with great suspicion — and yet was revered by his doting manager. Like real love, the boss crush is blind. Worse than that, once the boss has publicly singled out the love-object as worthy of promotion, his pride is on the line. The crush object simply has to be good; nothing else will do. All warning signs are ignored, the truth only outs when it is too late. Then the after-effects of the crush are brutal — the former loved one is treated to rage and disdain and usually in the end is fired. The most troubling thing about this phenomenon is that there isn’t an answer. You can’t ban executives from crushes any more than you can ban teenagers. All you can do is notice the sorts of people who are prone to them, and be warned. In the absence of any studies and based only on my own observation, I’d say those most prone to crushes are sublimely confident of their own judgment, are somewhat isolated and inclined to be strong and charismatic. Which turns out not to be very helpful at all — they are just the sort of people most likely to rise to the very top<EMAIL_ADDRESS>Twitter: @lucykellaway


|
F´ Flight Software - C/C++ Documentation
NASA-v1.5.0
A framework for building embedded system applications to NASA flight quality standards.
|
AMPCSSequence
is a derived class of CmdSequencer::Sequence
. It loads, validates, and runs AMPCS-compatible sequence files.
A sequence file consists of a 32-bit sequence header followed by up to 32,768 bytes of record data.
The record data consists of zero or more records. Each record has the following format:
| Record Field | Size in Bytes | Description |
|---|---|---|
| Time Flag | 1 | Either 0x0 denoting absolute time or 0xFF denoting relative time |
| Time | 4 | The time in seconds |
| CMD Length | 2 | The size in bytes of the Command field |
| Command | 1017 | A serialized command in F Prime format, with a 16-bit opcode |
The AMPCSSequence
class implements the virtual functions of CmdSequencer::Sequence
as follows.
.CRC32
.m_header
as follows:m_fileSize
: The size of the command record data, computed in item 2 above.m_numRecords
: Count the records when validating them.m_timeBase
: Use 0xFFFF (don't care).m_timeContext
: Use 0xFF (don't care).Return true
if and only if B has more data.
Deserialize and return the next record stored in the serial buffer. The deserialized record contains the following binary data in its argument field:
| Field | Size in Bytes | Value |
|---|---|---|
| Packet Descriptor | 4 | Fw::ComPacket::FW_PACKET_COMMAND |
| Opcode | 4 | The opcode stored in bytes 0-1 of the serial record, zero-extended to four bytes |
| Arguments | Variable | Bytes 2-end of the serial record |
Reset B for deserialization.
Reset B for serialization.


Father Name:
{{contact.fatherName}}
Father Occupation:
{{contact.fatherOccupation}}
Father Income:
{{contact.fatherIncome}}
Father Number:
{{contact.fatherMobile}}
Mother Name:
{{contact.motherName}}
Mother Occupation:
{{contact.motherOccupation}}
Mother Income:
{{contact.motherIncome}}
Mother Number:
{{contact.motherMobile}}


Edit time and date...
Time zone:
Reset all filenames to their defaults. This action will take effect immediately and cannot be undone.
Set the default size of opened window. Default is 40x25.Window width: 40
Window height: 25
Color scheme
Desktop background


Hey, waddup. I’m Rico from bigrat.monster.
As 2020 comes to a close, I would like to thank you for purchasing merchandise for my little project.
As you may have heard, the bigrat.monster merch store is closing permanently and as you are reading this, it had already closed its doors.
bigrat.monster originally started as just a meme. I saw a screenshot of a 4chan post and thought it would be funny to make a website.
I am aware of the copyright issue at the very start since the picture isn't mine. The merch wasn't anyone's fault and technically isn't infringing anyones copyright, I'm just not comfortable with it. That ultimately lead to the decision to close the store.
Don't worry, while the merch store is gone, the main website is going to stay.
From the bottom of my heart, I would like to thank you once again for purchasing at the merch store and visiting the site. Everyone’s life changed a lot in 2020 but you brought a positive one to mine.
Stay positive and have a happy new year.
Sincerely,
Rico
1st January 2021


---
layout: page
title: Sponsors
sponsors-10:
sponsors-50:
sponsors-100:
sponsors-200:
sponsors-500:
---
The following have invested in Blaze's continuous development. Thank you!
Special thanks to
{% for sponsor in page.sponsors-500 %}
{% endfor %}
{% for sponsor in page.sponsors-200 %}
{% endfor %}
{% for sponsor in page.sponsors-100 %}
{% endfor %}
{% for sponsor in page.sponsors-50 %}
{% endfor %}
{% for sponsor in page.sponsors-10 %}
{{ sponsor.name }}
{% endfor %}


Skin is eBay's official CSS framework and is distributed via NPM under the @ebay/skin package name.
To use Skin, the package should be added as a dependency in your project's package.json file.
{% highlight json %} { "dependencies": { "@ebay/skin": "^7" } } {% endhighlight %}Skin is optimised for use with Lasso.js - an advanced JavaScript module bundler, asset pipeline and optimizer.
Add the @ebay/skin module as a browser.json dependency to include the entire set of Skin modules.
{% highlight json %} { "dependencies": [ "@ebay/skin" ] } {% endhighlight %}Or, alternatively, by specifying modules on a per-need basis.
{% highlight json %} { "dependencies": [ "@ebay/skin/less", "@ebay/skin/global", "@ebay/skin/button", "@ebay/skin/icon/foreground" ] } {% endhighlight %}Skin provides the following modules:


--- layout: archive title: Zulip Chat Archive permalink: /stream/116395-maths/topic/basic.20complex.20number.20computations.html ---
@VeraZZ is doing basic computations with complex numbers and I'm still not 100% sure that we're doing it right.
If the goal looks like this:
z₁ z₂ : ℂ ⊢ ↑(z₁.re * z₂.re + z₁.im * z₂.im) + ↑(z₁.re * z₂.re + z₁.im * z₂.im) = z₁ * conj z₂ + z₂ * conj z₁
then currently our strategy is the (probably rather inefficient)
apply complex.ext, simp,ring,simp,ring,
After Chris' complex number PR I realised that I am not at all sure how I'm supposed to be working with complex numbers. The strategy above is to check that two complex numbers are equal it suffices to check their real and imag parts are equal, and then use a dangerous non-finishing simp
to unravel all the real and imaginary stuff followed by ring
. Are there better approaches?
I think a non-finishing simp
is not dangerous here, since ring
is not sensitive to the precise state of the goal.
you could also define a tactic doing apply complex.ext ; {simp, ring}
, and you wouldn't see simp
:wink:
By the way, if ext
cannot replace apply complex.ext
then the extensionality attribute needs to be added somewhere
and, as usual with non finishing simp, you can use suffices : stuff := by simp,
, where stuff is what you currently see as after simp
That sounds like a tactic I might be able to write.
sure: meta def cplx_ring : tactic unit := `[apply complex.ext ; {simp, ring}]
Last updated: Apr 24 2020 at 19:02 UTC


Ruby Core
Now is a fantastic time to follow Ruby’s development, with Ruby 2.0 development underway. With the increased attention Ruby has received in the past few years, there’s a growing need for good talent to help enhance Ruby and document its parts. So, where do you start?
The topics related to Ruby development covered here are:
- Using Subversion to Track Ruby Development
- How to Use Git With the Main Ruby Repository
- Improving Ruby, Patch by Patch
- Rules for Core Developers
Using Subversion to Track Ruby Development
Checking out the latest Ruby source code is a matter of logging into the Subversion anonymous account. From your commandline:
1
|
|
The ruby
directory will now contain the latest source code for Ruby
1.9 (trunk), which is the development version of Ruby. The trunk was
used to release a stable 1.9.1 version in January 2009. Currently
patches applied to the trunk are backported to the stable 1_9_1 branch
(see below).
If you’d like to follow patching of Ruby 1.9.1, you should use the
ruby_1_9_1
branch when checking out:
1
|
|
If you’d like to follow patching of Ruby 1.8, you should use the
ruby_1_8_6
or ruby_1_8_7
branch when checking out (depending on the
version you’re using):
1
|
|
This will check out the Ruby 1.8.7 development tree into a ruby_1_8_7
directory. Developers working on Ruby 1.8 are expected to migrate their
changes to Ruby’s trunk, so often the two branches are very similiar,
with the exception of improvements made by Matz and Nobu to the language
itself.
If you prefer, you may browse Ruby’s repository via the web.
For information about Subversion, please see the Subversion FAQ and the Subversion book. Alternatively, you may find Pragmatic Version Control with Subversion to be a useful introductory book.
How to Use Git With the Main Ruby Repository
Those who prefer to use Git over Subversion can find instructions with the mirror on GitHub, both for those with commit access and everybody else.
Improving Ruby, Patch by Patch
The core team maintains a bug tracker for submitting patches and bug reports to Matz and the gang. These reports also get submitted to the Ruby-Core mailing list for discussion, so you can be sure your request won’t go unnoticed. You can also send your patches straight to the mailing list. Either way, you are encouraged to take part in the discussion that ensues.
Please look over the Patch Writer’s Guide for some tips, straight from matz, on how to get your patches considered.
To summarize, the steps for building a patch are:
- If you are fixing a bug in Ruby 1.8, check out a copy of Ruby 1.8
from Subversion using the
ruby_1_8
branch.$ svn co http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8
If you wish to add a feature to Ruby, check out the trunk of Ruby’s source. Even if you wish to add a feature to Ruby 1.8, it has to be proven in the trunk first.$ svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby
- Add your improvements to the code.
- Create a patch.
$ svn diff > ruby-changes.patch
- Email your patch to the Ruby-Core mailing list with a CHANGELOG entry describing the patch.
- If there are no issues raised about the patch, committers will be given the approval to apply it.
Please note: patches should be submitted as a unified diff. For more on how patches are merged, see the diffutils reference.
Discussion of Ruby’s development converges on the Ruby-Core mailing list. So, if you are curious about whether your patch is worthwhile or you want to spark a discussion about Ruby’s future, don’t hesitate to come aboard. Be warned that off-topic discussions are not tolerated on this list, the noise level should be very low, topics should be pointed, well-conceived and well-written. Since we’re addressing Ruby’s creator, let’s have some reverence.
Keep in mind that Ruby’s core developers live in Japan and, while many speak very good English, there is a significant timezone difference. They also have an entire body of Japanese development lists happening alongside the English counterparts. Be patient, if your claim isn’t resolved, be persistent—give it another shot a few days later.
Rules for Core Developers
Generally, the developers of Ruby should be familiar with the source code and the style of development used by the team. To be clear, the following guidelines should be honored when checking into Subversion:
- All check-ins should be described in the
ChangeLog
, following the GNU conventions. (Many Ruby core developers use Emacsadd-log
mode, which can be accessed with the commandC-x 4 a
.) - Check-in dates should be given in Japan Standard Time (UTC+9).
- The bulleted points from your ChangeLog should also be placed in the Subversion commit message. This message will be automatically mailed to the Ruby-CVS list after you commit.
- K&R function declarations are used throughout Ruby’s source code and its packaged extensions.
- Please, do not use C++-style comments (
//
), Ruby’s maintainers instead prefer the standard C multiline comment. (/* .. */
)


This website uses the powerful Amazon Web Services neural machine translation service to enable you to translate text while taking full advantage of its free tier for the first year of use. This means 2 million characters translated per month as of May 2020. Refer to the pricing page for details.
An experimental project by Kevin Loeffler


There is no 3rd party involved in the transaction. The involved parties choose to ship and release the funds when they are ready.
The platform is just a gateway to the Nebulas smart contract and provides the tools necessary to interact with the Blockchain.
At this moment, there is NO transaction fee. The cost is the one the seller and buyer agreed upon.
The NAS Blockchain provides the immutability and persistance of the transactions.
Below is a basic escrow transaction flow between a seller and a buyer.
The buyer or the seller starts a transaction in which they describe the product details that is being traded and the price in NAS.
The seller/buyer accepts the escrow transaction details and price and chooses to reject or accept the transaction.
After buyer has deposited the necessary funds within the Nebulas contract, the seller can choose to Ship the product and provide the shipment details.
After receiving the product, the buyer has X amount of days to inspect the item and release the funds to the seller.
The funds are being kept secure in the NEBULAS smart contract. They can't be released or refunded by anyone other
than the parties involved.
When buyer chooses to release the funds, they will automatically be credited within the seller NEBULAS adderess.
In case of a disagreement between the parties, they both have an option to dispute the transaction, in which case it will be handled only by the nas-escrow developer without any additional fee.
Below is a list of under development features in order to
facilitate the usefulness of the Escrow smart contract. Hover over each section for more details.
Both the platform and contract code are linked below:
For any platform problems or enquiries, or any dispute arrangements
please use the email address below.
support@nas-escrow.com


/search Endpoint
Nutritionix API ID
(text)
Nutritionix API Key
(text)
Query (Item Name)
(text)
Query (Brand Name)
(text)
NOTE:
If this if filled, then
QUERIES
will be used instead of
QUERY
Offset
(interger)
Limit (10 to 50)
(interger)
Sort Field
(text)
Sort Order
Ascending
Descending
Minimum Search Score
(float)
Fields (should be a valid JSON array)
(text)
Example:
["item_name","brand_name","nf_calories","nf_sodium","item_type"]
Filters (should be a valid JSON array)
(text)
Example:
{"not":{"item_type":2},"nf_calories":{"from":0,"to":400}}
Contains Milk?
True
False
Not Set
Contains Eggs?
True
False
Not Set
Contains Fish?
True
False
Not Set
Contains Shellfish?
True
False
Not Set
Contains Tree Nuts?
True
False
Not Set
Contains Peanuts?
True
False
Not Set
Contains Wheat?
True
False
Not Set
Contains Soybeans?
True
False
Not Set
Contains Gluten?
True
False
Not Set
Return Result As
JSON
PHP Array
Submit
Result