To Do
Home
List
Create
Active
Disabled
Shared
Active
Pending
Login
To Do List
Keep track of all of things you need to do by creating lists and sharing items with friends.
View
List
Items
Shared
Status


The the web API to interact with this CorDapp, end-points available:
- GET /api/iou/ious (list IOUs)
- GET /api/iou/issue-iou?amount=INTEGER¤cy=[GBP/USD]&party=NODE_NAME (issue an IOU to a party with a specified amount and currency)
- GET /api/iou/transfer-iou?id=LINEAR_ID&party=NODE_NAME (Transfer an IOU specified by linearId to another party
- GET /api/iou/settle-iou?id=LINEAR_ID&amount=INTEGER¤cy=[GBP/USD] (settle an amount of an IOU specified by linearId)
- GET /api/iou/cash (list all cash states)
- GET /api/iou/self-issue-cash?amount=INTEGER¤cy=[GBP/USD] (self issues an amount of cash in the specified currency)
- GET /api/iou/cash-balances (lists cash balances per currency)


otp2ocp - convert Omega Translation Process files to Omega Compiled Process files
otp2ocp OTPFILE [ \fB.otp\fP ]
otp2ocp is used to create or recreate Omega Compiled Process files (binary) from Omega Translation Process (text) files.
Omega Translation Processes are rules used to translate one character set to another and to choose between characters with one or more context-sensitive variants. OTPs could also be used to change the case or hyphenation of text.
mkocp(1), omega(1).
Draft Manual for the Omega System (omega-manual.dvi).
Web page: <http://www.gutenberg.eu.org/omega/>
The primary authors of Omega are John Plaice<EMAIL_ADDRESS>and Yannis Haralambous<EMAIL_ADDRESS>This manual page was written by C.M. Connelly<EMAIL_ADDRESS>for the Debian GNU/Linux system. It may be used by other distributions without contacting the author. Any mistakes or omissions in the manual page are my fault; inquiries about or corrections to this manual page should be directed to me (and not to the primary author).


Bold text denotes the names of actions you can type in the Find Action
dialog (Ctrl+Shift+A or quickly press Shift twice for
Find Anything). Shortcuts are given for the default Windows/Linux keymap.
To learn shortcuts for your keymap consult Help > Keymap reference
. Shortcut
for an action is also displayed in the Find Action dialog.


--- layout: article title: Onslaught! Arena v1.2.8 author: matt tags: [onslaughtarena] ---
We just pushed a minor update to Onslaught! Arena on the Chrome Webstore. This quick update includes:
While this is just a small release, we've got new content in the works, including new weapons, new monsters, and a special promotion for Valentine's Day (this upcoming Monday). So stay tuned for more updates!


Welcome to Xanho
What is Xanho?
Xanho is an open source, open curriculum, open research academic platform.
What is Xanho's goal?
Education is necessary for a functioning society, and the more educated a society, the more productive it is. With that in mind, our goal is to make education affordable and easily accessible to everyone, everywhere.
What is the primary focus of Xanho?
Education and research are often one and the same. The focus of Xanho is sharing and collaborating on research. Furthermore, different students learn in different was. Some learn best through a series of video lectures, others learn best through writing. Xanho gives students the freedom to learn and research in ways which fit the individual, not the group.
How is it structured?
The Xanho School is built using two main structures: Microdegrees which cover a relatively wide subject area, and Topics which focus on a very specific unit of interest. For example, a Microdegree in Computer Science may consist of Topics on various programming languages, algorithm analysis, information security, and many others.
Microdegrees and Topics can be either privately or publicly owned.
A privately owned entity allows for suggestions and contributions by the community; however, the "owner" of it gets the final say on what goes in. Companies, universities, and governments can privately own an entity, thus allowing for standards set forth by the owner. Furthermore, the private owner of a Topic is granted the right of picking or hiring Council Members, which is an team of reviewers tasked with critiquing, approving, and denying student Research Projects.
Publicly owned entities, on the other hand, are open to the public for modifications, adjustments, additions, and removals. A user can submit a Revision Proposal which gets voted upon by the community. Furthermore, the public reviews and approves anonymous student Research Projects.
In either case, anyone is allowed to enroll in a Topic, regardless of its ownership.
How does it work?
Students
The student workflow is as follows: 1. Enroll in a Topic. 2. Study the content provided by the community (typically by teachers or professors). All tests, quizzes, and assignments are optional. 3. Conduct preliminary independent research using the Xanho Library. 4. Pick an idea for a Research Project which demonstrates understanding of the Topic, and submit for Council approval. 5. Once approved, complete the research project using the media of your choice. 6. Once you have a rough draft, you can optionally submit it for a Peer Review by students who have successfully completed the Topic. 7. Once you are comfortable with the project, submit for Council approval. 8. If accepted, you become a graduate of the Unit. If denied, you may make changes or modifications and resubmit. 9. Once you are a graduate of a unit, you gain the ability to Peer Review the projects of students in the Unit. By Peer Reviewing, you earn free credits to take additional Units.


Capabilities are summaries of business-oriented things that you organization is or want to be capable of. Click a capability to view or edit details
No capabilities defined yet
{{ capability.description }}
Define the structure of capabilities


The Smell: Repetitive Code
The Fix: A Function
smelly
minty
opportunity
The Smell: Repetitive Code
The Fix: Objects
smelly
minty
opportunity
The Smell: Unnecessary IDs
The Fix: Closures
smelly
minty
The Smell: Complex Functions
The Fix: More & Smaller Functions
smelly
minty
opportunity
The Smell: Async Acrobatics
The Fix: Deferreds
smelly
minty
opportunity
The Smell: HTML in Your JavaScript
The Fix: Templates
smelly
minty
opportunity
### minty code opens the door to abstractions.
## demand minty code, from yourself & others
- eliminate repetition
- keep functions short and simple
- avoid complex if / else logic
- manage and leverage asynchronicity
- keep HTML out of your JS
[moar smells](http://en.wikipedia.org/wiki/Code_smells)
### it will make you a better developer.
## work at getting better
- read libraries & examples
- rewrite code from IRC, StackOverflow
- incorporate code reviews into your workflow
- maintain and enforce a style guide on projects
- write tests for your code
**Repo** [github.com/rmurphey/js-minty-fresh](https://github.com/rmurphey/js-minty-fresh)
**Links** [pinboard.in/u:rmurphey/t:js-minty-fresh](http://pinboard.in/u:rmurphey/t:js-minty-fresh)
**Presentation** [rmurphey.com/js-minty-fresh/presentation/](http://rmurphey.com/js-minty-fresh/presentation/)
[@rmurphey](http://twitter.com/rmurphey) ☆ [rmurphey.com](http://rmurphey.com)
[bazaarvoice.com](http://bazaarvoice.com)


My name is Mr.Olesito Armstrong. A member of Independent Committee of Eminent Persons (ICEP), Switzerland. ICEP is charged with the Responsibility of finding bank accounts in Switzerland belonging to Non-Swiss indigenes, which have remained dormant since World War II. It may interest you to know that in July of 1997, the Swiss Banker's Association published a list of dormant accounts originally opened by Non-Swiss citizens. These accounts had been dormant since the end of World War II (May 9, 1945). Most belonged to Holocaust victims. The continuing efforts of the Independent Committee of Eminent Persons (ICEP) have since resulted in the discovery of additional dormant accounts - 54,000 in December 1995.The published lists contain all types of dormant accounts, including Interest-bearing savings accounts, securities accounts, safe deposit Boxes, custody accounts, and non-interest-bearing transaction accounts. Numbered accounts are also included. Interest is paid on accounts that Were interests bearing when established The Claims Resolution Tribunal (CRT) handles processing of all claims on accounts due non-Swiss citizens A Dormant account of OKEI JOB with a credit balance of 45,000,000.00 (Forty five million us dollars) plus accumulated interest was discovered by me. The beneficiary was murdered during the holocaust era, leaving no WILL and no possible records for trace of heirs. The Claims Resolution Tribunal has been mandated to report all unclaimed funds for permanent closure of accounts and transfer of existing credit balance into the treasury of Switzerland government as provided by the law of management of assets of deceased beneficiaries who died interstate (living no wills). Being a top executive at ICEP, I have all secret details and necessary Contacts for claim of the funds without any hitch. We can share the Funds and use it in investment of our choice. Due to the sensitive nature of my job, I need a foreigner to HELP claim The Funds. All that is required is for you to provide me with your details for Processing of the necessary legal and administrative claim documents For transfer of the funds to you. Kindly provide me with your full Name, Address, and Telephone/fax. I will do all my possible best to ensure that the fund is transferred to a secure, numbered account in your name in any Country of your choice and also where you will be capable of accessing the Funds Gradually and transferring to your country and other banks of your Choice in the world. My share will be 60 percent and your share is 30 per cent of the total Amount. 10 percent will be for all the expenses that the two party will Encounters. THERE IS NO RISK INVOLVED. You can find additional information about unclaimed funds through the Internet at the following websites: http://www.cnn.com/WORLD/europe/9902/09/germany.holocaust/ The Holocaust Claims Processing Office has put funds in Escrow awaiting submission of valid claims for necessary disbursement. I find myself privileged to have this information and this may be a great opportunity for a lifetime of success without Risks. Due to security reasons, you can also reply to my via email only. You May reply to me securely on the following email<EMAIL_ADDRESS>Thank you for your prompt response. I hope to hear from you soon. Mr. Olesito Armstrong


reStructuredText Primer ¶
reStructuredText is the default plaintext markup language used by Sphinx. This section is a brief introduction to reStructuredText (reST) concepts and syntax, intended to provide authors with enough information to author documents productively. Since reST was designed to be a simple, unobtrusive markup language, this will not take too long.
See also
The authoritative reStructuredText User Documentation . The “ref” links in this document link to the description of the individual constructs in the reST reference.
Paragraphs ¶
The paragraph ( ref ) is the most basic block in a reST document. Paragraphs are simply chunks of text separated by one or more blank lines. As in Python, indentation is significant in reST, so all lines of the same paragraph must be left-aligned to the same level of indentation.
Inline markup ¶
The standard reST inline markup is quite simple: use
-
one asterisk:
*text*
for emphasis (italics), -
two asterisks:
**text**
for strong emphasis (boldface), and -
backquotes:
``text``
for code samples.
If asterisks or backquotes appear in running text and could be confused with inline markup delimiters, they have to be escaped with a backslash.
Be aware of some restrictions of this markup:
-
it may not be nested,
-
content may not start or end with whitespace:
* text*
is wrong, -
it must be separated from surrounding text by non-word characters. Use a backslash escaped space to work around that:
thisis\ *one*\ word
.
These restrictions may be lifted in future versions of the docutils.
It is also possible to replace or expand upon some of this inline markup with roles. Refer to Roles for more information.
Lists and Quote-like blocks ¶
List markup (
ref
) is natural: just place an asterisk at
the start of a paragraph and indent properly. The same goes for numbered
lists; they can also be autonumbered using a
#
sign:
* This is a bulleted list.
* It has two items, the second
item uses two lines.
-
This is a bulleted list.
-
It has two items, the second item uses two lines.
1. This is a numbered list.
2. It has two items too.
-
This is a numbered list.
-
It has two items too.
#. This is a numbered list.
#. It has two items too.
-
This is a numbered list.
-
It has two items too.
Nested lists are possible, but be aware that they must be separated from the parent list items by blank lines:
* this is
* a list
* with a nested list
* and some subitems
* and here the parent list continues
-
this is
-
a list
-
with a nested list
-
and some subitems
-
-
and here the parent list continues
Definition lists ( ref ) are created as follows:
term (up to a line of text)
Definition of the term, which must be indented
and can even consist of multiple paragraphs
next term
Description.
- term (up to a line of text)
-
Definition of the term, which must be indented
and can even consist of multiple paragraphs
- next term
-
Description.
Note that the term cannot have more than one line of text.
Quoted paragraphs ( ref ) are created by just indenting them more than the surrounding paragraphs.
Line blocks ( ref ) are a way of preserving line breaks:
| These lines are
| broken exactly like in
| the source file.
There are also several more special blocks available:
-
field lists ( ref , with caveats noted in Field Lists )
-
option lists ( ref )
-
quoted literal blocks ( ref )
-
doctest blocks ( ref )
Literal blocks ¶
Literal code blocks (
ref
) are introduced by ending a
paragraph with the special marker
::
. The literal block must be indented
(and, like all paragraphs, separated from the surrounding ones by blank
lines):
This is a normal text paragraph. The next paragraph is a code sample::
It is not processed in any way, except
that the indentation is removed.
It can span multiple lines.
This is a normal text paragraph again.
This is a normal text paragraph. The next paragraph is a code sample:
It is not processed in any way, except
that the indentation is removed.
It can span multiple lines.
This is a normal text paragraph again.
The handling of the
::
marker is smart:
-
If it occurs as a paragraph of its own, that paragraph is completely left out of the document.
-
If it is preceded by whitespace, the marker is removed.
-
If it is preceded by non-whitespace, the marker is replaced by a single colon.
That way, the second sentence in the above example’s first paragraph would be rendered as “The next paragraph is a code sample:”.
Code highlighting can be enabled for these literal blocks on a document-wide
basis using the
highlight
directive and on a project-wide basis
using the
highlight_language
configuration option. The
code-block
directive can be used to set highlighting on a
block-by-block basis. These directives are discussed later.
Doctest blocks ¶
Doctest blocks ( ref ) are interactive Python sessions cut-and-pasted into docstrings. They do not require the literal blocks syntax. The doctest block must end with a blank line and should not end with with an unused prompt:
>>> 1 + 1
2
The doctest appears below,
>>> 1 + 1
Tables ¶
For grid tables ( ref ), you have to “paint” the cell grid yourself. They look like this:
+------------------------+------------+----------+----------+
| Header row, column 1 | Header 2 | Header 3 | Header 4 |
| (header rows optional) | | | |
+========================+============+==========+==========+
| body row 1, column 1 | column 2 | column 3 | column 4 |
+------------------------+------------+----------+----------+
| body row 2 | ... | ... | |
+------------------------+------------+----------+----------+
|
Header row, column 1 (header rows optional) |
Header 2 |
Header 3 |
Header 4 |
|---|---|---|---|
|
body row 1, column 1 |
column 2 |
column 3 |
column 4 |
|
body row 2 |
… |
… |
Simple tables ( ref ) are easier to write, but limited: they must contain more than one row, and the first column cells cannot contain multiple lines. They look like this:
===== ===== =======
A B A and B
===== ===== =======
False False False
True False False
False True False
True True True
===== ===== =======
|
A |
B |
A and B |
|---|---|---|
|
False |
False |
False |
|
True |
False |
False |
|
False |
True |
False |
|
True |
True |
True |
Two more syntaxes are supported: CSV tables and List tables . They use an explicit markup block . Refer to table directives in the Sphinx documentation for more information.
Hyperlinks ¶
External links ¶
Use
`Link
text
<https://domain.invalid/>`_
for inline web links. If the
link text should be the web address, you don’t need special markup at all, the
parser finds links and mail addresses in ordinary text.
Important
There must be a space between the link text and the opening < for the URL.
You can also separate the link and the target definition ( ref ), like this:
This is a paragraph that contains `a link`_.
.. _a link: https://domain.invalid/
This is a paragraph that contains a link .
Internal links ¶
Internal linking is done via a special reST role provided by Sphinx, see the section on specific markup.
Sections ¶
Section headers ( ref ) are created by underlining (and optionally overlining) the section title with a punctuation character, at least as long as the text:
=================
This is a heading
=================
Normally, there are no heading levels assigned to certain characters as the structure is determined from the succession of headings. However, this convention is used in Python’s Style Guide for documenting which you may follow:
-
#
with overline, for parts -
*
with overline, for chapters -
=
, for sections -
-
, for subsections -
^
, for subsubsections -
"
, for paragraphs
Of course, you are free to use your own marker characters (see the reST documentation), and use a deeper nesting level, but keep in mind that most target formats (HTML, LaTeX) have a limited supported nesting depth.
Field Lists ¶
Field lists ( ref ) are sequences of fields marked up like this:
:fieldname: Field content
They are commonly used in Python documentation:
def my_function(my_arg, my_other_arg):
"""A function just for me.
:param my_arg: The first of my arguments.
:param my_other_arg: The second of my arguments.
:returns: A message (just for me, of course).
"""
Sphinx extends standard docutils behavior and intercepts field lists specified at the beginning of documents. Refer to field lists in the Sphinx documentation for more information.
Roles ¶
A role or “custom interpreted text role” (
ref
) is an inline
piece of explicit markup. It signifies that that the enclosed text should be
interpreted in a specific way. Sphinx uses this to provide semantic markup and
cross-referencing of identifiers, as described in the appropriate section. The
general syntax is
:rolename:`content`
.
Docutils supports the following roles:
-
emphasis – equivalent of
*emphasis*
( emphasis ) -
strong – equivalent of
**strong**
( strong ) -
literal – equivalent of
``literal``
(literal
) -
subscript – subscript text (subscript subscript )
-
superscript – superscript text (superscript superscript )
-
title-reference – for titles of books, periodicals, and other materials
Refer to roles in the Sphinx documentation for roles added by Sphinx.
Explicit Markup ¶
“Explicit markup” ( ref ) is used in reST for most constructs that need special handling, such as footnotes, specially-highlighted paragraphs, comments, and generic directives.
An explicit markup block begins with a line starting with
..
followed by
whitespace and is terminated by the next paragraph at the same level of
indentation. (There needs to be a blank line between explicit markup and
normal paragraphs. This may all sound a bit complicated, but it is intuitive
enough when you write it.)
Directives ¶
A directive ( ref ) is a generic block of explicit markup. Along with roles, it is one of the extension mechanisms of reST, and Sphinx makes heavy use of it.
Docutils supports the following directives:
-
Admonitions: attention , caution , danger , error , hint , important , note , tip , warning and the generic admonition . (Most themes style only “note” and “warning” specially.)
Attention
Attention
Caution
Caution
Danger
Danger
Error
Error
Hint
Hint
Important
Important
Note
Note
Tip
Tip
Warning
Warning
-
Images:
-
Additional body elements:
-
contents (a local, i.e. for the current file only, table of contents)
-
container (a container with a custom class, useful to generate an outer
<div>
in HTML) -
rubric (a heading without relation to the document sectioning)
-
parsed-literal (literal block that supports inline markup)
-
epigraph (a block quote with optional attribution line)
-
highlights , pull-quote (block quotes with their own class attribute)
-
compound (a compound paragraph)
-
-
Special tables:
-
table (a table with title)
-
csv-table (a table generated from comma-separated values)
-
list-table (a table generated from a list of lists)
-
-
Special directives:
-
HTML specifics:
-
meta (generation of HTML
<meta>
tags, see also HTML Metadata below) -
title (override document title)
-
-
Influencing markup:
-
default-role (set a new default role)
-
role (create a new role)
Since these are only per-file, better use Sphinx’s facilities for setting the
default_role
. -
Directives added by Sphinx are described in directives in the Sphinx documentation.
Basically, a directive consists of a name, arguments, options and content. (Keep this terminology in mind, it is used in the next chapter describing custom directives.) Looking at this example,
.. function:: foo(x)
foo(y, z)
:module: some.module.name
Return a line of text input from the user.
function
is the directive name. It is given two arguments here, the
remainder of the first line and the second line, as well as one option
module
(as you can see, options are given in the lines immediately
following the arguments and indicated by the colons). Options must be indented
to the same level as the directive content.
The directive content follows after a blank line and is indented relative to the directive start.
Images ¶
reST supports an image directive ( ref ), used like so:
.. image:: gnu.png
(options)
When used within Sphinx, the file name given (here
gnu.png
) must either be
relative to the source file, or absolute which means that they are relative to
the top source directory. For example, the file
sketch/spam.rst
could
refer to the image
images/spam.png
as
../images/spam.png
or
/images/spam.png
.
Sphinx will automatically copy image files over to a subdirectory of the output
directory on building (e.g. the
_static
directory for HTML output.)
Interpretation of image size options (
width
and
height
) is as follows:
if the size has no unit or the unit is pixels, the given size will only be
respected for output channels that support pixels. Other units (like
pt
for
points) will be used for HTML and LaTeX output (the latter replaces
pt
by
bp
as this is the TeX unit such that
72bp=1in
).
Sphinx extends the standard docutils behavior by allowing an asterisk for the extension:
.. image:: gnu.*
Sphinx then searches for all images matching the provided pattern and
determines their type. Each builder then chooses the best image out of these
candidates. For instance, if the file name
gnu.*
was given and two files
gnu.pdf
and
gnu.png
existed in the source tree, the LaTeX
builder would choose the former, while the HTML builder would prefer the
latter. Supported image types and choosing priority are defined at
Welcome to documentation!
.
Note that image file names should not contain spaces.
Changed in version 0.4: Added the support for file names ending in an asterisk.
Changed in version 0.6: Image paths can now be absolute.
Changed in version 1.5:
latex target supports pixels (default is
96px=1in
).
Footnotes ¶
For footnotes (
ref
), use
[#name]_
to mark the footnote
location, and add the footnote body at the bottom of the document after a
“Footnotes” rubric heading, like so:
Lorem ipsum [#f1]_ dolor sit amet ... [#f2]_
.. rubric:: Footnotes
.. [#f1] Text of the first footnote.
.. [#f2] Text of the second footnote.
You can also explicitly number the footnotes (
[1]_
) or use auto-numbered
footnotes without names (
[#]_
).
Citations ¶
Standard reST citations ( ref ) are supported, with the additional feature that they are “global”, i.e. all citations can be referenced from all files. Use them like so:
Lorem ipsum [Ref]_ dolor sit amet.
.. [Ref] Book or article reference, URL or whatever.
Citation usage is similar to footnote usage, but with a label that is not
numeric or begins with
#
.
Substitutions ¶
reST supports “substitutions” (
ref
), which
are pieces of text and/or markup referred to in the text by
|name|
. They
are defined like footnotes with explicit markup blocks, like this:
.. |name| replace:: replacement *text*
or this:
.. |caution| image:: warning.png
:alt: Warning!
See the reST reference for substitutions for details.
If you want to use some substitutions for all documents, put them into
rst_prolog
or
rst_epilog
or put them into a separate file
and include it into all documents you want to use them in, using the
include
directive. (Be sure to give the include file a file name
extension differing from that of other source files, to avoid Sphinx finding it
as a standalone document.)
Sphinx defines some default substitutions.
Comments ¶
Every explicit markup block which isn’t a valid markup construct (like the footnotes above) is regarded as a comment ( ref ). For example:
.. This is a comment.
You can indent text after a comment start to form multiline comments:
..
This whole indented block
is a comment.
Still in the comment.
HTML Metadata ¶
The
meta
directive (
ref
) allows specifying the HTML
metadata element
of a Sphinx documentation page. For example, the
directive:
.. meta::
:description: The Sphinx documentation builder
:keywords: Sphinx, documentation, builder
will generate the following HTML output:
<meta name="description" content="The Sphinx documentation builder">
<meta name="keywords" content="Sphinx, documentation, builder">
Also, Sphinx will add the keywords as specified in the meta directive to the
search index. Thereby, the
lang
attribute of the meta element is
considered. For example, the directive:
.. meta::
:keywords: backup
:keywords lang=en: pleasefindthiskey pleasefindthiskeytoo
:keywords lang=de: bittediesenkeyfinden
adds the following words to the search indices of builds with different language configurations:
-
pleasefindthiskey
,pleasefindthiskeytoo
to English builds; -
bittediesenkeyfinden
to German builds; -
backup
to builds in all languages.
Source encoding ¶
Since the easiest way to include special characters like em dashes or copyright
signs in reST is to directly write them as Unicode characters, one has to
specify an encoding. Sphinx assumes source files to be encoded in UTF-8 by
default; you can change this with the
source_encoding
config value.
Gotchas ¶
There are some problems one commonly runs into while authoring reST documents:
-
Separation of inline markup: As said above, inline markup spans must be separated from the surrounding text by non-word characters, you have to use a backslash-escaped space to get around that. See the reference for the details.
-
No nested inline markup: Something like
*see :func:`foo`*
is not possible.
Footnotes
- 1
-
When the default domain contains a
class
directive, this directive will be shadowed. Therefore, Sphinx re-exports it asrst-class
.


This example shows how to create an asynchronous test with the YUI Test framework for testing browser-based JavaScript code. A YUITest.TestCase
object is created with a test that waits for a
few seconds before continuing. The YUITest.TestRunner
is then used to run the tests once the page has loaded.


8 references to NotStarted
System.Management.Automation (8)
engine\remoting\client\Job.cs (2)
567
public JobStateInfo JobStateInfo { get; private set; } = new JobStateInfo(JobState.
NotStarted
);
4397
if (_helpers.Count == 0 && this.JobStateInfo.State == JobState.
NotStarted
)
engine\remoting\client\Job2.cs (3)
727
ParentJobStateCalculation(new JobStateEventArgs(childJobStateInfo, new JobStateInfo(JobState.
NotStarted
)));
1790
if (JobStateInfo.State == JobState.
NotStarted
&& computedState == JobState.Running)
1829
computedJobState = JobState.
NotStarted
;
engine\remoting\client\ThrottlingJob.cs (2)
370
/// Thrown when the child job is not in the <see cref="JobState.
NotStarted
"/> state.
376
if (childJob.JobStateInfo.State != JobState.
NotStarted
) throw new ArgumentException(RemotingErrorIdStrings.ThrottlingJobChildAlreadyRunning, nameof(childJob));
engine\remoting\commands\ReceiveJob.cs (1)
221
return JobState.
NotStarted
;


Fecha_Creacion: 2018-04-15T17:56:09.117Z
Dimension: Phone Dimension
Id_Locacion: 72
Nombre: Earth (Phone Dimension)
Residentes: ['https://rickandmortyapi.com/api/character/404', 'https://rickandmortyapi.com/api/character/427', 'https://rickandmortyapi.com/api/character/428']
Tipo: Planet
URL: https://rickandmortyapi.com/api/location/72


Welcome to ezEngine
ezEngine is a free, open source game engine written in C++. Its philosophy is to be modular and flexible, such that it can be adapted to many different use cases. EZ utilizes a plugin system to integrate features such as FMOD or Jolt Physics. This makes it possible to only include those features that you need, or to replace systems with a custom solution that works better for your requirements.
Similarly, the EZ code base can be built in multiple tiers, where you either get the entire feature set, with a fully functional editor, asset management and renderer, or you can strip it down to just the base libraries and core engine functionality. This can be extremely useful if you need to build a lot of custom technology, but require a high-performance, reliable foundation. EZ has a strong emphasis on providing robust, easy to use and well-tested base functionality. It is successfully being used in such a capacity in commercial products.
When to use ezEngine
ezEngine is designed to be a great basis for complicated projects. It provides you with lots of functionality that is tedious and difficult to build, such as efficient STL like container classes, a high-performance scenegraph, resource streaming and much more. It can be used to build the tech for games, as well as for industry applications. In many code bases the lower level functionality is messy and buggy, because it is hard (and boring) to build these parts, and game developers rather spend time on making pretty pictures. In EZ the base functionality is clean, consistent, efficient and fully unit-tested. It builds on Windows, Mac, Linux and Android.
Out of the box EZ can be used to create games just with scripting. However, it is meant for people who need or want to build their own technology and are looking for a great foundation to build on top of. The ezEditor is a powerful and robust tool that enables quick iteration on ideas with fast startup-times and WYSIWYG real-time editing. It is also completely optional, in case you need a different kind of workflow.
EZ is also a very good fit for students interested in learning how modern game engines work. It is easy to setup, compiles fast, is well documented, and straight-forward to extend. We also welcome contributions in the form of code or art.
When not to use ezEngine
ezEngine is mainly developed on Windows. The renderer currently uses DX11. A Vulkan port is in development and the tools are being ported to Linux as well, however this is still in the early phase and not yet productively usable.
It is also not comparable in feature completeness to commercial offerings such as Unreal or Unity. Although it does support scripting game logic both with TypeScript and Visual Scripting, it is not meant for low-code or no-code development. The scripting capabilities are limited, for many game ideas you need to be comfortable writing C++ code.
Getting Started
- You can download prebuilt binaries or clone the latest dev branch.
- See the documentation for build instructions and available samples.
- Check out the FAQ.
- There are videos about various topics on our YouTube channel.
- If you need help, contact us.
- Everyone is welcome to contribute.


{{ quote.quote }}
Quote author: {{ quote.quoteAuthor }}
Posted by: {{ quote.userName }}
~~| Posted: {{ quote.date | elapsedTime }} |~~
~~| most likes |~~


| Package | Description |
|---|---|
| org.deeplearning4j.nn.transferlearning |
| Modifier and Type | Method and Description |
|---|---|
TransferLearning.Builder |
TransferLearning.Builder.addLayer(Layer layer)
Add layers to the net
Required if layers are removed.
|
TransferLearning.Builder |
TransferLearning.Builder.fineTuneConfiguration(FineTuneConfiguration finetuneConfiguration)
Fine tune configurations specified will overwrite the existing configuration if any
Usage example: specify a learning rate will set specified learning rate on all layers
Refer to the fineTuneConfiguration class for more details
|
TransferLearning.Builder |
TransferLearning.Builder.nInReplace(int layerNum,
int nIn,
IWeightInit scheme)
Modify the architecture of a vertex layer by changing nIn of the specified layer.
|
TransferLearning.Builder |
TransferLearning.Builder.nInReplace(int layerNum,
int nIn,
WeightInit scheme)
Modify the architecture of a vertex layer by changing nIn of the specified layer.
|
TransferLearning.Builder |
TransferLearning.Builder.nInReplace(int layerNum,
int nIn,
WeightInit scheme,
Distribution dist)
Modify the architecture of a vertex layer by changing nIn of the specified layer.
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
Distribution dist)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
Distribution dist,
Distribution distNext)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
Can specify different weight init schemes for the specified layer and the layer that follows it.
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
Distribution dist,
WeightInit schemeNext)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
Can specify different weight init schemes for the specified layer and the layer that follows it.
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
IWeightInit scheme,
IWeightInit schemeNext)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
Can specify different weight init schemes for the specified layer and the layer that follows it.
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
WeightInit scheme)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
WeightInit scheme,
Distribution distNext)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
Can specify different weight init schemes for the specified layer and the layer that follows it.
|
TransferLearning.Builder |
TransferLearning.Builder.nOutReplace(int layerNum,
int nOut,
WeightInit scheme,
WeightInit schemeNext)
Modify the architecture of a layer by changing nOut
Note this will also affect the layer that follows the layer specified, unless it is the output layer
Can specify different weight init schemes for the specified layer and the layer that follows it.
|
TransferLearning.Builder |
TransferLearning.Builder.removeLayersFromOutput(int layerNum)
Remove last "n" layers of the net
At least an output layer must be added back in
|
TransferLearning.Builder |
TransferLearning.Builder.removeOutputLayer()
Helper method to remove the outputLayer of the net.
|
TransferLearning.Builder |
TransferLearning.Builder.setFeatureExtractor(int layerNum)
Specify a layer to set as a "feature extractor"
The specified layer and the layers preceding it will be "frozen" with parameters staying constant
|
TransferLearning.Builder |
TransferLearning.Builder.setInputPreProcessor(int layer,
InputPreProcessor processor)
Specify the preprocessor for the added layers
for cases where they cannot be inferred automatically.
|
TransferLearning.Builder |
TransferLearning.Builder.validateOutputLayerConfig(boolean validate) |
Copyright © 2020. All rights reserved.


Actions, resources, and condition keys for AWS IoT Greengrass
AWS IoT Greengrass (service prefix:
greengrass
) provides the following service-specific resources, actions, and condition context keys for use in IAM permission policies.
References:
-
Learn how to configure this service .
-
View a list of the API operations available for this service .
-
Learn how to secure this service and its resources by using IAM permission policies.
Topics
Actions defined by AWS IoT Greengrass
You can specify the following actions in the
Action
element of an IAM policy statement. Use policies to grant permissions to perform an operation in AWS. When you use an action in a policy, you usually allow or deny access to the API operation or CLI command with the same name. However, in some cases, a single action controls access to more than one operation. Alternatively, some operations require several different actions.
The
Resource types
column of the Actions table indicates whether each action supports resource-level permissions. If there is no value for this column, you must specify all resources ("*") to which the policy applies in the
Resource
element of your policy statement. If the column includes a resource type, then you can specify an ARN of that type in a statement with that action. If the action has one or more required resources, the caller must have permission to use the action with those resources. Required resources are indicated in the table with an asterisk (*). If you limit resource access with the
Resource
element in an IAM policy, you must include an ARN or pattern for each required resource type. Some actions support multiple resource types. If the resource type is optional (not indicated as required), then you can choose to use one of the optional resource types.
The
Condition keys
column of the Actions table includes keys that you can specify in a policy statement's
Condition
element. For more information on the condition keys that are associated with resources for the service, see the
Condition keys
column of the Resource types table.
For details about the columns in the following table, see Actions table .
| Actions | Description | Access level | Resource types (*required) | Condition keys | Dependent actions |
|---|---|---|---|---|---|
| AssociateRoleToGroup | Grants permission to associate a role with a group. The role's permissions must allow Greengrass core Lambda functions and connectors to perform actions in other AWS services | Write | |||
| AssociateServiceRoleToAccount | Grants permission to associate a role with your account. AWS IoT Greengrass uses this role to access your Lambda functions and AWS IoT resources | Permissions management | |||
| CreateConnectorDefinition | Grants permission to create a connector definition | Write | |||
| CreateConnectorDefinitionVersion | Grants permission to create a version of an existing connector definition | Write | |||
| CreateCoreDefinition | Grants permission to create a core definition | Write | |||
| CreateCoreDefinitionVersion | Grants permission to create a version of an existing core definition. Greengrass groups must each contain exactly one Greengrass core | Write | |||
| CreateDeployment | Grants permission to create a deployment | Write | |||
| CreateDeviceDefinition | Grants permission to create a device definition | Write | |||
| CreateDeviceDefinitionVersion | Grants permission to create a version of an existing device definition | Write | |||
| CreateFunctionDefinition | Grants permission to create a Lambda function definition to be used in a group that contains a list of Lambda functions and their configurations | Write | |||
| CreateFunctionDefinitionVersion | Grants permission to create a version of an existing Lambda function definition | Write | |||
| CreateGroup | Grants permission to create a group | Write | |||
| CreateGroupCertificateAuthority | Grants permission to create a CA for the group, or rotate the existing CA | Write | |||
| CreateGroupVersion | Grants permission to create a version of a group that has already been defined | Write | |||
| CreateLoggerDefinition | Grants permission to create a logger definition | Write | |||
| CreateLoggerDefinitionVersion | Grants permission to create a version of an existing logger definition | Write | |||
| CreateResourceDefinition | Grants permission to create a resource definition that contains a list of resources to be used in a group | Write | |||
| CreateResourceDefinitionVersion | Grants permission to create a version of an existing resource definition | Write | |||
| CreateSoftwareUpdateJob | Grants permission to create an AWS IoT job that will trigger your Greengrass cores to update the software they are running | Write | |||
| CreateSubscriptionDefinition | Grants permission to create a subscription definition | Write | |||
| CreateSubscriptionDefinitionVersion | Grants permission to create a version of an existing subscription definition | Write | |||
| DeleteConnectorDefinition | Grants permission to delete a connector definition | Write | |||
| DeleteCoreDefinition | Grants permission to delete a core definition. Deleting a definition that is currently in use in a deployment affects future deployments | Write | |||
| DeleteDeviceDefinition | Grants permission to delete a device definition. Deleting a definition that is currently in use in a deployment affects future deployments | Write | |||
| DeleteFunctionDefinition | Grants permission to delete a Lambda function definition. Deleting a definition that is currently in use in a deployment affects future deployments | Write | |||
| DeleteGroup | Grants permission to delete a group that is not currently in use in a deployment | Write | |||
| DeleteLoggerDefinition | Grants permission to delete a logger definition. Deleting a definition that is currently in use in a deployment affects future deployments | Write | |||
| DeleteResourceDefinition | Grants permission to delete a resource definition | Write | |||
| DeleteSubscriptionDefinition | Grants permission to delete a subscription definition. Deleting a definition that is currently in use in a deployment affects future deployments | Write | |||
| DisassociateRoleFromGroup | Grants permission to disassociate the role from a group | Write | |||
| DisassociateServiceRoleFromAccount | Grants permission to disassociate the service role from an account. Without a service role, deployments will not work | Write | |||
| Discover | Grants permission to retrieve information required to connect to a Greengrass core | Read | |||
| GetAssociatedRole | Grants permission to retrieve the role associated with a group | Read | |||
| GetBulkDeploymentStatus | Grants permission to return the status of a bulk deployment | Read | |||
| GetConnectivityInfo | Grants permission to retrieve the connectivity information for a core | Read | |||
| GetConnectorDefinition | Grants permission to retrieve information about a connector definition | Read | |||
| GetConnectorDefinitionVersion | Grants permission to retrieve information about a connector definition version | Read | |||
| GetCoreDefinition | Grants permission to retrieve information about a core definition | Read | |||
| GetCoreDefinitionVersion | Grants permission to retrieve information about a core definition version | Read | |||
| GetDeploymentStatus | Grants permission to return the status of a deployment | Read | |||
| GetDeviceDefinition | Grants permission to retrieve information about a device definition | Read | |||
| GetDeviceDefinitionVersion | Grants permission to retrieve information about a device definition version | Read | |||
| GetFunctionDefinition | Grants permission to retrieve information about a Lambda function definition, such as its creation time and latest version | Read | |||
| GetFunctionDefinitionVersion | Grants permission to retrieve information about a Lambda function definition version, such as which Lambda functions are included in the version and their configurations | Read | |||
| GetGroup | Grants permission to retrieve information about a group | Read | |||
| GetGroupCertificateAuthority | Grants permission to return the public key of the CA associated with a group | Read | |||
| GetGroupCertificateConfiguration | Grants permission to retrieve the current configuration for the CA used by a group | Read | |||
| GetGroupVersion | Grants permission to retrieve information about a group version | Read | |||
| GetLoggerDefinition | Grants permission to retrieve information about a logger definition | Read | |||
| GetLoggerDefinitionVersion | Grants permission to retrieve information about a logger definition version | Read | |||
| GetResourceDefinition | Grants permission to retrieve information about a resource definition, such as its creation time and latest version | Read | |||
| GetResourceDefinitionVersion | Grants permission to retrieve information about a resource definition version, such as which resources are included in the version | Read | |||
| GetServiceRoleForAccount | Grants permission to retrieve the service role that is attached to an account | Read | |||
| GetSubscriptionDefinition | Grants permission to retrieve information about a subscription definition | Read | |||
| GetSubscriptionDefinitionVersion | Grants permission to retrieve information about a subscription definition version | Read | |||
| GetThingRuntimeConfiguration | Grants permission to retrieve runtime configuration of a thing | Read | |||
| ListBulkDeploymentDetailedReports | Grants permission to retrieve a paginated list of the deployments that have been started in a bulk deployment operation and their current deployment status | Read | |||
| ListBulkDeployments | Grants permission to retrieve a list of bulk deployments | List | |||
| ListConnectorDefinitionVersions | Grants permission to list the versions of a connector definition | List | |||
| ListConnectorDefinitions | Grants permission to retrieve a list of connector definitions | List | |||
| ListCoreDefinitionVersions | Grants permission to list the versions of a core definition | List | |||
| ListCoreDefinitions | Grants permission to retrieve a list of core definitions | List | |||
| ListDeployments | Grants permission to retrieve a list of all deployments for a group | List | |||
| ListDeviceDefinitionVersions | Grants permission to list the versions of a device definition | List | |||
| ListDeviceDefinitions | Grants permission to retrieve a list of device definitions | List | |||
| ListFunctionDefinitionVersions | Grants permission to list the versions of a Lambda function definition | List | |||
| ListFunctionDefinitions | Grants permission to retrieve a list of Lambda function definitions | List | |||
| ListGroupCertificateAuthorities | Grants permission to retrieve a list of current CAs for a group | List | |||
| ListGroupVersions | Grants permission to list the versions of a group | List | |||
| ListGroups | Grants permission to retrieve a list of groups | List | |||
| ListLoggerDefinitionVersions | Grants permission to list the versions of a logger definition | List | |||
| ListLoggerDefinitions | Grants permission to retrieve a list of logger definitions | List | |||
| ListResourceDefinitionVersions | Grants permission to list the versions of a resource definition | List | |||
| ListResourceDefinitions | Grants permission to retrieve a list of resource definitions | List | |||
| ListSubscriptionDefinitionVersions | Grants permission to list the versions of a subscription definition | List | |||
| ListSubscriptionDefinitions | Grants permission to retrieve a list of subscription definitions | List | |||
| ListTagsForResource | Grants permission to list the tags for a resource | Read | |||
| ResetDeployments | Grants permission to reset a group's deployments | Write | |||
| StartBulkDeployment | Grants permission to deploy multiple groups in one operation | Write | |||
| StopBulkDeployment | Grants permission to stop the execution of a bulk deployment | Write | |||
| TagResource | Grants permission to add tags to a resource | Tagging | |||
| UntagResource | Grants permission to remove tags from a resource | Tagging | |||
| UpdateConnectivityInfo | Grants permission to update the connectivity information for a Greengrass core. Any devices that belong to the group that has this core will receive this information in order to find the location of the core and connect to it | Write | |||
| UpdateConnectorDefinition | Grants permission to update a connector definition | Write | |||
| UpdateCoreDefinition | Grants permission to update a core definition | Write | |||
| UpdateDeviceDefinition | Grants permission to update a device definition | Write | |||
| UpdateFunctionDefinition | Grants permission to update a Lambda function definition | Write | |||
| UpdateGroup | Grants permission to update a group | Write | |||
| UpdateGroupCertificateConfiguration | Grants permission to update the certificate expiry time for a group | Write | |||
| UpdateLoggerDefinition | Grants permission to update a logger definition | Write | |||
| UpdateResourceDefinition | Grants permission to update a resource definition | Write | |||
| UpdateSubscriptionDefinition | Grants permission to update a subscription definition | Write | |||
| UpdateThingRuntimeConfiguration | Grants permission to update runtime configuration of a thing | Write |
Resource types defined by AWS IoT Greengrass
The following resource types are defined by this service and can be used in the
Resource
element of IAM permission policy statements. Each action in the
Actions table
identifies the resource types that can be specified with that action. A resource type can also define which condition keys you can include in a policy. These keys are displayed in the last column of the Resource types table. For details about the columns in the following table, see
Resource types table
.
| Resource types | ARN | Condition keys |
|---|---|---|
| connectivityInfo |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/things/$
{
ThingName}/connectivityInfo
|
|
| certificateAuthority |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/groups/$
{
GroupId}/certificateauthorities/$
{
CertificateAuthorityId}
|
|
| deployment |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/groups/$
{
GroupId}/deployments/$
{
DeploymentId}
|
|
| bulkDeployment |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/bulk/deployments/$
{
BulkDeploymentId}
|
|
| group |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/groups/$
{
GroupId}
|
|
| groupVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/groups/$
{
GroupId}/versions/$
{
VersionId}
|
|
| coreDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/cores/$
{
CoreDefinitionId}
|
|
| coreDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/cores/$
{
CoreDefinitionId}/versions/$
{
VersionId}
|
|
| deviceDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/devices/$
{
DeviceDefinitionId}
|
|
| deviceDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/devices/$
{
DeviceDefinitionId}/versions/$
{
VersionId}
|
|
| functionDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/functions/$
{
FunctionDefinitionId}
|
|
| functionDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/functions/$
{
FunctionDefinitionId}/versions/$
{
VersionId}
|
|
| subscriptionDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/subscriptions/$
{
SubscriptionDefinitionId}
|
|
| subscriptionDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/subscriptions/$
{
SubscriptionDefinitionId}/versions/$
{
VersionId}
|
|
| loggerDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/loggers/$
{
LoggerDefinitionId}
|
|
| loggerDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/loggers/$
{
LoggerDefinitionId}/versions/$
{
VersionId}
|
|
| resourceDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/resources/$
{
ResourceDefinitionId}
|
|
| resourceDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/resources/$
{
ResourceDefinitionId}/versions/$
{
VersionId}
|
|
| connectorDefinition |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/connectors/$
{
ConnectorDefinitionId}
|
|
| connectorDefinitionVersion |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/definition/connectors/$
{
ConnectorDefinitionId}/versions/$
{
VersionId}
|
|
| thing |
arn:$
{
Partition}:iot:$
{
Region}:$
{
Account}:thing/$
{
ThingName}
|
|
| thingRuntimeConfig |
arn:$
{
Partition}:greengrass:$
{
Region}:$
{
Account}:/greengrass/things/$
{
ThingName}/runtimeconfig
|
Condition keys for AWS IoT Greengrass
AWS IoT Greengrass defines the following condition keys that can be used in the
Condition
element of an IAM policy. You can use these keys to further refine the conditions under which the policy statement applies. For details about the columns in the following table, see
Condition keys table
.
To view the global condition keys that are available to all services, see Available global condition keys .
| Condition keys | Description | Type |
|---|---|---|
| aws:RequestTag/${TagKey} | Filters access by the allowed set of values for each of the mandatory tags | String |
| aws:ResourceTag/${TagKey} | Filters access by the tag value associated with the resource | String |
| aws:TagKeys | Filters access by the presence of mandatory tags in the request | ArrayOfString |