Please download agentsV3WithPowerloomForStudents.zip and unzip it in the usual way to the directory of your choice. Here is what you will find:
1. The same restaurant application that you are familiar with but with two changes:
a. A* is already integrate into the WaiterAgent. You may use mine or substitute your own solution.
b. Powerloom is integrated into the code. Much more about that later.
2. In the doc directory you will find:
a. restaurant.plm – This is the powerloom file, written by Jon Stinzel, that corresponds to my circles and arrows picture (shown later in this document). You need to become intimately familiar with this file.
b. restcmd.plm – This is a powerloom file that has the queries to test restaurant.plm. Jon also wrote it.
c. PowerLoomExample.java – This file shows how to write Java code to interface to Powerloom. Dr. Tom Russ supplied it. I used it extensively to implement my agent code.
d. DesignDocV3.0.doc – This is the original design document for the original V3.0 agents. Denise Nemenz wrote it. She also wrote the original v3.0 agents.
e. RestaurantAssignment.htm – This document.
Here’s how Powerloom has been integrated into the restaurant code:
1. In RestaurantGui.java
a.
In the main routine -
PowerloomHelper.doPowerLoomRestaurantStartup();
This initializes powerloom and reads in restaurant.plm.
b.
In the constructor, powerloom instances for our restaurant are
created. There are two gettr’s:
String getrestaurantInstance() and String getneighborhoodInstance().
You will notice that all powerloom instances are of type String.
2. In Host.java
a. In the constructor, the host is instantiated in Powerloom and asserted to be an employee of our restaurant.
b. Every agent has a variable to hold its instance: String loomInstance
3. In PowerloomHelper.java
a. I have put several helper functions there. When you explore Customer.java you will see how to use them.
b. When PowerloomHelper.instantiate(loomInstance, Agent) is called, an entry is added to the static hashmap loomMap. This is how we associate powerloom instances with our Java pointers for the agent. Look in CustomerAgent.java to see how he gets the HostAgent using this map.
4. CustomerAgent.java – I have completely converted this agent to work with Powerloom.
a.
When this constructor is called by the gui (after you selected
Create Customer on the gui), we look him up in powerloom. Two things can happen:
· The name of the customer is one we already know from restaurant.plm. In that case, we simply set loomInstance to it.
· If we don't find the customer in restaurant.plm, then we (1) create new a instance for him, (2) assert he has a home in our restaurant's neighborhood. We don't know anything about his home, so the go-to-restaurant rule will fire and he'll be seated.
b. The variables it uses to store information it and reason with have been replaced by loom instances:
·
private String state
replaces AgentState state
· AgentState used to be an enum and is now static strings.
· boolean isHungry is now maintained by powerloom
c. In the message reception code, assertions are made instead of setting Java variables.
d. In the schedule, decisions are made by making queries to powerloom.
e. In the actions, assertions and retractions are made to represent what is going on.
 We’ll see; that’s what the discussion board is for.
1. Add code to CustomerAgent.java so that he’ll eat at home if there is food there and he is hungry. I have annotated its scheduler to show you where to put the code. Do this first to become familiar with how the code works. This addition will have no role in the animation. Only the print output will tell us it worked.
2. Change the Waiter, Cook, and Host in the same way I changed CustomerAgent.java. In other words all of their data storage and reasoning should be done with powerloom. Almost all the concepts, relations, and rules you need are already in restaurant.plm. You may have to add some.
3. HostAgent.java
a. Each of the following is to be replaced by using powerloom to store the information:
· List<CustomerAgent> waitList - This is where entering customers was stored.
· List<MyWaiter> waiters - This is where the waiters are stored.
· Table tables[] - This is where the Host keeps his table assignments.
· int nextWaiter - This is the hack the code uses to rotate among the waiters. We’ll try to figure out a good way to do this with powerloom on the discussion board.
b. The classes MyWaiter and Table should be commented out. You shouldn’t need them.
4. WaiterAgent.java – This is the most complicated Agent. You will have to add stuff to restaurant.plm; when you do this, test it out in Powerloom first.
a. Each of the following is to be replaced by using powerloom to store the information.
· The booleans: working, onBreak, and startedBreak. [Don’t worry at first about the on break protocol and the onBreak, and startedBreak booleans. Make sure your waiters are “working”. You can do the on break stuff for extra credit.]
· enum CustomerState. Look how CustomerState is handled in restaurant.plm and CustomerAgent.java. Notice that in this agent CustomerState is how the customer is viewed by the waiter. So it needs a different name in restaurant.plm, something like WaitersViewOfCustomer.
· List<MyCustomer> customers – This is where customers who assigned by the host are stored. Use the CustomerAssignment concept in restaurant.plm.
b. The MyCustomer class should be commented out.
c. Don’t touch anything that has to do with the animation.
5. CookAgent.java
a. Each of the following is to be replaced by using powerloom to store the information:
· ArrayList<Order> orders – This is where the cook stores his orders. Use the FoodOrder concept in restaurant.plm.
b. The Order class should be commented out.
c. Don’t touch anything that has to do with the animation.
The idea is that the restaurant should work exactly the same as it did before powerloom, except now its reasoning and storage are done by powerloom.
One of the main reasons for using powerloom is so that I could replace code like this (found in the Host.java scheduler)
if(!waitList.isEmpty() &&
!waiters.isEmpty()){
synchronized(waiters){
//Finds
the next waiter that is working
while(!waiters.get(nextWaiter).working){
nextWaiter =
(nextWaiter+1)%waiters.size();
}
}
print("picking waiter
number:"+nextWaiter);
//Then runs through the tables and finds
the first unoccupied
//table and tells the waiter to sit the
first customer at that table
for(int i=0; i < nTables; i++){
if(!tables[i].occupied){
synchronized(waitList){
tellWaiterToSitCustomerAtTable(waiters.get(nextWaiter),
waitList.get(0), i);
}
return true;
}
}
}
With one retrieval that says something like this pseudocode:
if (thereExists (?customer ?waiter ?table) such that
(and (WaitingCustomer ?customer)
(WorkingWaiter ?waiter)
(EmptyTable ?table))
then call the action tellWaiterToSitCustomerAtTable(?waiter, ?customer, ?table)
It won’t be exactly that easy, but you should get the idea. All that searching code currently in the agent is to be replaced by powerloom retrievals.
&ne already encoded many of the rules in restaurant.plm. For example:
(defrelation
restaurantNearby ((?p person) (?r restaurant))
:<=> (exists
(?h ?l)
(AND
(person ?p)
(lives ?p ?h)
(home ?h)
(hasLocation ?h ?l)
(neighborhood ?l)
(restaurant ?r)
(hasLocation ?r ?l))))
This relation appeared in the CustomerAgent scheduling rules.
(defrelation atHome ((?p person))
:<=> (exists
(?h)
(AND
(home ?h)
(isAt ?p ?h))))
(defconcept
foodAtHome ((?h home))
:<=> (exists
(?k ?r ?f)
(AND
(hasArea ?h ?k)
(kitchen ?k)
(hasAppliance ?k ?r)
(hasFood ?r ?f))))
(defrelation
eatAtHome ((?p person))
:<=> (exists
(?h)
(AND
(hungry ?p)
(lives ?p ?h)
(atHome ?p)
(foodAtHome ?h))))
(defconcept
waitingCustomer (?c)
:<=> (AND
(customer ?c)
(waiting ?c)))
(defconcept
workingWaiter (?w)
:<=> (AND
(waiter ?w)
(working ?w)))
(defconcept occupiedTable (?t)
:<=> (AND
(mesa ?t)
(exists (?c) (occupiedBy ?t ?c))))
(defconcept
occupiedTable (?t)
:<=> (AND
(mesa ?t)
(exists (?c) (occupiedBy ?t ?c))))
The word Table is reserved by Powerloom, so Jon had to pick something else. A table in Spanish is mesa. You can change it to anything you want.
(defrelation client
(?x ?c)
:<= (exists
(?a)(AND (employee ?x)
(hasAssignment ?x ?a)
(assignment ?a)
(identifies ?a ?c))))
It certainly wouldn’t surprise me if you needed more rules. The discussion board is the place to discuss this.
In addition, restaurant.pl contains many instances of people and restaurants. In particular:
· Joe and Jane live in the same neighborhood as our restaurant.
· Steve lives in a different neighborhood, but has food in his refrigerator. So when you finish the first part of this assignment, Steve should eat at home once he is made hungry.
· Jim lives in a different neighborhood, but does not have food in his refrigerator. When you make him hungry, no rule should fire.
So, when you run the restaurant, if you create customers named Joe or Jane, they should appear normally. If you create Steve, he should eat at home. If you create Jim, nothing will happen; his scheduler will not find anything to do.
Of course, you can create more instances.
The Circles and Arrows diagrams follow. It should conform to what you see in restaurant.plm. Please post discrepancies that you find.


Gridlines Class
Gridlines draws gridlines on a Graph.
Item Index
Properties
Methods
_drawGridlines
()
private
Algorithm for drawing gridlines
_getDefaultStyles
()
protected
Gets the default value for the styles
attribute. Overrides
base implementation.
Returns:
Object
_horizontalLine
(
private
-
path
-
pt
-
w
-
h
Algorithm for horizontal lines.
Parameters:
-
path
PathReference to path element
-
pt
ObjectCoordinates corresponding to a major unit of an axis.
-
w
NumberWidth of the Graph
-
h
NumberHeight of the Graph
_verticalLine
(
private
-
path
-
pt
-
w
-
h
Algorithm for vertical lines.
Parameters:
-
path
PathReference to path element
-
pt
ObjectCoordinates corresponding to a major unit of an axis.
-
w
NumberWidth of the Graph
-
h
NumberHeight of the Graph
draw
()
protected
Draws the gridlines
remove
()
private
Removes the Gridlines.
Properties
_path
Path
private
Reference to the Path
element used for drawing Gridlines.


Following the Gatewatch's defeat on Amonkhet, Jace travels to Ixalan in search of an artifact known as the Immortal Sun. However, Jace soon finds he is unable to report his discovery to the rest of the Gatewatch.


How to hide gun and UI to make stunning videos - Better Battlelog Forums #1634
Sitemap
15. April 2012 18:43
Topicstarter
BrainFooLong
Administrator
As the title said, here my little tutorial.
Still works after the new Patch.
http://www.youtube.com/watch?v=ImNDmbL3B00&list=UUAx-EYFYnLWwWITzG8_CgdA&index=2&feature=plcp
16. April 2012 00:02
ORFK
Global Moderator
Yeah Thanks! We can use it for our own (maximalCreative) Video Projects =)


Phonology Problem Set Generator
Configuration
Instructions:
- (Optional) Give the problem set a title and (GitHub Flavored Markdown) description.
- Upload a dataset in CSV format, or choose one from the dropdown list.
- (Optional) Upload a set of features in CSV format; if no feature set is uploaded, the default one displayed will be used.
- Use the checkboxes to select which entries to include; you can choose to include or exclude specific entries, as well as those including specific phonemes or phonemes with specific features. Use <Tab> and <Alt-Tab> to walk through checkboxes.
- Print using your browser's print functionality or the button below; only the title, description, and the data you choose to include will be printed. Your browser should allow you to print to PDF if you would like electronic copies. Entries will be automatically numbered.
- Changes you make will be reflected immediately.
Dataset
Nothing uploaded yet!


Search the surrounding region for the Idols eyes or die. The choice is yours.


Followers: {{profile.followers}} Following: {{profile.following}} Public Repos: {{profile.public_repos}}
View profile on github
{{repo.description}}


Upload PDF with the file dialog or by dragging and dropping onto the dashed region
PDF not selected
Select PDF file


Eden Hazard backs Chelsea to beat Manchester City this weekend
by Shambhu AjithChelsea take on Manchester City in the Premier League on Saturday and Eden Hazard has backed his former side to beat Pep Guardiola's men. The Real Madrid star was talking to Sky Sports News when he was asked if he watches Chelsea matches and if he thinks the Blues can beat City this weekend.
Hazard said: “Of course I think so. It’s not going to be easy. It’s hard to play there. Last time we played them we lost 6-0, so bad memories for me and for Chelsea as well.”
“But I think this season they are really good. They are really young, but they are really good, so why not go there and win the game?”
Chelsea have enjoyed a good start to the season and occupy the third spot in the table. Hazard, on the other hand, is slowly getting into the groove at Real Madrid. After a poor start in the Spanish capital, the Belgian has found some form and is playing well for the Spanish side, although he is yet to hit top gear.
Real Madrid are joint top of La Liga with 25 points from 12 games. However, they've not been at their best in the Champions League; they were outplayed by PSG and also held to a draw at home by Club Brugge in a couple of their matches.


2. h5gate format specification language¶
| Revision: | 0.9.1 |
|---|---|
| Date: | May 1, 2017 [1] |
2.1. Introduction¶
This API for the NWB format is built using a domain-independent specification language which allows specifying formats for data stored in HDF5. The system provides the following features:
- A single, human-readable file is used to specify a “core” format.
(For the NWB format, this file is
nwb_core.py
). - The core format can be extended to incorporate new use cases by creating “extensions” to the core format.
- Both the core format and extensions are written in the same specification language (described in this document).
- Write APIs are provided for both Python and Matlab. The write APIs are independent of the format and do not change when extensions are used. This allows extensions to be shared without the API software needing to be modified to use different extensions.
- Files in the fomat can be validated to ensure that they are consistent with the core format and any used extensions.
- Documentation for the core format and extensions can be generated from the specification files (and from data files created using the API because these include the specifications files).
- Specification files (both for the core format and extensions) can be validated using JSON Schema (http://json-schema.org).
The main program that implements these features is called “h5gate.” The “h5” refers to HDF5 (but other backends may be possible). The “gate” refers to the concept of controlling access, like a gate in a fence, because the write APIs control the addition of data into files to conform to that indicated by the format specification. The specification language and h5gate were designed for the NWB format, but may also be useful for other formats. The operation of the specification language is shown in Fig. 2.1.1.
| [1] | The reversion number is for this document and is independent of the version number for the NWB format. The date is the last modification date of this document. |
2.2. High-level organization¶
The specification language is written using a Python dictionary in a JSON-like syntax, which can easily be converted to JSON. A Python dictionary is used rather than pure JSON because Python allows inserting comments and also provides more readable ways to include long strings.
2.2.1. Schema-Id (or namespace)¶
The top-level of a format specification has the following form:
{"fs": {
"ns1": <specification for schema 'ns1'>,
"ns2": *\<specification for schema 'ns2'>,
"ns3": *\<specification for schema 'ns3'>, ... }
}
The top level identifier must be “fs”. (This stands for “format specification”). The value of “fs” is a dictionary with each key the “schema-Id” (or “namespace”) of a format specification that is associated with that schema-Id. The schema-Ids can be any valid Python string (they are not restricted to start with ‘ns’). One of the schemas-Ids is designated as the “default” and it is associated with the core format. Other schema-Ids are associated with extensions to the core format. Information indicating where to obtain the specifications (usually names of files containing the specifications) and the default schema-Id are passed into the API software when it is initialized.
2.2.2. Top level components¶
The specification associated with each schema-Id is a Python dictionary with three keys: info, schema, and doc. e.g.:
{
"info": <info specification>,
"schema": <schema specification>,
"doc": <auxiliary documentation>,
}
“info” and “schema” are required. “doc” is optional. <info
specification>
has the following form:
{
"name": "<Name of specification>",
"version": "<version number>",
"date": "<date last modified or released>",
"author": "<author name>",
"contact": "<author email or other contact info>",
"description": "<description of the specification>"
}
The <schema specification>
section defines the groups, datasets and
relationship that make up the format. This is the main part of the
format specification. It is described in the following sections.
The <auxiliary documentation>
section is for text that is added to
documentation that is generated from the format
specification, using the make_docs.py
tool. This is not described
further in this document, but the structure and operation can be deduced
by examining this part of the NWB format specification in file
nwb_core.py
and the generated documentation for the NWB format.
The top level components are 2.2.2 Top level components (see above). They are also at 2.2.2 Top level components (Top level components) (also see above).
But these work: Top level components (see above). They are also at top_level_components (also see above).
2.2.3. Schema specification¶
The <schema specification>
consist of a Python dictionary where each key
has the following form:
[<absolute_path>] <identifier> [<group-flag>] [<quantity-flag>]
<absolute_path>
is optional. If present, it starts with a slash (“/”),
and specifies the absolute location within an HDF5 file of the group or
dataset. For the root group, the absolute path is empty and the
identifier is “/”.
<identifier>
is required. Identifiers that start with “<“ and end
with “>” have a “variable” name, that is, the name is specified
through an API call when creating the group or dataset. If the identifier
does not start and end with angle brackets, then the name is fixed and is
the same as the identifier.
<group-flag>
is optional. If present, it is a “/” to indicate that the
identifier is associated with a group. If absent, the identifier is associated
with a dataset.
<quantity_flag>
is optional. It is used to indicate if the HDF5 dataset
or group associated with the identifier is required, optional, recommended or
if there are multiple instances required. (The term “quantity” was chosen
for this because some of the characters used for the <quantity_flag>
have
the same meaning as characters used to specifies quantities in regular
expressions). If present, the <quantity_flag>
is a single character,
one of: “?”, “!”, “^”, “+” or “*”. These mean:
! - Required (this is the default)
? - Optional
^ - Recommended
+ - One or more instances of variable-named identifier required
* - Zero or more instances of variable-named identifier allowed
Some example schema specification keys and their meaning are given below:
Unspecified location (no leading slash):
foo - dataset, name is “foo”
foo/ - group, name is “foo”
<foo> - dataset, variable name
<foo>/ - group, variable name
Specified location (has leading slash). Meaning same as above, but location specified:
/some/path/foo – dataset, name is “foo”, located at /some/path/
/some/path/foo/ – group, name is “foo”, located at /some/path/
/some/path/<foo> – dataset, variable name, located at /some/path
/some/path/<foo>/ – group, variable name, located at /some/path
With quantity specified:
foo? – dataset, name is “foo”. Is optional
foo/^ – group, name is “foo”. Is recommended
<foo>* – dataset, variable name, zero or more allowed
<foo>+ – group, variable name, at least one required
When an absolute path is specified (or if the identifier is for the root group) the identifier is “anchored” to the specified location. If there is no absolute path, then the group or dataset associated with the identifier can be incorporated into other groups using the “include” or “merge” directives that are described below.
2.2.4. Extensions¶
As mentioned, extensions to the core format are specified using schema-Ids that are different from the schema-id used for the core format. The way that extensions are implemented is very simple: The schema specified in extensions are simply “merged” into the schema specified in the core format based on having the same absolute path (if given) and the same identifier. For example, if the core format schema includes key “<foo>/” (specifying a group with a variable name “foo”) and an extension also includes a key “<foo>/”, the value associated with both of these (which must be a dictionary) are combined to form the combined specification of the core format and the extension. While it’s possible to define multiple extensions in the same file (as illustrated in Section 2.2.1 Schema-Id (or namespace)) normally, the specification associated with each schema-Id will be in a separate file as illustrated below:
File containing specification for core format:
{"fs": {
"core": <specification for core format>
}}
File containing specification for extension ex1:
{"fs": {
"ex1": <specification for extension ex1>
}}
File containing specification for extension ex2:
{"fs": {
"ex2": <specification for extension ex2>
}}
2.3. Specification of groups¶
2.3.1. Overall form¶
The specification of a group (i.e. value of a schema specification identifier that is followed by a slash) is a Python dictionary with the following form:
{
"description": "<description of group>",
"_description": "<description in case there is a dataset named 'description'>",
"_required": <required specification>,
"_exclude_in": <exclude_in specification>,
"_properties": <properties specification>",
"attributes": <attributes specification>,
"merge": <list of groups to merge>,
"merge+": <list of group (base class) to merge>,
"include": <dictionary of structures to include>,
"link": <link specification>,
"dataset_id[<qty-flag>]": { <dataset specification> },
"group_id/[<qty-flag>]": { <group specification> }
}
None of the key-value pairs are required. All but the last two are
described in the Section 2.3.2 Group specification keys below. The last two
(“dataset_id”, and “group_id/”) are used to specify a group or dataset
inside the group. The specification for these is the same as the
specification for top-level groups (described in this section) and for
top-level datasets (describe in :numref”:specification_of_datasets).
There can be any number of groups or datasets specified inside a group.
The optional <qty-flag>
after “dataset_id” and “group_id/” is the same
as the <quantity-flag>
described in Section 2.2.3 Schema specification.
2.3.2. Group specification keys¶
<IP_ADDRESS>. “description”¶
The value of the group specification “description” key is a string describing the group.
<IP_ADDRESS>. “_description”¶
The key “_description” (has an underscore in front) is used in place of “description” in case the key “description” is used to specify a dataset in the group named “description”. (In this case the value of the “description” key would be a JSON Object (Python dictionary) instead of a string.)
<IP_ADDRESS>. “_required”¶
The <required specification>
is a dictionary with each key an
identifier associated with some condition, and each value a list of
tuples. First element of each tuple is a string (called the “condition
string”) that contains a logical expression that has variables matching
members of the group. The condition string specifies which combinations
of group members are required. The second element of each tuple is an
error message that is displayed if the requirements of the condition
string are not met. An example required specification is shown below:
{ "start_time" :
["starting_time XOR timestamps",
"starting_time or timestamps must be present, but not both."],
"control":
["(control AND control_description) OR (NOT control AND NOT control_description)",
"If control or control_description are present, then both must be present.")]}
The logical expression can contain the following logical operators:
{"AND": 'and', 'XOR': '^', 'OR': 'or', 'NOT': 'not'}
either the upper-case strings (keys in the above JSON object) or the corresponding Python operator (values associated with the above keys) can be used.
<IP_ADDRESS>. “exclude_in”¶
The exclude_in specification is used to specify locations in the HDF5 file under which particular members of this group should not be present (or be optional). It has the form:
{ "/path1": ["id1", "id2", "id3", ...],
"/path2": [<ids for path2>], ... }
Each id is the identifier of a member group or dataset. The id in the list can be followed by characters ”!”, “^”, ”?” to respectively indicate that the id must not be present, should not be present or is optional under the specified path. If the last character is not “!”, “^” or “?” then “!” is assumed. An example is:
"_exclude\_in": {
"/stimulus/templates":
[ "starting_time!", "timestamps!", "num_samples?"] }
<IP_ADDRESS>. “_properties”¶
The “_properties” specification is optional. If present, the value must be a dictionary containing any combination of the keys: “abstract”, “closed” and “create”. The value of included key(s) must be type boolean (True or False). Key “abstract” has value True to indicate that this group is “abstract” (cannot be created directly, but instead must be subclassed via the “merge” directive). Key “closed” is True to indicate that additional members (groups and datasets beyond what are defined in the specification) are not allowed in this group. Key “create” is True to indicate that a write API should automatically create this group if the group is specified as being required and it is not created.
<IP_ADDRESS>. Group “attributes”¶
The value of the group specification “attributes” key is a Python dictionary of the following form:
{
"attr_name_1[<qty_flag>]": <specification for attr_name_1>,
"attr_name_2[<qty-flag>]": <specification for attr_name_2>,
... }
The keys are the attribute names, optionally followed by a <qty_flag>
.”
The <qty_flag>
(stands for ‘quantity flag’ is similar to that for
groups and data sets. It specifies if the attribute is required (“!”)–
the default, optional (“?”) or recommended (“^”). The value of each key
is the specification for that attribute. Each attribute specification
has the following form:
{
"data_type": <data_type>,
"dimensions": <dimensions list>,
"description": "<description of attribute>",
"value": <value to store>,
"const": <True or False>,
"autogen": <autogen specification>,
"references": <reference specification>,
"dim1": <dimension specification>,
"dim2": <dimension specification>
}
Only “data_type” is required. The value (<data_type>
) is a string
specifying the data_type of the attribute. Allowable values include:
"float" – indicates a floating point number
"int" – indicates an integer
"uint" – unsigned integer
"number" – indicates either a floating point or an integer
"text" – a text string
For “float”, “int” and “uint”, a default size (in bits) can be specified by appending the size to the type, e.g., “int32”. If “!” is appended to the default size, e.g. “float64!”, then the default size is also the required minimum size.
If the attribute stores an array, the <dimensions list>
specifies
the list of dimensions. The format for this is the same as the
<dimensions list>
for datasets which is described in Section
<IP_ADDRESS> Dataset dimensions. If no <dimension list>
is given, the
attribute stores a scalar value.
The description is a text string describing the attribute.
The “value” key denotes the value to store in the attribute. If a value is specified and “const”:True is specified, then the value is treated as a constant and cannot be changed by the API.
The autogen specification is described in Section 2.5 Autogen.
The references specification and the <dimension specification>
are the same as that used for datasets. They are respectively described
in Sections <IP_ADDRESS> “references” and 2.4.2 dimension specification.
<IP_ADDRESS>. “merge”¶
The merge specification is used to merge the specification of other groups into the current group. It consists of a Python list of the groups (identifiers described in Section 2.2.3 Schema specification) to merge. (Each element of the list must have a trailing slash since they all must be groups).
<IP_ADDRESS>. “merge+”¶
The merge+ specification (“+” character after the word “merge”) is used to merge the specification of a single group (or subclass of it) into the current group. The group merged is either the group given in the list, or a subclass of that group (where subclasses are defined as a group that merges the specified group). In the API call to make the group, a subclass is specified by appending a dash then the subclass name after the identifier used to make the group. For example, in the NWB format, if the group name is “corrected” and the base class (in the “merge+” specification) is “<image-series>”, then the call to create a subclass (such as “<TwoPhotonSeries>”) would be:
make_group("corrected-<TwoPhotonSeries>")
<IP_ADDRESS>. “include”¶
The include specification is used to include the specification of a
group or dataset inside the current group. The format is a Python
dictionary (also JSON object), in which each key is the key associated
with a group or dataset to include and the values are a dictionary used
to specify properties and values that are merged into the included structure
and also options for the include. The key that designate the group or
dataset to include may have a final character that specifies a quantity
(same as described in Section 2.2.3 Schema specification). Options for
the include are specified by key \_options
. Currently, there is only
one option: “subclasses” which has value True to indicate that “subclasses”
of the included group should also be included. Subclasses of a group are
groups that inherit from a base group using the “merge” directive
(described in the next section). Some examples of the include directive
are shown below:
# include with subclasses
"include": { "<TimeSeries>/*":{"\_options": {"subclasses": True}}}
# include without subclasses
"include": {"<TimeSeries>/*": {}}
<IP_ADDRESS>. “merge” vs. “include”¶
The merge operation implements a type of subclassing because properties of the merged in groups (the superclasses) are included, but overridden by properties in the group specifying the merge if there are conflicts. The include specification implements a type of reuse. The merge and include operations are illustrated by the following diagram:
| merge – (for subclassing) | include – for reuse |
|---|---|
“A/”: {
“x”: ...,
“y”: ...
}
“B/”: {
“merge”: [“A/”,],
“m”: ...,
“n”: ...,
}
Result:
“B/”: {
“x”: ...,
“y”: ...,
“m”: ...,
“n”: ...,
}
|
“A/”: {
“x”: ...,
“y”: ...
}
“B/”: {
“include”: {“A/”: {}},
“m”: ...,
“n”: ...,
}
Result:
“B/”: {
“m”: ...,
“n”: ...,
“A/”: {
“x”: ...,
“y”: ...
}
}
|
<IP_ADDRESS>. “link”¶
The link specification is used to indicate that the group must be HDF5 link to another group. (Hard or soft links can be used, but soft links are recommended). The link specification is a Python dictionary. It has the following form:
{
"target_type": "<target_type>",
"allow_subclasses": <True or False>,
}
<target_type>
specifies the key for a group in the top level structure
of a namespace. It is used to indicate that the link must be to an
instance of that structure. “allow_subclasses” is set to True to
indicate the link can be to subclasses of the target structure.
Subclasses are structures that include the target using a “merge”
specification. Neither of the keys are required. The default value for
“allow_subclasses” is False. If <target_type>
is not specified, then
the link can be to any group.
2.4. Specification of datasets¶
2.4.1. Overall form¶
The specification of a dataset (i.e. value associated with a schema specification key described in Section 2.2.3 Schema specification that does not have a trailing slash) is a Python dictionary with the following form:
{
"description": "<description>",
"data_type": <data_type>,
"dimensions": <dimensions list>, # required if dataset is not scalar
"attributes": <attributes specification>,
"references": "<reference target specification>",
"link": <link specification>,
"autogen": <autogen specification>,
"dim1": <dimension specification>,
"dim2": <dimension specification>,
...
}
Either the “data_type” or “link” property must be present. All others are optional. If the dataset is specified and is an array (not scalar) than the dimensions property is required. The autogen specification is described in Section 2.5 Autogen. Others are described below.
<IP_ADDRESS>. 4.2.1 dataset “description”¶
A string describing the dataset.
<IP_ADDRESS>. “data_type”¶
A string indicating the type of data stored. This is the same as the
<data_type
for group attributes, described in Section <IP_ADDRESS> Group “attributes”.
<IP_ADDRESS>. Dataset dimensions¶
If present, <dimension_list>
is either a list of named
dimensions, e.g.: [“dim1”, “dim2”, ...], or a list of lists of named
dimensions, e.g.: [[“dim1”], [“dim1”, “dim2”]]. The first form is
used if there is only one possibility for the number of dimensions. The
second form is used if there are multiple possible number of dimensions.
Each dimension name is a string (providing a dimension name). Dimensions
names are used both for specifying properties of dimensions (as described
in Section 2.4.2 dimension specification) and for specifying relationships
between datasets.
The special dimension name "*unlimited*"
is used to indicate that the
number of elements stored in this dimension can increase (by appending to
the dataset) after the dataset is created. Other dimensions are fixed in
size once the dataset is created.
<IP_ADDRESS>. Dataset “attributes”¶
Dataset attributes are specified in the same was as group attributes, described in Section <IP_ADDRESS> Group “attributes”.
<IP_ADDRESS>. “references”¶
The references property is used to indicate that the values stored in the dataset are referencing groups, datasets or parts of other datasets in the file. The value of the references property is a reference target specification. This has one of the following four forms:
- <path_to_dataset>.dimension
- <path_to_dataset>.dimension.component
- <path_to_group>/<variable_node_id>
- /
<path_to_dataset>
and <path_to_group>
are
respectively a path to a group or dataset in the file. The path can be
absolute (starting with “/”) or a relative (not starting with “/”). A
relative path references a node that is a child of the group containing
the references specification.
The first form (a) specifies a reference to a particular dimension of a dataset. In this case all values in the referencing dataset should be integers that are equal to one of the indices in the referenced dataset dimension. Zero-based indexing in used.
The second form (b) specifies a reference to a particular component of a structured dimension. Structured dimensions are described in the Section 2.4.2 dimension specification. In this case each value in the referencing dataset should be equal to a value in the referenced component of the referenced dataset and the values of the component in the referenced dataset should all be unique. This case corresponds to foreign key references in relational databases with the referenced component being a column in the referenced table satisfying a uniqueness constraint.
The third form (c) allows referencing variable-named groups or datasets. In this case all values of the referencing dataset should be names of groups or datasets that are created with the name specified in the call to the API. The value of the reference target specification should contain the name of the group or dataset in angle brackets (since the name is variable) and have a trailing slash if it is a group (since groups are designated by a slash after the name).
The forth form (d) is a single slash. This form is to indicate that the values in the referencing dataset must link to a group or dataset somewhere in the file, but there are no other constraints.
<IP_ADDRESS>. Dataset “link”¶
The link specification is used to indicate that the dataset must be implemented using a HDF5 link. Either hard or soft links can be used, but soft links are recommended because they indicate the source and target of the link). The link specification is a Python dictionary. It has the following form:
{
"target_type": "<target_type>"
}
<target_type>
specifies the identifier for a dataset in the top level
structure of a namespace. It is used to indicate that the link must be
to an instance of that structure. If “target_type” is not specified, then
the link can be to any dataset id.
2.4.2. dimension specification¶
Within a dataset specification, there are two types of dimension specifications. The first, described in Section <IP_ADDRESS> Dataset dimensions, provides a list of the names of all dimensions in the dataset. The second (described in this section) provides a way to describe the properties of each dimension. It is not necessary to include the specification for all dimensions. Only those dimensions that have structured components (which are described here) need to be specified. These dimension specifications have a key equal to the name of the dimension, and the value is the specification of the properties of the dimension. The following format is used:
{
"type": "structure",
"components": [
{ "alias": "var1",
"unit": "<unit>",
"references": "<reference target specification>"},
{ "alias": "var2", ... }, ... ]
}
The “type” specifies the type of dimension. Currently there is only one type implemented, named “structure”. Type “structure” allows storing different types of data into a single array similar to columns in a spreadsheet or fields in a relational data base table.
The different components are specified using a list of dictionaries, (or
a list of lists of dictionaries if there are more than one possible
structure; see below) with each dictionary specifying the properties
of the corresponding component. The “alias” specifies the component name that
can be referenced in a <reference target specification>
(reference type “b” in Section <IP_ADDRESS> “references”).
“unit” allows specifying the unit of measure for numeric values. “references” allows specifying that the values in the component reference another part of the file using any of the methods described in Section <IP_ADDRESS> “references”.
The list of components can be a list of lists, which allows specifying more than one possible structure for the dimension. An example in which this is useful is for representing a field of view, which could be 2-D (with components “width” and “height”) or 3-D (with components: “width”, “height” and “depth”). The same functionality might be achieved by defining two structured (“fov2d”, “fov3d”) and including both in the list of dimensions. In either case, determining which dimension (or list of dimension components) matches the dataset stored in a file requires matches the number of components in the structured dimension specification to the number of components in the data.
2.5. Autogen¶
2.5.1. Purpose and overall form¶
The autogen specification is used to specify that the attribute or dataset contents (values) can be derived from the contents of the HDF55 file and automatically filled in by the API. An API may use the autogen specification to automatically generate the values when creating a file, and to ensure that correct values are stored when validating a file. (In this section, the values specified by the autogen will be denoted by the phrase “value of the autogen” or “autogen contents.”) The autogen specification has the following form:
{
"type": <type of autogen>
"target": <path_to_target>,
"trim": <True or False; default False>
"allow_others": <True or False; default False>
"qty": <Either ‘!’ – exactly one, or “*” – zero or more; default “*”>
"tsig": <target_signature>
"include_empty": <True or False; default False>,
"sort": <True or False; default True>,
"format’: <link_path_format>
}
<Type of autogen>
is one of:
"links", "link_path", "names", "values", "length", "missing"
The <Type of autogen>
is the type of autogen. They are described in the
sections below. For all types, except “missing” key “target” is required.
All other keys are optional.
<path_to_target>
is a path of identifiers that specifies
one or more groups or datasets that are descendant of the group that most
directly contains the autogen specification. To specify multiple
members the target path would have one or more variable-named id’s
(enclosed in <>). In addition, the target “<*>” indicates
any group or dataset.
If “include_empty” is True, then if no values are found that would be used to fill the autogen, the value is set to an empty list. Otherwise, the container for the autogen values (attribute or dataset) is not created.
The “tsig” value (<target_signature>
) is used to specify properties that
must be satisfied for matching target(s). It is used to filter the nodes (groups
or datasets) found at the target path to only those for which the autogen
should apply. <target_signature>
has the following form:
{ "type": <"group" or "dataset">,
"attrs": { "key1": <value1>, "key2": <value2>, ... },
}
At least one of the keys (“type” or “attrs”) is required and both may be present. The value for “type” specifies the type of the target node (either “group” or “dataset”). If not included, both groups and datasets match. “attrs” specifies the attribute keys and values that are compared to those in the target to detect a match.
2.5.2. autogen type “links”¶
<type of autogen>
value “links” indicates that the value of the autogen
is a list of paths that link to the group or dataset specified by the <target_signature>
.
If “trim” is True then when the paths are stored, if they all share the same trailing
component (e.g. /foo/bar/baz
, and /x/y/baz
; both share final component “baz”),
then the common final component is trimmed from the paths before using them
to fill in the data. If “sort” is true, values must be sorted.
2.5.3. autogen type “link_path”¶
<type of autogen>
value “link_path” indicates that the value of the autogen is the
path of a link made from the referenced group or dataset. For example, if there is
a group “foo” which is links to group “bar”, and a dataset named “baz” at the same
level, defined by:
"baz": {"autogen": {"type": "link_path", "target": "foo"}}
Then the value of “baz” should be the path to “bar”.
The “format” option allows specifying a formatting string used for
“link_path”. It can include strings: “$s” to indicate the source of a
link and “$t” to indicate the target. If present, the format is used to
create the “link_path” entries. Default format is: “$t” (include just
the target path). Another common format is "'$s' is '$t'"
which will
generate strings like: '<source>' is '<target>'
The ‘qty’ for
“link_path” is currently not used. If “trim” is True both the “prefix”
and “suffix” of any matching paths are trimmed. The “prefix” is defined
as the path to the group that most directly contains the autogen
specification. The “suffix” is defined as any components of the matching path
which are to the right of the rightmost component associated with a
“variable named” node (that is, identifier enclosed in “<>”). If there
is no path component associated with a variable named node, the suffix
is not trimmed.
2.5.4. autogen type “names”¶
<type of autogen>
value “names” specifies that the value of the autogen
is an array contining the names of groups and/or datasets referenced by
the <target_signature>
. If “sort” is True, the values must be sorted.
2.5.5. autogen type “values”¶
<type of autogen>
set to “values” specifies that the the autogen contents
is an array listing all values stored in the target data set(s) as a set (no
duplicates). If “sort” is True, the array is sorted. The values in each target
data set must be an array of strings.
2.5.6. autogen type “length”¶
<type of autogen>
value “length” specifies that the value of the autogen is the
length of the target which must be a dataset storing a 1-D array.
2.5.7. autogen type “missing”¶
<type of autogen>
value “missing” specifies that autogen contents
is a sorted list of all members within the group which are specified as
being required or recommended, but are missing. There is no target
specified. If “allow_others” is True, then the list can also include
additional identifiers, as long as they are not present in the group,
whether or not they are defined in the specification as being required
or recommended. If present, such additional identifiers should be indicated
with a warning during validation.
2.6. Relationships¶
Relationships are specified in one of two ways:
- By sharing a common dimension identifier. Two arrays that are in the same group and which have a common dimension identifier are related to each other through the common dimension. Specifically, for a given index value “i” into the common dimension, the value in the two arrays at that index are related. For example, if arrays “data” and “timestamps” have a common dimension named “num_times”, then the values in these arrays that share the same index for “num_times” will be related.
- Through references specifications in dataset specifications that are described in Section <IP_ADDRESS> “references”.
2.7. Default custom location¶
An optional dataset named “__custom” (two leading underscores) is used as a flag in the format specification to indicate the location within which custom groups and custom datasets are created by default (that if, if the path is not specified in the API call).


First using Adobe Photoshop, and then uploading to the T-shirt design software (PDIP), I saved my files as a JPG. Then, I pressed and printed the front and back of this t-shirt.
I first found an image off of the Pexels image source. Folowing that I inserted this image onto corel draw, on a sheet which had the dimensions of an iPhone 6s phone case. Finally, using the Roland Versa Works software I manipulated what I made in CorelDraw to fit my phone case, and sent it to the UV printer. Here it is:
Step 1:After doing some extensive research, I found a stock image which I edited in corel draw and finally printed onto a 12 by 12 sheet of stock board using the UV Printer.
Step 2:I then used corel draw to design the puzzle pieces, which I then proceded to vector on the laser printer. In the end, my puzzle was a success!
Home Page


Installing Arduino IDE¶
Go to Arduino Download Site, choose Just Download (unless you want to donate).
Next install arduino IDE:
# considering you'd saved your .tar on Downloads:
~$ cd Downloads/
~/Downloads$ tar -xvJf arduino-1.6.13-linux64.tar.xz
~/Downloads$ cd arduino-1.6.13
~/Downloads/arduino-1.6.13$ ./install.sh
~/Downloads/arduino-1.6.13$ export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/lib/jni
~/Downloads/arduino-1.6.13$ sudo usermod -a -G tty $(whoami)
~/Downloads/arduino-1.6.13$ sudo usermod -a -G dialout $(whoami)
Once Ubuntu’s modemmanager
uses same port that Arduino Pro Micro, so it’s necessary to remove it from system:
~$ sudo apt purge modemmanager
Log off and log on again for the changes to take effect!
Now you have Arduino IDE on your pc, it can be accesed from unity menu by justing searching for Arduino.
Let’s install pro micro board on our arduino IDE
Firts you’ll need to point the Arduino IDE board manager to a custom URL. Open up Arduino, then go to the Preferences (File > Preferences). Then, towards the bottom of the window, paste this URL into the “Additional Board Manager URLs” text box:
https://raw.githubusercontent.com/sparkfun/Arduino_Boards/master/IDE_Board_Manager/package_sparkfun_index.json
Click OK. Then open the Board Manager by clicking Tools, then hovering over the Board selection tab and clicking Board Manager.
Search for ‘sparkfun’ in the Board Manager. You should see the SparkFun AVR Boards package appear. Click install, wait a few moments, and all the .brd files you’ll need should be installed, indicated by the blue ‘Installed’ that is printed next to the package.
You should now be able to upload code to a number of SparkFun Arduino-compatible products, including the Fio and the Pro Micro.


INSTRUCTIONS
Please enter your name, or your group's name at the top.
IMPORTANT
Please remember to click the Submit button once you have finished your cleanup.
ABOUT
The Coastal Watershed Council (CWC) is a 501(c)(3) nonprofit organization that was was formed in 1995 in response to the declining health of watersheds in the Monterey Bay region. Visit our website at
coastal-watershed.org/ 345 Lake Avenue, Suite F Santa Cruz, CA 95062<EMAIL_ADDRESS>Phone:<PHONE_NUMBER>Version 0.1


Montana
Cup
2004
Bike Race Series
Jerseys for the first place Cat. 1,2 Man
and Cat. 1,2,(3) Woman
Trophies for first place
finishers, all other
divisions"
Cash
or equivalent merchandise according to the following schedule:
$660 - Men 1,2 ($200/125/100/80/60/40/30/25)
$340 - Men 3 ($125/75/50/40/30/20)
$250 - Men 4,5 ($100/60/40/30/20)
$160 - Men Masters A ($60/40/30/20/10)
$105 - Men Masters B ($40/30/20/10/5)
$400 - Women 1,2,(3) ($150/100/75/50/25)
$190 - Women (3),4 ($75/50/30/20/15)
TBD - Juniors


Structure
APICollection
public struct APICollection
Order for defining routing.
It was defined as a specification when ordering routing from the presentation layer to the domain layer.
Note
If possible, I wanted to define this class as an abstract order that does not depend on the framework, but I gave up it because it was difficult in Vapor.
Initializers
init(method:paths:closure:middlewares:)
public init(method: HTTPMethodInDomain,
paths: [PathComponent],
closure: @escaping (Request) throws -> Future<Response>,
middlewares: [Middleware] = [])
Default initializer.
Parameters
| Name | Type | Description |
|---|---|---|
| method | HTTPMethodInDomain |
HTTPMethod to which API responds. |
| paths | [PathComponent] |
See |
| closure | @escaping (Request) throws -> Future<Response> |
API processing. |
| middlewares | [Middleware] |
Middleware that performs processing between Framework and Controller. |
Properties
middlewares
public let middlewares: [Middleware]
Middleware that performs processing between Framework and Controller.


Introduction
Universal Dependencies (UD) is a project that is developing cross-linguistically consistent treebank annotation for many languages, with the goal of facilitating multilingual parser development, cross-lingual learning, and parsing research from a language typology perspective. The annotation scheme is based on an evolution of (universal) Stanford dependencies (de Marneffe et al., 2006, 2008, 2014), Google universal part-of-speech tags (Petrov et al., 2012), and the Interset interlingua for morphosyntactic tagsets (Zeman, 2008). The general philosophy is to provide a universal inventory of categories and guidelines to facilitate consistent annotation of similar constructions across languages, while allowing language-specific extensions when necessary.

The secret to understanding the design and current success of UD is to realize that the design is a very subtle compromise between approximately 6 things:
- UD needs to be satisfactory on linguistic analysis grounds for individual languages.
- UD needs to be good for linguistic typology, i.e., providing a suitable basis for bringing out cross-linguistic parallelism across languages and language families.
- UD must be suitable for rapid, consistent annotation by a human annotator.
- UD must be easily comprehended and used by a non-linguist, whether a language learner or an engineer with prosaic needs for language processing. We refer to this as seeking a habitable design, and it leads us to favor traditional grammar notions and terminology.
- UD must be suitable for computer parsing with high accuracy.
- UD must support well downstream language understanding tasks (relation extraction, reading comprehension, machine translation, …).
It’s easy to come up with a proposal that improves UD on one of these dimensions. The interesting and difficult part is to improve UD while remaining sensitive to all these dimensions.
History
The Stanford dependencies were originally developed in 2005 as a backend to the Stanford parser to help in Recognizing Textual Entailment systems, then eventually emerged as the de facto standard for dependency analysis of English, and have since been adapted to a number of different languages (Chang et al., 2009, Bosco et al., 2013, Haverinen et al., 2013, Seraji et al., 2013, Tsarfaty, 2013, Lipenkova and Souček 2014). The Google universal tag set grew out of the cross-linguistic error analysis based on the CoNLL-X shared task data by McDonald and Nivre (2007), was initially used for unsupervised part-of-speech tagging by Das and Petrov (2011), and has since been adopted as a widely used standard for mapping diverse tagsets to a common standard. The Interset (Zeman, 2008) started as a tool for conversion between morphosyntactic tagsets of multiple languages. It dates back to 2006 when it was used in the first experiments with cross-lingual delexicalized parser adaptation (Zeman and Resnik, 2008). It was later employed as the morphological layer in HamleDT (Zeman et al., 2014) – a project that brings treebanks of many languages under a common annotation scheme.
The first attempt to combine Stanford dependencies and Google universal tags into a universal annotation scheme was the Universal Dependency Treebank (UDT) project (McDonald et al., 2013), which released treebanks for 6 languages in 2013 and 11 languages in 2014, and the first proposal for incorporating morphology was made by Tsarfaty (2013). The second version of HamleDT (Rosa et al., 2014) provided Stanford/Google annotation for 30 languages in 2014. This was followed by the development of universal Stanford dependencies (USD) (de Marneffe et al., 2014). The new Universal Dependencies is the result of merging all these initiatives into a single coherent framework, based on universal Stanford dependencies, an extended version of the Google universal tagset, a revised subset of the Interset feature inventory, and a revised version of the CoNLL-X format (called CoNLL-U).
The first version of the new guidelines, released in October 2014, introduced a somewhat extended universal part-of-speech tag set. This set makes some distinctions that were missing in the original proposal, but were perceived to be of importance by many, and clarifies the definition of categories. As a result of this work, universal POS categories have substantive definitions and are not necessarily just equivalence classes of categories in underlying language-particular treebanks. Hence, work to convert to UD POS tags often requires context-sensitive rules, or some hand correction. The UD morphological features aim to provide a stripped down basic set of features which are most crucial for analysis and are widespread across languages. The dependency representation of UD evolves out of Stanford Dependencies (SD), which itself follows ideas of grammatical relations-focused description that can be found in many linguistic frameworks. That is, it is centrally organized around notions of subject, object, clausal complement, noun determiner, noun modifier, etc. The goal of the new universal version was to add or refine relations to better accommodate the grammatical structures of typologically different languages and to clean up some of the quirkier and more English-specific features of the original version. Hence, the new taxonomy has less relations than the original SD.
Project organization
UD is an open collaboration with many project members. The administrative structure is kept at a minimum and currently consists of the following:
- The project is coordinated by Joakim Nivre (aka chief cat herder).
- Releases (including validation and documentation) are managed by Filip Ginter, Sampo Pyysalo and Dan Zeman.
- Universal guidelines are managed by a small group of core members, currently consisting of Marie de Marneffe, Filip Ginter, Yoav Goldberg, Jan Hajič, Chris Manning, Ryan McDonald, Lori Levin, Joakim Nivre, Slav Petrov, Sampo Pyysalo, Nathan Schneider, Sebastian Schuster, Natalia Silveira, Reut Tsarfaty, Fran Tyers, Amir Zeldes and Dan Zeman.
- Language-specific guidelines and treebanks are maintained by each specific language team.
- Issues are raised on GitHub and resolved through discussion and voting.
UD-related publications
2021
- Marie-Catherine de Marneffe, Christopher Manning, Joakim Nivre, Daniel Zeman (2021): Universal Dependencies. In: Computational Linguistics, ISSN 1530-9312, vol. 47, no. 2, pp. 255-308.
2020
-
Proceedings of the Fourth Workshop on Universal Dependencies, UDW 2020, COLING, on-line.
-
Joakim Nivre, Marie-Catherine de Marneffe, Filip Ginter, Jan Hajič, Christopher Manning, Sampo Pyysalo, Sebastian Schuster, Francis Tyers, Daniel Zeman. 2020. Universal Dependencies v2: An Evergrowing Multilingual Treebank Collection. In Proceedings of the 12th International Conference on Language Resources and Evaluation (LREC 2020), pp. 4034-4043, European Language Resources Association, Marseille, France, ISBN 979-10-95546-34-4.
-
Ika Alfina, Daniel Zeman, Arawinda Dinakaramani, Indra Budi, Heru Suhartanto (2020): Selecting the Universal Dependencies Morphological Features for Indonesian Dependency Treebank. In: Proceedings of the International Conference on Asian Language Processing (IALP 2020), pp. 104-109, Chinese and Oriental Languages Information Processing Society, Kuala Lumpur, Malaysia, ISBN 978-1-7281-7689-5.
-
Gosse Bouma, Djamé Seddah, Daniel Zeman (2020): Overview of the IWPT 2020 Shared Task on Parsing into Enhanced Universal Dependencies. In: Proceedings of the 16th International Conference on Parsing Technologies and the IWPT 2020 Shared Task on Parsing into Enhanced Universal Dependencies, pp. 151-161, Association for Computational Linguistics, Stroudsburg, PA, USA, ISBN 978-1-952148-11-8.
-
Ọlájídé Ishola, Daniel Zeman (2020): Yorùbá Dependency Treebank (YTB). In: Proceedings of the 12th International Conference on Language Resources and Evaluation (LREC 2020), pp. 5180-5188, European Language Resources Association, Marseille, France, ISBN 979-10-95546-34-4.
-
Atul Kumar Ojha, Daniel Zeman (2020): Universal Dependency Treebanks for Low-Resource Indian Languages: The Case of Bhojpuri. In: Proceedings of the LREC 2020 WILDRE5 – 5th Workshop on Indian Language Data: Resources and Evaluation, pp. 33-38, European Language Resources Association, Paris, France, ISBN 979-10-95546-67-2.
-
Marsida Toska, Joakim Nivre, Daniel Zeman (2020): Universal Dependencies for Albanian. In: Proceedings of the Fourth Workshop on Universal Dependencies (UDW 2020), pp. 178-188, Association for Computational Linguistics, Stroudsburg, PA, USA, ISBN 978-1-952148-48-4.
2019
-
Proceedings of the Third Workshop on Universal Dependencies, UDW 2019, SyntaxFest, Paris.
-
Kira Droganova, Daniel Zeman. 2019. Towards Deep Universal Dependencies. In Proceedings of the Fifth International Conference on Dependency Linguistics (Depling, Syntaxfest 2019), pp. 144-152.
-
Kim Gerdes, Bruno Guillaume, Sylvain Kahane, Guy Perrier. 2019. Improving Surface-syntactic Universal Dependencies (SUD): surface-syntactic functions and deep-syntactic features, Proceedings of the 17th international conference on Treebanks and Linguistic Theories (TLT), SyntaxFest, Paris.
-
Anssi Yli-Jyrä. 2019. Transition-Based Coding and Formal Language Theory for Ordered Digraphs, Proceedings of the 14th International Conference on Finite-State Methods and Natural Language Processing (FSMNLP, Dresden, Germany, 23–25 September 2019), pp. 118–131. SIGFSM, Association for Computational Linguistics.
-
Anssi Yli-Jyrä. 2019. How to embed noncrossing trees in Universal Dependencies treebanks in a low-complexity regular language. Journal of Language Modelling, 7(2):177-232.
2018
-
Proceedings of the Second Workshop on Universal Dependencies, UDW 2018, EMNLP, Brussels.
-
Puneet Dwivedi, Daniel Zeman. 2018. The Forest Lion and the Bull: Morphosyntactic Annotation of the Panchatantra. In: Computación y Sistemas, ISSN 1405-5546, vol. 22, no. 4, pp. 1377-1384.
-
N. Gruzitis, L. Pretkalnina, B. Saulite, L. Rituma, G. Nespore-Berzkalne, A. Znotins and P. Paikens. 2018. Creation of a Balanced State-of-the-Art Multilayer Corpus for NLU. In Proceedings of the 11th International Conference on Language Resources and Evaluation (LREC), pp. 4506-4513.
-
Sonja Marković, Daniel Zeman. 2018. Reflexives in Universal Dependencies. In Proceedings of the 17th International Workshop on Treebanks and Linguistic Theories (TLT 2018), pp. 131-146.
-
Agnieszka Patejuk and Adam Przepiórkowski. 2018. From Lexical Functional Grammar to Enhanced Universal Dependencies: Linguistically informed treebanks of Polish. Institute of Computer Science, Polish Academy of Sciences, Warsaw. (263 pages)
-
Lauma Pretkalniņa, Laura Rituma and Baiba Saulīte. 2018. Deriving Enhanced Universal Dependencies from a Hybrid Dependency-Constituency Treebank. In Text, Speech, and Dialogue, vol. 11107, pp. 95-105.
-
Adam Przepiórkowski and Agnieszka Patejuk. 2018. Arguments and adjuncts in Universal Dependencies. In Proceedings of the 27th International Conference on Computational Linguistics (COLING 2018), pages 3837–3852, Santa Fe, NM.
-
Sylvain Kahane, Marine Courtin, Kim Gerdes. 2018. Multi-word annotation in syntactic treebanks: Propositions for Universal Dependencies, Proceedings of the 16th international conference on Treebanks and Linguistic Theories (TLT), Prague.
-
Daniel Zeman. 2018. The World of Tokens, Tags and Trees. ISBN 978-80-88132-09-7.
-
Daniel Zeman, Jan Hajič, Martin Popel, Martin Potthast, Milan Straka, Filip Ginter, Joakim Nivre, Slav Petrov. 2018. CoNLL 2018 Shared Task: Multilingual Parsing from Raw Text to Universal Dependencies. In Proceedings of the CoNLL 2018 Shared Task: Multilingual Parsing from Raw Text to Universal Dependencies, pp. 1-21.
2017
-
Proceedings of the First Workshop on Universal Dependencies, UDW 2017, NoDaLiDa, Gothenburg.
-
Teresa Lynn, Jennifer Foster and Mark Dras. 2017. Morphological Features of the Irish Universal Dependency Treebank. In Proceedings of the 15th International Workshop on Treebanks and Linguistic Theories (TLT 2017), pp 111-122.
-
Joakim Nivre, Daniel Zeman, Filip Ginter, Francis Tyers. 2017. EACL tutorial on Universal Dependencies.
-
Tanja Samardžić, Mirjana Starović, Željko Agić, Nikola Ljubešić. 2017. Universal Dependencies for Serbian in Comparison with Croatian and Other Slavic Languages. In: Proceedings of BSNLP 2017, Valencia, Spain.
-
Dima Taji, Nizar Habash, Daniel Zeman. 2017. Universal Dependencies for Arabic. In Proceedings of the Third Arabic Natural Language Processing Workshop (WANLP), pp. 166-176.
-
Daniel Zeman. 2017. Core Arguments in Universal Dependencies. In Proceedings of the Fourth International Conference on Dependency Linguistics (Depling 2017).
-
Daniel Zeman. 2017. Slovak Dependency Treebank in Universal Dependencies. In Jazykovedný časopis / Journal of Linguistics, ISSN 0021-5597, vol. 68, no. 2, pp. 385-395.
-
Daniel Zeman, Martin Popel, Milan Straka, Jan Hajič, Joakim Nivre, Filip Ginter, Juhani Luotolahti, Sampo Pyysalo, Slav Petrov, Martin Potthast, Francis Tyers, Elena Badmaeva, Memduh Gökırmak, Anna Nedoluzhko, Silvie Cinková, Jan Hajič, jr., Jaroslava Hlaváčová, Václava Kettnerová, Zdeňka Urešová, Jenna Kanerva, Stina Ojala, Anna Missilä, Christopher Manning, Sebastian Schuster, Siva Reddy, Dima Taji, Nizar Habash, Herman Leung, Marie-Catherine de Marneffe, Manuela Sanguinetti, Maria Simi, Hiroshi Kanayama, Valeria de Paiva, Kira Droganova, Héctor Martínez Alonso, Çağrı Çöltekin, Umut Sulubacak, Hans Uszkoreit, Vivien Macketanz, Aljoscha Burchardt, Kim Harris, Katrin Marheinecke, Georg Rehm, Tolga Kayadelen, Mohammed Attia, Ali Elkahky, Zhuoran Yu, Emily Pitler, Saran Lertpradit, Michael Mandl, Jesse Kirchner, Hector Fernandez Alcalde, Jana Strnadová, Esha Banerjee, Ruli Manurung, Antonio Stella, Atsuko Shimada, Sookyoung Kwak, Gustavo Mendonça, Tatiana Lando, Rattima Nitisaroj, Josie Li. 2017. CoNLL 2017 Shared Task: Multilingual Parsing from Raw Text to Universal Dependencies. In Proceedings of the CoNLL 2017 Shared Task: Multilingual Parsing from Raw Text to Universal Dependencies, pp. 1-19.
-
Rademaker, Alexandre, Fabricio Chalub, Livy Real, Cláudia Freitas, Eckhard Bick, and Valeria de Paiva Universal Dependencies for Portuguese. 2017. “Universal Dependencies for Portuguese.” In Proceedings of the Fourth International Conference on Dependency Linguistics (Depling), 197–206. Pisa, Italy.
-
Anssi Yli-Jyrä. 2017. Bounded-Depth High-Coverage Search Space for Noncrossing Parses. In Proceedings of the 13th International Conference on Finite State Methods and Natural Language Processing (FSMNLP 2017, Umeå, Sweden, 4-6 September 2017), pp. 30-40. SIGFSM, Association for Computational Linguistics.
2016
-
Teresa Lynn and Jennifer Foster. 2016. Universal Dependencies for Irish. In Proceedings of the Second Celtic Language Technology Workshop (CLTW 2016), pp. 79-92.
-
Héctor Martínez Alonso, Daniel Zeman. 2016. Universal Dependencies for the AnCora treebanks. In Procesamiento del Lenguaje Natural, ISSN 1135-5948, 57, pp. 91-98.
-
Joakim Nivre, Marie-Catherine de Marneffe, Filip Ginter, Yoav Goldberg, Jan Hajič, Christopher D. Manning, Ryan McDonald, Slav Petrov, Sampo Pyysalo, Natalia Silveira, Reut Tsarfaty, Daniel Zeman. 2016. Universal Dependencies v1: A Multilingual Treebank Collection. In Proceedings of LREC.
-
Sebastian Schuster, Christopher D. Manning. 2016. Enhanced English Universal Dependencies: An Improved Representation for Natural Language Understanding Tasks. In Proceedings of LREC.
-
Mojgan Seraji, Filip Ginter, Joakim Nivre. 2016. Universal Dependencies for Persian. In Proceedings of LREC, pages 2361-2365.
-
Daniel Zeman. 2016. Universal Annotation of Slavic Verb Forms. In The Prague Bulletin of Mathematical Linguistics, ISSN 0032-6585, 105, pp. 143-193.
2015
-
Željko Agić, Nikola Ljubešić. 2015. Universal Dependencies for Croatian (that Work for Serbian, too), In: Proceedings of BSNLP 2015, Hissar, Bulgaria.
-
Kim Gerdes, Sylvain Kahane. 2015. Non-constituent coordination and other coordinative constructions as dependency graphs, Proceedings of the 3rd international conference on Dependency Linguistics (Depling), Uppsala.
-
Joakim Nivre. 2015. Towards a Universal Grammar for Natural Language Processing. Computational Linguistics and Intelligent Text Processing.
-
Petya Osenova and Kiril Simov. 2015. Universalizing BulTreeBank: a Linguistic Tale about Glocalization. In: Proceedings of BSNLP 2015, Hissar, Bulgaria, pp. 81–89.
-
Sampo Pyysalo, Jenna Kanerva, Anna Missilä, Veronika Laippala, and Filip Ginter. 2015. Universal Dependencies for Finnish. In Proceedings of Nodalida 2015.
-
Daniel Zeman. 2015. Slavic Languages in Universal Dependencies. In Slovko 2015: Natural Language Processing, Corpus Linguistics, E-learning. Bratislava, Slovakia. PDF
2014
-
Joakim Nivre. 2014. Universal Dependencies for Swedish. In SLTC 2014.
-
Rudolf Rosa, Jan Mašek, David Mareček, Martin Popel, Daniel Zeman, Zdeněk Žabokrtský. 2014. HamleDT 2.0: Thirty Dependency Treebanks Stanfordized. In Proceedings of LREC. (home page)
-
Daniel Zeman, Ondřej Dušek, David Mareček, Martin Popel, Loganathan Ramasamy, Jan Štěpánek, Zdeněk Žabokrtský, and Jan Hajič. 2014. HamleDT: Harmonized multi-language dependency treebank. In Language Resources and Evaluation, DOI 10.1007/s10579-014-9275-2. (Extended version of paper from LREC 2012.)
2013 and before
-
Cristina Bosco, Simonetta Montemagni, Maria Simi. 2013. Converting Italian treebanks: Towards an Italian Stanford dependency treebank, In 7th Linguistic Annotation Workshop and Interoperability with Discourse.
-
Pi-Chuan Chang, Huihsin Tseng, Dan Jurafsky, and Christopher D. Manning. 2009. Discriminative Reordering with Chinese Grammatical Relations Features. In Proceedings of the Third Workshop on Syntax and Structure in Statistical Translation.
-
Dipanjan Das, and Slav Petrov. 2011. Unsupervised part-of-speech tagging with bilingual graph-based projections In Proceedings of ACL.
-
Katri Haverinen, Jenna Nyblom, Timo Viljanen, Veronika Laippala, Samuel Kohonen, Anna Missilä, Stina Ojala, Tapio Salakoski, and Filip Ginter. 2013. Building the essential resources for Finnish: the Turku Dependency Treebank. Language Resources and Evaluation. Volume 48, Issue 3, pp 493-531.
-
Janna Lipenkova and Milan Souček. 2014. Converting Russian Dependency Treebank to Stanford Typed Dependencies Representation. In Proceedings of the 14th Conference of the European Chapter of the Association for Computational Linguistics, pp. 143-147.
-
Teresa Lynn, Jennifer Foster, Mark Dras and Lamia Tounsi. 2014. Cross-lingual Transfer Parsing for Low-Resourced Languages: An Irish Case Study In Proceedings of the First Celtic Language Technology Workshop (CLTW 2014)
-
Marie-Catherine de Marneffe, Miriam Connor, Natalia Silveira, Samuel R. Bowman, Timothy Dozat, and Christopher D. Manning. 2013. More constructions, more genres: extending Stanfod Dependencies. In Proceedings of the Second International Conference on Dependency Linguistics (DepLing 2013).
-
Marie-Catherine de Marneffe, Timothy Dozat, Natalia Silveira, Katri Haverinen, Filip Ginter, Joakim Nivre, and Christopher D. Manning. 2014. Universal Stanford Dependencies: A cross-linguistic typology. In Proceedings of LREC.
-
Marie-Catherine de Marneffe, Bill MacCartney, and Christopher D. Manning. 2006. Generating typed dependency parses from phrase structure parses. In Proceedings of LREC.
-
Marie-Catherine de Marneffe and Christopher D. Manning. 2008. The Stanford typed dependencies representation. In COLING Workshop on Cross-framework and Cross-domain Parser Evaluation.
-
Ryan McDonald, and Joakim Nivre. 2007. Characterizing the errors of data-driven dependency parsing models. In Proceedings of EMNLP-CoNLL.
-
Ryan McDonald, Joakim Nivre, Yvonne Quirmbach-Brundage, Yoav Goldberg, Dipanjan Das, Kuzman Ganchev, Keith Hall, Slav Petrov, Hao Zhang, Oscar Täckström, Claudia Bedini, Núria Bertomeu Castelló, and Jungmee Lee. 2013. Universal Dependency Annotation for Multilingual Parsing. In Proceedings of ACL. (home page)
-
Slav Petrov, Dipanjan Das, and Ryan McDonald. 2012. A universal part-of-speech tagset. In Proceedings of LREC. (home page)
-
Mojgan Seraji, Carina Jahani, Beáta Megyesi, and Joakim Nivre. 2013. A Persian treebank with Stanford typed dependencies. In Proceedings of LREC.
-
Pavel Straňák, Jan Štěpánek. 2010. Representing Layered and Structured Data in the CoNLL-ST Format. In Proceedings of ICGL 2010.
-
Reut Tsarfaty. 2013. A unified morpho-syntactic scheme of Stanford dependencies. In Proceedings of ACL.
-
Daniel Zeman. 2008. Reusable Tagset Conversion Using Tagset Drivers. In Proceedings of LREC. (home page)
-
Daniel Zeman, and Philip Resnik. 2008. Cross-Language Parser Adaptation between Related Languages. In Proceedings of IJCNLP 2008 Workshop on NLP for Less Privileged Languages


Resources used:
HTML, CSS JavaScript compiled with Babel, React, React DOM, Marked, Bootstrap and Font Awesome
Test Requirements(Select Markdown Previewer to test in test suite):
Technology Stack:
1. You can use any mix of HTML, JavaScript, CSS, Bootstrap, SASS, React, Redux, and jQuery to complete this project. You should use a frontend framework (like React for example) because this section is about learning frontend frameworks. Additional technologies not listed above are not recommended and using them is at your own risk. We are looking at supporting other frontend frameworks like Angular and Vue, but they are not currently supported. We will accept and try to fix all issue reports that use the suggested technology stack for this project. Happy coding!
Tests:
- I can see a textarea element with corresponding id="editor"
- I can see an element with corresponding id="preview"
- When I enter text into the #editor element, the #preview element is updated as I type to display the content of the textarea
- When I enter GitHub flavored markdown into the #editor element, the text is rendered as HTML in the #preview element as I type (Hint: You don't need to parse Markdown yourself - you can import the Marked library for this.
- When my markdown previewer first loads, the default text in the #editor field should contain valid markdown that represents at least one of each of the following elements: a header (H1 size), a sub header (H2 size), a link, inline code, a code block, a list item, a blockquote, an image, and bolded text
- When my markdown previewer first loads, the default markdown in the #editor field should be rendered as HTML in the #preview element
- OPTIONAL BONUS (you do not need to make this test pass): My markdown previewer interprets carriage returns and renders them as
(line break) elements (HINT: read the Marked.js docs for this one!).


TDI.Ajax Class
Basic Ajax functionality for the TDI library. Used to bind DOM events to desired HTML elements and send the TDI request when the events fire.
Requires TDI global object.
Item Index
Methods
Properties
Methods
_bindUI
()
private
Bind all the needed DOM events for Ajax enabled elements:
onclick
- ajax enabled links and submit buttonsonsubmit
- ajax enabled formsonchange
- ajax enabled form fieldsonunload
- window
_onBeforeFormSubmit
-
evt
The form onsubmit event handler. Used to trigger the preventable tdi:ajax:beforeFormSubmit
event.
Parameters:
-
evt
EventThe event object
_onBeforeLinkClick
-
evt
The link onclick event handler. Used to trigger the preventable tdi:ajax:beforeLinkClick
event.
Parameters:
-
evt
EventThe event object
_onFieldChange
-
evt
The field onchange event handler. If the field has the data-ajax-url
attribute
it is used as the trigger element. Otherwise, the fields form is considered to be the trigger
element.
Parameters:
-
evt
EventThe event object
_onFieldSubmit
-
evt
The field onkeydown event handler. If the field has the data-ajax-url
attribute,
a TDI ajax request is sent when Enter is pressed.
Parameters:
-
evt
EventThe event object
_onFormButtonActivate
-
evt
Saves the name
and value
of the submit button which the user used to
submit the form.
Parameters:
-
evt
EventThe event object
_onFormSubmit
-
evt
The form onsubmit event default method.
Parameters:
-
evt
EventThe event object
_onLinkClick
-
evt
The link onclick event handler.
Parameters:
-
evt
EventThe event object
_unbindUI
()
private
Unbind all previously attached DOM event handlers:
onclick
onsubmit
onchange
onunload
send
-
elm
-
callbacks
Universal method for sending a TDI.Ajax call. It is called internaly for all Ajax enabled
elements (like Links, Forms, Selects, Inputs). This method may be used in other scripts as TDI.Ajax.send( elm );
where the elm
parameter points to the element, which would trigger the Ajax call if it was Ajax enabled.
- There are some HTML attributes of the element, which are used to configure the call:
href
The target URL of the Ajax callaction
The same as hrefdata-ajax-url
The target URL of the Ajax call. Used if the Ajax URL should be different than the one defined by href or action attributes, or if the HTML element does not have URL attributes (select, input, ...)method
The HTTP method to be used for the Ajax request. Only for Form elements. Forms with <input type="file"> elements will have forced POST method!data-ajax-method
The HTTP method to be used for the Ajax request. The same as method but applicable for all elements. If used on Form element, it has precedence before method attribute (except Forms with file fields which have always POST method). Defaults to GET.data-related-element
A selector pointing to a related element. This element(s) gets notified when the Ajax call starts/ends.rel
(deprecated; use data-related-element instead) The same as data-related-elementdata-related-ancestor
A selector pointing to a related parent element. This element gets notified when the Ajax call starts/endsdata-confirm
A confirmation message. Use when the user should be able to stop the Ajax calldisabled
The Ajax call does not start if the element has the disabled atribute setclass="disabled"
The Ajax call does not start if the element has a disabled class name
Parameters:
-
elm
(String | JQuery | HTMLElement)The element which is used as a trigger for the Ajax call.
-
callbacks
ObjectAn optional set of callbacks:
beforeStart <Function>
If it returns false, the AJAX call and the defaultstart
callback will not be executed.start <Function>
beforeEnd <Function>
If it returns false, the defaultend
callback will not be executed.end <Function>
Returns:
xhr The jqXHR object or null if the iframe method was used to send a form
Properties
_delegateSelectors
Unknown
private
final
Selectors for ajax enabled elements:
a.tdi
form.tdi
form.tdi input[type=submit], form.tdi button
select.tdi, input[type=checkbox].tdi, input[type=radio].tdi
input[type=text].tdi
Events
tdi:ajax:beforeFormSubmit
Fires before the form is submited.
This event is preventable. Use preventDefault() to prevent the default action (_onFormSubmit
).
Event Payload:
-
evt
EventThe event object
-
data
ObjectThe event data:
form <jQuery>
The form object
tdi:ajax:beforeLinkClick
Fires before the link is clicked (before the link action is executed).
This event is preventable. Use preventDefault() to prevent the default action (_onLinkClick
).
Event Payload:
-
evt
EventThe event object
-
data
ObjectThe event data:
link <jQuery>
The link object


MEAN is a framework for an easy starting point with MongoDB, Node.js, Express, and AngularJS based applications. It is designed to give you a quick and organized way to start developing MEAN based web apps with useful modules like Mongoose and Passport pre-bundled and configured. We mainly try to take care of the connection points between existing popular frameworks and solve common integration problems.
If you're using ubuntu, this is the preferred repository to use...
$ curl -sL https://deb.nodesource.com/setup | sudo bash -
$ sudo apt-get update
$ sudo apt-get install nodejs
$ npm install -g gulp
// and bower
$ npm install -g bower
To start with MEAN install the mean-cli
package from NPM.
This will add the mean command which lets you interact (install, manage, update ...) your Mean based application.
$ npm install -g mean-cli
$ mean init <myApp>
$ cd <myApp> && npm install
Mean supports the gulp task runner for various services which are applied on the code. To start your application run -
$ gulp
Alternatively, when not using gulp
(and for production environments) you can run:
$ node server
Then, open a browser and go to:
http://localhost:3000
During installation depending on your os and prerequisite versions you may encounter some issues.
Most issues can be solved by one of the following tips, but if you are unable to find a solution feel free to contact us via the repository issue tracker or the links provided below.
Sometimes you may find there is a weird error during install like npm's Error: ENOENT. Usually updating those tools to the latest version solves the issue.
$ npm update -g npm
$ npm update -g grunt-cli
$ npm update -g bower
NPM and Bower has a caching system for holding packages that you already installed. We found that often cleaning the cache solves some troubles this system creates.
$ npm cache clean
$ bower cache clean
Some of Mean.io dependencies uses node-gyp with supported Python version 2.7.x. So if you see an error related to node-gyp rebuild follow next steps:
$ npm update -g
If you get this error when trying to mean init
:
Prerequisite not installed: git
And you definitely have Git for Windows installed, then it's not included in your path. Find the folder containing git.exe (likely C:\Program Files (x86)\Git\cmd
) and add it to your PATH.
MEAN is an acronym for Mongo, Express.js , Angular.js and Node.js
The MEAN CLI is a simple Command Line Interface for installing and managing MEAN applications. As a core module of the Mean.io project, it provides a number of useful tools to make interaction with your MEAN application easier, with features such as: scaffolding, module creation and admin, status checks, and user management.
$ mean
$ mean --help
$ mean help
mean help
can also be used in conjunction with any command to get more information about that particular functionality. For example, try mean help init
to see the options for init
$ mean help [command]
Information can be display for a specific customer via mean user email
. Email is required. User roles can be assigned or removed with the --addRole (or -a)
and --removeRole (or -r)
options, respectively.
For example, the admin role is required to edit tokens.
$ mean user <email>
$ mean user <email> --addRole <role>;
$ mean user <email> --removeRole <role>;
All of the remaining of the commands must be run from the root folder of your MEAN application.
Contributed MEAN packages can be installed or uninstalled via the CLI. Also, currently installed modules can be viewed with the list
command.
$ mean list
$ mean install <module>
$ mean uninstall <module>
Mean packages installed via the installer are found in /node_modules
To find new packages run the mean search command
$ mean search [packagename]
mean search
will return all of the available packages, mean search [packagename]
will filter the search results.
To create a new MEAN app, run mean init
. Name for the application is optional. If no name is provided, "mean" is used. The MEAN project will be cloned from GitHub into a directory of the application name.
$ mean init [name]
$ cd [name] && npm install
Note: git must be installed for this command to work properly.
Check the database connection for a particular environment (e.g. development (default), test, production) and make sure that the meanio command line version is up to date.
$ mean status
A simple shortcut to open the mean documentation in your default browser.
$ mean docs
Everything in mean.io is a package and when extending mean with custom functionality make sure you create your own package and do not alter the core packages.
The mean.io package system allows developers to create modular code that provides useful tools that other mean developers can use. The packages, when published, are plug-and-play and are used in a way very similar to traditional npm packages.
The mean.io package system integrates all the packages into the mean project as if the code was part of mean itself and provides the developers with all the necessary tools required to integrate their package into the host project.
There are two types of packages:
Custom Packages are generated by the mean scaffolder and contain most of your application logic. Custom packages are found in /packages/custom and can be published as a contrib package for use by other developers.
Contrib Packages are installed by the mean installer and are found at /packages/contrib. Contrib packages are "plug and play".
All Core
packages can be overridden by other packages allowing you to extend and adapt it to fit your specific needs. See Overriding views
for detailed examples.
The "system" package creates the basic pages as well as defines the layout of the site and integrates the menu into the page. The system package also allows us to define things such as rendering engines, static files and routing on the client and server side.
The "users" package creates the database model of the user, provides validation as well as various login and registration features.
The "access" package manages permissions and middleware. It controls the various authentication methods and is dependent on the users package
The "theme" package adds some basic CSS and other assets such as images and backgrounds
The "articles" package is typically used as an example starting point for managing content that might be used in a blog or cms. The full CRUD is implemented on the server and client.
The file structure is similar to that of the mean project itself
Fundamental
Files at the root
of the package
Server
Packages are registered in the app.js
Defines package name, version and mean=true
in the package.json
All of the Server side code resides in the /server
directory.
Server
--- config # Configuration files
--- controllers # Server side logic goes here
--- models # Database Schema Models
--- routes # Rest api endpoints for routing
--- views # Swig based html rendering
Client
All of the Client side code resides in the /public
directory.
public
--- assets # JavaScript/CSS/Images (not aggregated)
--- controllers # Angular controllers
--- config # Contains routing files
--- services # Angular services (also directive and filter folders)
--- views # Angular views
All JavaScript within public
is automatically aggregated with the exception of files in public/assets
, which can be manually added using the aggregateAsset()
function.
Files within the public
directory of the package can be accessed externally at /[package-name]/path-to-file-relative-to-public
. For example, to access the Tokens
Angular controller, tokens/controllers/tokens.js
.
In order for a Package to work it needs to be registered. By doing this you make the package system aware that you are ready and that other packages are able to depend on you. The packages are registered from within app.js
.
When registering you are required to declare all your dependencies in order for the package system to make them available to your package.
// Example of registering the MyPackage
MyPackage.register(function(app, auth, database) {
// ...
});
MEAN has 3 pre registered dependencies:
- app
Makes the express app available .
- auth
Includes some basic authentication functions
- database
Contains the Mongoose database connection
All dependencies specified must be registered in order to use them
An injection is the passing of a dependency (a service) to a dependent object (a client). The service is made part of the client's state. Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern. Wikipedia
Dependency injection allows you to declare what dependencies you require and rely on the package system to resolve all dependencies for you. Any package registered is automatically made available to anyone who would like to depend on them.
Looking again at the registration example we can see that MyPackage
depends on the Tokens
package and can make use of its full functionality, including overriding it.
// Example of registering the tokens package
MyPackage.register(function(app, auth, database, Tokens) {
// I can make use of the tokens within my module
MyPackage.someExampleFunction('some parameter');
// I can override functions
MyPackage.someExampleFunction = function(param) {
//my custom logic goes here
};
});
Packages when in code are used in a capitalized form
Every package registration automatically creates a corresponding angular module of the form mean.[package-name]
The package system injects this information into the mean init functions and allows developers to base their controllers, services, filters, directives etc on either an existing module or on their own one.
In addition you are able to declare which angular dependencies you want your angular module to use.
Below is an example of adding an angular dependency to our angular module.
// Example of adding an angular dependency of the ngDragDrop to the
MyPackage.angularDependencies(['ngDragDrop']);
See the assets section for an example how to add external libraries to the client such as the
gDragDrop
javascript library
All assets such as images, javascript libraries and CSS stylesheets should be within public/assets
of the package file structure.
Javascript and CSS from assets
can be aggregated to the global aggregation files. By default all javascript is automatically wrapped within an anonymous function unless given the option {global:true}
to not enclose the javascript within a contained scope
//Adding jquery to the mean project
MyPackage.aggregateAsset('js','jquery.min.js');
//Adding another library - global by default is false
MyPackage.aggregateAsset('js','jquery.min.js', {global:true});
//Adding some css to the mean project
MyPackage.aggregateAsset('css','default.css');
Javascript files outside of assets are automatically aggregated and injected into the mean project. As a result libraries that you do not want aggregated should be placed within
public/assets/js
The aggregation supports the ability to control the location of where to inject the aggregated code and if you add a weight and a group to your aggregateAsset method you can make sure it's included in the correct region.
MyPackage.aggregateAsset('js','first.js',{global:true, weight: -4, group: 'header'});
The line that gets loaded in your head.html calls the header group and injects the js you want to include first- in packages/system/server/views/includes/head.html
The settings object is a persistence object that is stored in the packages collection and allows for saving persistent information per package such as configuration options or admin settings for the package.
Receives two arguments the first being the settings object the second is a callback function
MyPackage.settings({'someSetting':'some value'}, function (err, settings) {
// You will receive the settings object on success
});
// Another save settings example this time with no callback
// This writes over the last settings.
MyPackage.settings({'anotherSettings':'some value'});
// Get settings. Retrieves latest saved settings
MyPackage.settings(function (err, settings) {
// You now have the settings object
});
Each time you save settings you overwrite your previous value. Settings are designed to be used to store basic configuration options and should not be used as a large data store
All routing to server side controllers is handled by express routes. The package system uses the typical express approach. The package system has a route function that passes along the package object to the main routing file typically server/routes/myPackage.js
By default the Package Object is passed to the routes along with the other arguments
MyPackage.routes(app, auth, database);
Example from the server/routes/myPackage.js
// The Package is past automatically as first parameter
module.exports = function(MyPackage, app, auth, database) {
// example route
app.get('/myPackage/example/anyone', function (req,res,next) {
res.send('Anyone can access this');
});
};
The angular routes are defined in public/routes/myPackage.js
. Just like the latest version of mean, the packages use the $stateProvider
$stateProvider
.state('myPackage example page', {
url: '/myPackage/example',
templateUrl: 'myPackage/views/index.html'
});
The angular views are publically accessible via templateUrl when prefixed with the package name
Packages are able to hook into an existing menu system and add links to various menus integrated within Mean.
Each link specifies its title
, template
, menu
and role
that is allowed to see the link. If the menu specified does not exist, a new menu will be created. The menu object is made accessible within the client by means of a menu angular service that queries the menu controller for information about links.
Below is an example how to add a link to the main menu from app.js
//We are adding a link to the main menu for all authenticated users
MyPackage.menus.add({
title: "myPackage example page",
link: "myPackage example page",
roles: ["authenticated"],
menu: "main"
});
You can look at the angular header controller in the mean project for more info. You can find it
public/system/controllers/header.js
and see how the menu service is implemented
The packages come built in with a rendering function allowing packages to render static html. The default templating engine is swig. The views are found in server/views
of the package and should end with the .html
suffix
Below is an example rendering some simple html
app.get('/myPackage/example/render', function (req,res,next) {
MyPackage.render('index', {packageName:'myPackage'}, function (err, html) {
//Rendering a view from the Package server/views
res.send(html);
});
});
One is able to override the default layout of the application through a custom package.
Below is an example overriding the default layout of system and instead using the layourts found locally within the package
MyPackage.register(function(system, app) {
app.set('views', __dirname + '/server/views');
// ...
Please note that the package must depend on
System
to ensure it is evaluated afterSystem
and can thus override the views folder
You may override public views used by certain core packages. To create a custom home page, you would create a custom package and modify the script in it's public folder like so:
angular.module('mean.mycustompackage', ['mean.system'])
.config(['$viewPathProvider', function($viewPathProvider) {
$viewPathProvider.override('system/views/index.html', 'mycustompackage/views/myhomepage.html');
}]);
This will render mycustompackage/views/myhomepage.html as the home page.
To create your own package and scaffold its initial code, run the following command:
$ mean package <packageName>
This will create a package under /packages/custom/pkgName
To delete your package, and remove its files:
$ mean uninstall myPackage
Where "myPackage" is the name of your package.
Once your package is in good shape and you want to share it with the world you can start the process of contributing it and submiting it so it can be included in the package repository. To contribute your package register to the network (see the section below) and run
bash
$ mean register # register to the mean network (see below)
$ cd <packages/custom/pkgName>
$ mean publish
Mean is a stand-alone instance that you can install locally or host on your server. We want to provide value to developers and are assembling a set of services which will be called the mean network. We're building all of this as we speak but we allready have some elements in place.
$ mean register
$ mean whoami
Coming soon!
All the configuration is specified in the config folder, through the env files, and is orchestrated through the meanio NPM module. Here you will need to specify your application name, database name, and hook up any social app keys if you want integration with Twitter, Facebook, GitHub, or Google.
There is a shared environment config: all
There are three environments provided by default: development, test, and production. Each of these environments has the following configuration options:
To run with a different environment, just specify NODE_ENV as you call grunt:
$ NODE_ENV=test grunt
If you are using node instead of grunt, it is very similar:
$ NODE_ENV=test node server
To simply run tests
$ npm test
NOTE: Running Node.js applications in the production environment enables caching, which is disabled by default in all other environments.
As from mean-0.4.4 control over the logging format has been delgated to the env configuration files.  MEAN uses git to download and update its own code. To handle its own operations, MEAN creates a remote called upstream
. This way you can use git as you would in any other project.
To update your MEAN app to the latest version of MEAN
$ git pull upstream master
$ npm install
To maintain your own public or private repository, add your repository as remote. See here for information on adding an existing project to GitHub.
$ git remote add origin <remote repository URL>
$ git push -u origin master
Since version 0.4.2 MEAN provides a command to easily upload your app to the mean cloud. To do so all you need to do is the following steps.
mean deploy
git push meanio master
mean user -a RoleName emailAddress --remote
mean logs -n 100
to get the last 100 lines...Before you start make sure you have the Heroku toolbelt installed and an accessible MongoDB instance - you can try MongoHQ which has an easy setup).
Add the db string to the production env in server/config/env/production.js.
$ git init
$ git add .
$ git commit -m "initial version"
$ heroku apps:create
$ heroku config:add NODE_ENV=production
$ heroku config:add BUILDPACK_URL=https://github.com/mbuchetics/heroku-buildpack-nodejs-grunt.git
$ git push heroku master
$ heroku config:set NODE_ENV=production
We believe that mean should be free and easy to integrate within your existing projects so we chose The MIT License


Anna Henson
Home
Tech
Core
About
Technical
Sprint 2 technical blog
Sprint 3 technical blog
Sprint 4 technical blog


"We should always have some aim in life which we must try to achieve while being of help to others."
―Sudha Murthy, Grandma's Bag of Stories
"I raise up my voice—not so I can shout, but so that those without a voice can be heard...we cannot succeed when half of us are held back."
―Malala Yousafzai
"There is no limit to what we, as women, can accomplish."
—Michelle Obama
"Men can do certain things well and women other things. Men and women are complementary to each other. One need not prove one’s strength."
―Michelle Obama
"Women are the real architects of society."
―Harriet Beecher Stowe
"Human rights are women's rights and women's rights are human rights, once and for all."
—Hillary Clinton
"We need to reshape our own perception of how we view ourselves. We have to step up as women and take the lead."
―Beyoncé
"A woman is the full circle. Within her is the power to create, nurture and transform."
―DIANE MARIECHILD


Combat Robotics is a sport that involves builders using all aspects of STEM to build robots that are capable of combat with one another. The goal is simple: in a match that lasts less than three minutes, disable your opponent through a knockout or by judge's decision. Robots can range from as light as 150 gram "fairyweights" to 340 pound "superheavyweights". I became interested after being introduced to the TV show "Battlebots" by my dad during my freshman year of high school.
An early driving test of Tombclone, without panelling or a blade. It's zippy!
Here's an example of a combat robot match from the TV show "BattleBots". Each of the two robots you see weigh 250 pounds.


Hello Code Club!
Introduction
Animation
Events
What have we learnt?
Microbit Links
Microbit 'Worst Snake ever'
Microbit 2 player 'Wargames.js'
Microbit simple tetris
HTML, CSS, JavaScript Links
Pixel Art
-


URL: {{post.identifier}}
Note that, these values are estimations. The actual rewards paid out after the post gets its payout may vary.