{% extends "example/base.html" %} {% load url from future %} {% block content %}
Token Trading!
{% if not error %} {% if not noparams %}This step of the OAuth2 authentication process is usually performed automatically by the consumer. For testing purposes, we simulate the POST request to the token endpoint provided by the Authorization Server with a form.
{% else %}You're not supposed to be here!
{% endif %} {% endif %} {% endblock %} {% block javascript %} {% endblock javascript %}


--- layout: post index: 6 tags: Grindlheim title: K'aros Roast House Pt. 2 excerpt: "Today's blog post completes our tour in and around the K'aros coffee roast house, the big theming experience along the footpath that surrounds Grindlheim. We also finally visit the observation deck including the coffee shop right next to the roast house." reddit: "https://www.reddit.com/r/PlanetCoaster/comments/dhquh0/part_2_of_the_karos_roast_house_tour_now_online/" shyguys-world: "https://www.shyguysworld.com/index.php/topic,21251.30.html#msg478671" number-of-images: 18 image-descriptions: - Today, we start with a view of the rear of the K'aros roast house, which I did not show in the last blog post. Here, we are still on the circular footpath that surrounds Grindlheim. - This is inside the roast house, when entering through the gate from the last picture. The opening on the right allows some immersive views down on Ri'kh and K'aros. - The roast house is powered by a waterwheel. These gears translate the movement from the wheel to the roast machines inside. - The second mid-course launch of K'aros catapults the riders through the basement of the roast house... - ...and right up to the highest peak of Grindlheim. The train rushing over this big waterfall and springkling its riders in the process is the most spectacular part of the ride. - This is also where the water for the waterwheel is taken from. - But the water needs to be redirected to the wheel with these wooden channels. - The people of Grindlheim seem to prefer complicated solutions and are known for their elaborate contraptions. - There's one more duct here and a little reservoir before the water flows down and powers the wheel. - This is the complete K'aros roast house as seen from above. - You may have seen the stairs on the left in the last post. They lead up to the observation deck and coffee shop. This is where we will go next. - A mountain massif surrounds the observation deck from one side. - The other side is open to allow spectatular views on the two coasters. This is the perfect place to have some fresh coffee, relax and fully take in the theme world and the power of K'aros rushing by. - As mentioned in previous posts, the first launch of K'aros is located directly underneath the observation deck. - If Planet Coaster had a first person virtual reality mode, this would be the place to go! - K'aros comes very close to the railing of the observation deck as it rushes by. - You can also see the track of Ri'kh flowing through the depths of Grindlheim down below. - Thank you for joining me on this update. Let's finish with a another overview of the K'aros roast house. Please join me again next time and keep an eye out for exclusive Grindlheim content on the Planet Coaster Subreddit! ---
Last time I showed you the first section of the circular footpath surrounding Grindlheim and we also visited the K'aros coffee roast house this path leads right through. In today's blog post we continue the tour in and around the roast house and we also visit the observation deck right next to it.
We start with some pictures of the rear of the building which I did not show last time. We also have a closer look at the big waterfall that K'aros rushes over directly after the second launch when the train reaches its maximum speed. This is also the place where the water for the waterweel that powers the roast house is taken from. The water is then guided to the wheel with elaborate wooden channels stretching over and around the roast house. Check out this little video to see the big waterfall and K'aros in action.
Until its completion the roast house was the most complicated building I had created in Planet Coaster. This is due to the multiple crossings of paths and coasters on different levels. This house is not just an outer shell, every place that visitors can see is themed to the same level of detail. No compromises made, no flickering textures, no objects sticking out of walls! This was all topped when I started on the Ri'kh queue building which is still not finished and much more complex. But that's a story for a future blog post.
Now, please check out the gallery below and finish the tour through the K'aros roast house.


Through Identity Brokering it's easy to allow users to authenticate to Keycloak using external Identity Providers or Social Networks.
We have built-in support for OpenID Connect and SAML 2.0 as well as a number of social networks such as Google, GitHub, Facebook and Twitter.
To get started select a provider from the dropdown below:


Are you ready for the best cookie of your life? 🍪
9 out of 10 families agree, salmon cookies are life-affirming.
Who are you to deny your loved ones?  Buy some cookies!
Our cookies are made with love, care, and fresh salmon hair.
Or perhaps you're too cool for a school (of fish)
Then you should snag a shirt! We have multiple prints available.


---
layout: default
title: Subscribe
permalink: /subscribe/
---
subscribe
Benifits
- Every time you post an emote in the chat, it will show up on my stream!
- Support me immensely so i can keep streaming!
- Snapchat, Kik, Whats App, Steam add, Discord role
- Paws + Multiplier
- SignPics
- Sub days
- My Love
- Giveaways
- Mod after 6 months
- Movie nights at least twice a week
- Steam add
- Custom Audio Command
- Custom Join Message
- Customm Command
- Drawing! Ask for anything drawn and edited digitally!
subscriber benefits
- undying love & appreciation
4.99 a month
subscribe
7034
28895
1


Hi, I'm Ahmed Shaaban Abou Elmagd! I'm a Front-end Developer who loves coding.
For more informations about me you can find my full CV Here.
If you'd like to follow me on Twitter, thats my username @ahmedshaaban00.


– Metadata Editor and Repository for MEI Data
Introduction to the MerMEId demo server
MerMEId is a system for the editing, handling, and (pre-)viewing of music metadata, based on the the MEI (Music Encoding Initiative) XML schema.
MerMEId is developed at the Danish Centre for Music Editing (DCM) both for the production of thematic catalogues of works and for organizing source- and work-related information during the preparation of scholarly editions of music. More information available at GitHub.
Try it!
The demo installation has been tested with a number of browsers on various operating systems, but browser compatibility is mainly dependent on the third-party software used (see the installation guide at GitHub for details). We recommend using Firefox or Google Chrome for best performance.
In order to use the editor you will need a user ID and password. For the demo installation they are honoured and guest, respectively. Welcome :-)
To get started, you may want to have a look at the manual (opens in a new window or tab) which also includes a list of frequently asked questions.
What you can do with the demo
You can create new files and change everything you like in the existing ones. Do not save anything indispensable, or even expect that a document created one day will survive the night. The system is restored daily. However, you can download your work to your own file system by right-clicking the XML code view icon and selecting "Save as...".
The demo includes a number of sample files illustrating various aspects of working with music metadata.
Setting up your own MerMEId server
MerMEId is open-source software released under the Apache License version 2.0. The software is available for download at https://github.com/Det-Kongelige-Bibliotek/MerMEId
For technical information please read the installation manuals (for Docker and non-Docker installations, respectively) at GitHub.
This version of MerMEId uses the MEI 4.0.0 XML schema. The schema is available at www.music-encoding.org/schema/.


--- layout: archive title: Zulip Chat Archive permalink: /stream/224796-Geographic-locality/topic/Paris.20area.2C.20France.html ---
I'm in Orsay, Paris area, France.
I'm also there, we should be able to meet after the lock-down!
(Samuel is working in my math department).
{% endraw %}Last updated: Apr 24 2020 at 19:02 UTC


Note: It's fixed now. The project itself is still pretty cool
I recently managed to sync my Facebook events to my Google Calendar (and thusly to my Android phone). At first the task seemed simple, because Facebook offers you a link to export your events in iCal format, but once imported to Google Calendar all you can see from the events is a "busy/free" block, like this
Of course it won't do at all, as you want to be able to see all of the
event details!
After some fiddling (with Fiddler) I saw that
the iCal events had a field called CLASS
, which was set to PRIVATE
on all of my Facebook events.
Facebook is probably using that field to signify which events are public and which are invite-only, like mine where.
Google Calendar must be interpreting the private
as an event which is
sensitive and cannot be fully shown - only the "busy/free" field.
I didn't have the intention to find which one is using this field
"correctly", but something had to be done. After editing the iCal with
notepad and modifying this field to PUBLIC
, the events showed up fine,
So I knew what I had to do.
I created another Yii application called
"eventFix" that helps users
feed their Facebook events url and get a proxy url - one that goes
through my application which replaces all instances of CLASS:PRIVATE
to CLASS:PUBLIC
. I'm using it already!
If you're worried about me sniffing your precious events, I can probably tell you that I don't really care / have the db space for that. But if you're uncomfortable using this applications for that reason, don't.
I'm sure other people have encountered the same problem and came up with their own solutions, and I'm sure some of those are better than mine. I don't care, I did it for the practice.
Have fun syncing!


IIT (ISM) campus is located in the City of Dhanbad, Jharkhand.The city is very well connected through Railways and Surface transport to various part of the country.
Dhanbad Junction station code DHN, is headquarters of the Dhanbad Rail Division of the East Central Railway zone. It is the largest railway station in Jharkhand, handling over 100 trains and 100,000+ passengers everyday. As one of the largest and busiest railway junctions, it has direct trains from all the major cities of the country.
Though the city of Dhanbad does not have any airport, it is extremely well connected to the cities of Kolkata, Ranchi which have functional International and Domestic Airports for flights to all corners of the country on a daily basis.
Kolkata: 270 Km from Dhanbad. Ranchi: 146 Km from Dhanbad.
AC accommodation is provided inside the campus (Executive Development Center/Senior Academic Hostel) on twin sharing basis(If Available). Other Hotels near to ISM where Accommodation is available are given below:
The hotel is approximately 4KM from railway station. The distance between hotel and our Institute is around 7KM.
The hotel is approximately 5KM from railway station. The distance between hotel and our Institute is around 8KM.
The hotel is approximately 5KM from railway station. The distance between hotel and our Institute is around 5KM
The hotel is approximately .5KM from railway station. The distance between hotel and our Institute is around 3KM.
The recruitment process is carried out in Executive Development Center which is located opposite to the Senior Academic Hostel. It is about 200m from the main gate.


Clicking on Add to Slack means, you are agreeing to the Natural Speech & Intent Processing Bot
Terms of Service &
Privacy Policy.
Your privacy is very important to us. Accordingly, we have developed this Policy in order for you to understand how we collect, use, communicate and disclose and make use of personal information. The following outlines our
- The application uses internet connection to show results.
- This application won't collect any personal information.
-
We will make readily available to customers information about our policies and practices relating to the management of personal information.
-
If the app is deleted, all the information is deleted automatically.
We will make readily available to customer’s information about our policies and practices relating to the management of personal information.
Contact Us:
If you have questions about this Privacy Policy, please contact us


PG_BACKEND_PID
Returns the process ID (PID) of the server process handling the current session.
Note
The PID is not globally unique. It can be reused over time.
Syntax
pg_backend_pid()
Return Type
Returns an integer.
Example
You can correlate PG_BACKEND_PID() with log tables to retrieve information for the current session. For example, the following query returns the query ID and a portion of the query text for queries executed in the current session.
select query, substring(text,1,40) from stl_querytext where pid = PG_BACKEND_PID() order by query desc; query | substring -------+------------------------------------------ 14831 | select query, substring(text,1,40) from 14827 | select query, substring(path,0,80) as pa 14826 | copy category from 's3://dw-tickit/manif 14825 | Count rows in target table 14824 | unload ('select * from category') to 's3 (5 rows)
You can correlate PG_BACKEND_PID() with the pid column in the following log tables (exceptions are noted in parentheses):
-
STL_SESSIONS (process)
-
STV_LOCKS (lock_owner_pid)
-
STV_RECENTS (process_id)


Toyota corolla xle 2020 3D tour
We're loading assets...
We're loading assets...
Lorem ipsum is placeholder text commonly used in the graphic, print, and publishing industries for previewing layouts and visual mockups.
Lorem ipsum is placeholder text commonly used in the graphic, print, and publishing industries for previewing layouts and visual mockups.


The homepage for my GitHub Pages content
Daniel Roelfs
Oslo Housing
Scripts to analyse and visualise the Oslo housing market
Slides
Repository to store slides from talks, tutorials, and presentations
CV
Repo to host my online cv created with RMarkdown


This is a demo for the the feedWebGL javascript library.
The canvas on the left displays the raw WebGL output from the transform/feedback program. The demo uses cutting edge WebGL features and does not work on all browser configurations. The canvas on the right displays the data after it has been captured and fed into a Three.js scene.
Please mousedown and drag on the right to rotate the three.js scene. Adjust the slider below to change the expression level contour.


?0
1
2
3
4
5
6
7
8
9
10
The
New
York
Ácm
_____copyright
reserved
botanical
Garden
ExmrIdmI
hr
NCRTH
AKEStCAN
FLORA
Cubtiss,
West
Indian
Plants,
No.
$>'$-
I
y
A.
H.
Curtiss.
"
~
2-
/fov
NO.
l~
CN
-
QjlOu.^
UjJL
.
DET.
BY
MILDRED
E.
MATHIAS
01501109
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


galactic-age-calculator
Enter your Earth birth date below
(Earth) Birth day:
(Earth) Birth month:
(Earth) Birth year:
Are you a healthy person?
Average
Yes
No
Celestial body:
--Select Option--
Sun
Mercury
Venus
Earth
Mars
Jupiter
Saturn
Uranus
Neptune
Pluto
Submit


Glossary of Puppet Vocabulary
An accurate, shared vocabulary goes a long way to ensure the success of a project. To that end, this glossary defines the most common terms Puppet users rely on.
attribute
Attributes are used to specify the state desired for a given configuration resource. Each resource type has a slightly different set of possible attributes, and each attribute has its own set of possible values. For example, a package resource (like vim
) would have an ensure
attribute, whose value could be present
, latest
, absent
, or a version number:
package {'vim':
ensure => present,
provider => apt,
}
The value of an attribute is specified with the =>
operator; attribute/value pairs are separated by commas.
agent
(or agent node)
Puppet is usually deployed in a simple client-server arrangement, and the Puppet client daemon is known as the “agent.” By association, a computer running puppet agent is usually referred to as an “agent node” (or simply “agent,” or simply “node”).
Puppet agent regularly pulls configuration catalogs from a puppet master server and applies them to the local system.
catalog
A catalog is a compilation of all the resources that will be applied to a given system and the relationships between those resources.
Catalogs are compiled from manifests by a puppet master server and served to agent nodes. Unlike the manifests they were compiled from, they don’t contain any conditional logic or functions. They are unambiguous, are only relevant to one specific node, and are machine-generated rather than written by hand.
class
A collection of related resources, which, once defined, can be declared as a single unit. For example, a class could contain all of the elements (files, settings, modules, scripts, etc) needed to configure Apache on a host. Classes can also declare other classes.
Classes are singletons, and can only be applied once in a given configuration, although the include
keyword allows you to declare a class multiple times while still only evaluating it once.
Note: Being singletons, Puppet classes are not analogous to classes in object-oriented programming languages. OO classes are like templates that can be instantiated multiple times; Puppet’s equivalent to this concept is defined types.
classify
(or node classification)
To assign classes to a node, as well as provide any data the classes require. Writing a class makes a set of configurations available; classifying a node determines what its actual configuration will be.
Nodes can be classified with node definitions in the site manifest, with an ENC, or with both.
declare
To direct Puppet to include a given class or resource in a given configuration. To declare resources, use the lowercase file {'/tmp/bar':}
syntax. To declare classes, use the include
keyword or the class {'foo':}
syntax. (Note that Puppet will automatically declare any classes it receives from an external node classifier.)
You can configure a resource or class when you declare it by including attribute/value pairs.
Contrast with “define.”
define
To specify the contents and behavior of a class or a defined resource type. Defining a class or type doesn’t automatically include it in a configuration; it simply makes it available to be declared.
define (noun)
(or definition)
An older term for a defined resource type.
define (keyword)
The language keyword used to create a defined type.
defined resource type
(or defined type)
See “type (defined).”
ENC
environment
An arbitrary segment of your Puppet site, which can be served a different set of modules. For example, environments can be used to set up scratch nodes for testing before roll-out, or to divide a site by types of hardware.
expression
The Puppet language supports several types of expressions for comparison and evaluation purposes. Amongst others, Puppet supports boolean expressions, comparision expressions, and arithmetic expressions. See the Expressions page in the latest Puppet language reference for more information.
external node classifier
(or ENC)
An executable script, which, when called by the puppet master, returns information about which classes to apply to a node.
ENCs provide an alternate method to using the main site manifest (site.pp
) to classify nodes. An ENC can be written in any language, and can use information from any pre-existing data source (such as an LDAP db) when classifying nodes.
An ENC is called with the name of the node to be classified as an argument, and should return a YAML document describing the node. See External Nodes for more information.
fact
A piece of information about a node, such as its operating system, hostname, or IP address.
Facts are read from the system by Facter, and are made available to Puppet as global variables.
Facter can also be extended with custom facts, which can expose site-specific details of your systems to your Puppet manifests. See Custom Facts for more details.
Facter
Facter is Puppet’s system inventory tool. Facter reads facts about a node (such as its hostname, IP address, operating system, etc.) and makes them available to Puppet.
Facter includes a large number of built-in facts; you can view their names and values for the local system by running facter
at the command line.
In agent/master Puppet arrangements, agent nodes send their facts to the master.
filebucket
A repository in which Puppet stores file backups when it has to replace files. A filebucket can be either local (and owned by the node being mangaed) or site-global (and owned by the puppet master). Typically, a single filebucket is defined for a whole network and is used as the default backup location.
See type: filebucket for more information.
function
A statement in a manifest which returns a value or makes a change to the catalog.
Since they run during compilation, functions happen on the puppet master in an agent/master arrangement. The only agent-specific information they have access to are the facts the agent submitted.
Common functions include template
, notice
, and include
. You can choose from the list of built-in functions, use functions from public modules (like puppetlabs-stdlib), or write our own custom functions (see the Writing Your Own Functions page).
global scope
See scope.
host
Any computer (physical or virtual) attached to a network.
In the Puppet docs, this usually means an instance of an operating system with the Puppet agent installed. See also “Agent Node”.
host (resource type)
An entry in a system’s hosts
file, used for name resolution. See type: host for more information.
idempotent
Able to be applied multiple times with the same outcome. Puppet resources are idempotent, since they describe a desired final state rather than a series of steps to follow.
(The only major exception is the exec
type; exec resources must still be idempotent, but it’s up to the user to design each exec resource correctly.)
inheritance (class)
A Puppet class can be derived from one other class with the inherits
keyword. The derived class will declare all of the same resources, but can override some of their attributes and add new resources.
Note: Most users should avoid inheritance most of the time. Unlike object-oriented programming languages, inheritance isn’t terribly important in Puppet; it is only useful for overriding attributes, which can be done equally well by using a single class with a few parameters.
inheritance (node)
Node statements can be derived from other node statements with the inherits
keyword. This works identically to the way class inheritance works.
Note: Node inheritance should almost always be avoided. Many new users attempt to use node inheritance to look up variables that have a common default value and a rare specific value on certain nodes; it is not suited to this task, and often yields the opposite of the expected result. If you have a lot of conditional per-node data, we recommend using the Heira tool or assigning variables with an ENC instead.
master
In a standard Puppet client-server deployment, the server is known as the master. The puppet master serves configuration catalogs on demand to the puppet agent service that runs on the clients.
The puppet master uses an HTTP server to provide catalogs. It can run as a standalone daemon process with a built-in web server, or it can be managed by a production-grade web server that supports the rack API. The built-in web server is meant for testing, and is not suitable for use with more than ten nodes.
manifest
A file containing code written in the Puppet language, and named with the .pp
file extension. The Puppet code in a manifest can:
- Declare resources and classes
- Set variables
- Evaluate functions
- Define classes, defined types, and nodes
Most manifests are contained in modules. Every manifest in a module should define a single class or defined type.
The puppet master service reads a single “site manifest,” usually located at /etc/puppet/manifests/site.pp
. This manifest usually defines nodes, so that each managed agent node will receive a unique catalog.
metaparameter
A resource attribute that can be specified for any type of resource. Metaparameters are part of Puppet’s framework rather than part of a specific type, and usually affect the way resources relate to each other. For a list of metaparameters and their usage, see the Metaparameter Reference.
module
A collection of classes, resource types, files, and templates, organized around a particular purpose. For example, a module could be used to completely configure an Apache instance or to set-up a Rails application. There are many pre-built modules available for download in the Puppet Forge. For more information see:
namevar
(or name)
The attribute that represents a resource’s unique identity on the target system. For example: two different files cannot have the same path
, and two different services cannot have the same name
.
Every resource type has a designated namevar; usually it is simply name
, but some types, like file
or exec
, have their own (e.g. path
and command
). If the namevar is something other than name
, it will be called out in the type reference.
If you do not specify a value for a resource’s namevar when you declare it, it will default to that resource’s title.
node (definition)
(or node statement)
A collection of classes, resources, and variables in a manifest, which will only be applied to a certain agent node. Node definitions begin with the node
keyword, and can match a node by full name or by regular expression.
When a managed node retrieves or compiles its catalog, it will receive the contents of a single matching node statement, as well as any classes or resources declared outside any node statement. The classes in every other node statement will be hidden from that node.
See node definitions in the latest Puppet language reference for more details.
node scope
The local variable scope created by a node definition. Variables declared in this scope will override top-scope variables. (Note that ENCs assign variables at top scope, and do not introduce node scopes.)
noop
Noop mode (short for “No Operations” mode) lets you simulate your configuration without making any actual changes. Basically, noop allows you to do a dry run with all logging working normally, but with no effect on any hosts. To run in noop mode, execute puppet agent
or puppet apply
with the --noop
option.
notify
A notification relationship, set with the notify
metaparameter or the wavy chaining arrow. (~>
) See “Relationships and Ordering” in the Puppet language reference for more details.
notification
A type of relationship that both declares an order for resources and causes refresh events to be sent. See “Relationships and Ordering” in the Puppet language reference for more details.
ordering
Which resources should be managed before which others.
By default, the order of a manifest is not the order in which resources are managed. You must declare a relationship if a resource depends on other resources. See “Relationships and Ordering” in the Puppet language reference for more details.
parameter
Generally speaking, a parameter is a chunk of information that a class or resource can accept. See also:
- parameter (custom type and provider development)
- parameter (defined types and parameterized classes)
- parameter (external nodes)
parameter (custom type and provider development)
A value which does not call a method on a provider. Eventually expressed as an attribute in instances of this resource type. See Custom Types.
parameter (defined types and parameterized classes)
A variable in the definition of a class or defined type, whose value is set by a resource attribute when an instance of that type (or class) is declared.
define my_new_type ($my_parameter) {
file {"$title":
ensure => file,
content => $my_parameter,
}
}
my_new_type {'/tmp/test_file':
my_parameter => "This text will become the content of the file.",
}
The parameters you use when defining a type (or class) become the attributes available when the type (or class) is declared.
parameter (external nodes)
A top-scope variable set by an external node classifier. Although these are called “parameters,” they are just normal variables; the name refers to the fact that they are usually used to configure the behavior of classes.
pattern
A colloquial term, describing a collection of related manifests meant to solve an issue or manage a particular configuration item. (For example, an Apache pattern.) See also module.
plusignment operator
The +>
operator, which allows you to add values to resource attributes using the (‘plusignment’) syntax. Useful when you want to override resource attributes without having to respecify already declared values.
property (custom type and provider development)
A value that corresponds to an observable piece of state on the target system. When retrieving the state of a resource, a property will call the specified method on the provider, which will read the state from the system. If the current state does not match the specified state, the provider will change it.
Properties appear as attributes when declaring instances of this resource type. See Custom Types.
provider
Providers implement resource types on a specific type of system, using the system’s own tools. The division between types and providers allows a single resource type (like package
) to manage packages on many different systems (using, for example, yum
on Red Hat systems, dpkg
and apt
on Debian-based systems, and ports
on BSD systems).
Typically, providers are simple Ruby wrappers around shell commands, so they are usually short and easy to create.
plugin
A custom type, function, or fact that extends Puppet’s capabilities and is distributed via a module. See Plugins in Modules for more details.
realize
To specify that a virtual resource should actually be applied to the current system. Once a virtual resource has been declared, there are two methods for realizing it:
- Use the “spaceship” syntax
<||>
- Use the
realize
function
A virtually declared resource will be present in the catalog, but will not be applied to a system until it is realized. See Virtual Resources for more details.
refresh
A resource gets refreshed when a resource it subscribes to (or which notifies it) is changed.
Different resource types do different things when they get refreshed. (Services restart; mount points unmount and remount; execs usually do nothing, but will fire if the refreshonly
attribute is set.)
relationship
A rule stating that one resource should be managed before another. See “Relationships and Ordering” in the Puppet language reference for more details.
resource
A unit of configuration, whose state can be managed by Puppet. Every resource has a type (such as file
, service
, or user
), a title, and one or more attributes with specified values (for example, an ensure
attribute with a value of present
).
Resources can be large or small, simple or complex, and they do not always directly map to simple details on the client – they might sometimes involve spreading information across multiple files, or even involve modifying devices. For example, a service
resource only models a single service, but may involve executing an init script, running an external command to check its status, and modifying the system’s run level configuration.
resource declaration
A fragment of Puppet code that details the desired state of a resource and instructs Puppet to manage it. This term helps to differentiate between the literal resource on disk and the specification for how to manage that resource. However, most often, these are just referred to as “resources.”
scope
The area of code where a variable has a given value.
Class definitions and type definitions create local scopes. Variables declared in a local scope are available by their short name (e.g. $my_variable
) inside the scope, but are hidden from other scopes unless you refer to them by their fully qualified name (e.g. $my_class::my_variable
).
Variables outside any definition (or set by an ENC) exist at a special “top scope;” they are available everywhere by their short names (e.g. $my_variable
), but can be overridden in a local scope if that scope has a variable of the same name.
Node definitions create a special “node scope.” Variables in this scope are also available everywhere by their short names, and can override top-scope variables.
Note: Previously, Puppet used dynamic scope, which would search for short-named variables through a long chain of parent scopes. This was deprecated in version 2.7 and will be removed in the next version. For more information, see Scope and Puppet.
site
An entire IT ecosystem being managed by Puppet. That is, a site includes all puppet master servers, all agent nodes, and all independent masterless Puppet nodes within an organization.
site manifest
The main “point of entry” manifest used by the puppet master when compiling a catalog. The location of this manifest is set with the manifest
setting in puppet.conf. Its default value is usually /etc/puppet/manifests/site.pp
or /etc/puppetlabs/puppet/manifests/site.pp
.
The site manifest usually contains node definitions. When an ENC is being used, the site manifest may be nearly empty, depending on whether the ENC was designed to have complete or partial node information.
site module
A common idiom in which one or more modules contain classes specific to a given Puppet site. These classes usually describe complete configurations for a specific system or a given group of systems. For example, the site::db_slave
class might describe the entire configuration of a database server, and a new database server could be configured simply by applying that class to it.
subclass
A class that inherits from another class. See inheritance.
subscribe
A notification relationship, set with the subscribe
metaparameter or the wavy chaining arrow. (~>
)
See “Relationships and Ordering” in the Puppet language reference for more details.
template
A partial document which is filled in with data from variables. Puppet can use Ruby ERB templates to generate configuration files tailored to an individual system. See Templating for more details.
title
The unique identifier (in a given Puppet catalog) of a resource or class.
- In a class, the title is simply the name of the class.
- In a resource declaration, the title is the part after the first curly brace and before the colon; in the example below, the title is
/etc/passwd
:
file { '/etc/passwd':
owner => 'root',
group => 'root',
}
- In native resource types, the name or namevar will use the title as its default value if you don’t explicitly specify a name.
- In a defined resource type or a class, the title is available for use throughout the definition as the
$title
variable.
Unlike the name or namevar, a resource’s title need not map to any actual attribute of the target system; it is only a referent. This means you can give a resource a single title even if its name has to vary across different kinds of system, like a configuration file whose location differs on Solaris.
For more on resource titles, see the Resources page of the latest Puppet language reference.
top scope
See scope.
type
A kind of resource that Puppet is able to manage; for example, file
, cron
, and service
are all resource types. A type specifies the set of attributes that a resource of that type may use, and models the behavior of that kind of resource on the target system. You can declare many resources of a given type.
Puppet ships with a set of built-in resource types; see the type reference for a complete list of them. New native types can be added as plugins, and defined types can be constructed by grouping together resources of existing types.
type (defined)
(or defined resource type; sometimes called a define or definition)
A resource type implemented as a group of other resources, written in the Puppet language and saved in a manifest. (For example, a defined type could use a combination of file
and exec
resources to set up and populate a Git repository.) Once a type is defined, new resources of that type can be declared just like any native or custom resource.
Since defined types are written in the Puppet language instead of as Ruby plugins, they are analogous to macros in other languages. Contrast with native types. For more information, see the Learning Puppet chapter on defined types.
type (native)
A resource type written in Ruby. Puppet ships with a large set of built-in native types, and custom native types can be distributed as plugins in modules. See the type reference for a complete list of built-in types.
Native types have lower-level access to the target system than defined types, and can directly use the system’s own tools to make changes. Most native types have one or more providers, so that they can implement the same resources on different kinds of systems.
variable
A named placeholder in a manifest that represents a value. Variables in Puppet are similar to variables in other programming languages, and are indicated with a dollar sign (e.g. $operatingsystem
) and assigned with the equals sign (e.g. $myvariable = "something"
). Once assigned, variables cannot be reassigned within the same scope; however, other local scopes can assign their own value to any variable name.
Facts from agent nodes are represented as variables within Puppet manifests, and are automatically pre-assigned before compilation begins. There are also several other special pre-assigned variables.
variable scoping
See scope above.
virtual resource
A resource that is declared in the catalog but will not be applied to a system unless it is explicitly realized.
See Virtual Resources for more details.
Contents
- attribute
- agent
- catalog
- class
- classify
- declare
- define
- define (noun)
- define (keyword)
- defined resource type
- ENC
- environment
- expression
- external node classifier
- fact
- Facter
- filebucket
- function
- global scope
- host
- host (resource type)
- idempotent
- inheritance (class)
- inheritance (node)
- master
- manifest
- metaparameter
- module
- namevar
- node (definition)
- node scope
- noop
- notify
- notification
- ordering
- parameter
- parameter (custom type and provider development)
- parameter (defined types and parameterized classes)
- parameter (external nodes)
- pattern
- plusignment operator
- property (custom type and provider development)
- provider
- plugin
- realize
- refresh
- relationship
- resource
- resource declaration
- scope
- site
- site manifest
- site module
- subclass
- subscribe
- template
- title
- top scope
- type
- type (defined)
- type (native)
- variable
- variable scoping
- virtual resource


| AbstractTlsAgreementCredentials |
|
| AbstractTlsCipherFactory |
|
| AbstractTlsClient |
|
| AbstractTlsCredentials |
|
| AbstractTlsEncryptionCredentials |
|
| AbstractTlsKeyExchange |
|
| AbstractTlsPeer |
|
| AbstractTlsServer |
|
| AbstractTlsSigner |
|
| AbstractTlsSignerCredentials |
|
| AlertDescription |
RFC 5246 7.2.
|
| AlertLevel |
RFC 5246 7.2
|
| BasicTlsPSKIdentity |
|
| BulkCipherAlgorithm |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| ByteQueue |
A queue for bytes.
|
| ByteQueueInputStream |
|
| ByteQueueOutputStream |
|
| CertChainType |
|
| Certificate |
Parsing and encoding of a Certificate struct from RFC 4346.
|
| CertificateRequest |
Parsing and encoding of a CertificateRequest struct from RFC 4346.
|
| CertificateStatus |
|
| CertificateStatusRequest |
|
| CertificateStatusType |
|
| CertificateURL |
|
| Chacha20Poly1305 |
|
| ChangeCipherSpec |
|
| CipherSuite |
RFC 2246 A.5
|
| CipherType |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| ClientAuthenticationType |
|
| ClientCertificateType |
|
| CompressionMethod |
RFC 2246 6.1
|
| ConnectionEnd |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| ContentType |
RFC 2246 6.2.1
|
| DefaultTlsAgreementCredentials |
|
| DefaultTlsCipherFactory |
|
| DefaultTlsClient |
|
| DefaultTlsEncryptionCredentials |
|
| DefaultTlsServer |
|
| DefaultTlsSignerCredentials |
|
| DefaultTlsSRPGroupVerifier |
|
| DigitallySigned |
|
| DTLSClientProtocol |
|
| DTLSClientProtocol.ClientHandshakeState |
|
| DTLSProtocol |
|
| DTLSServerProtocol |
|
| DTLSServerProtocol.ServerHandshakeState |
|
| DTLSTransport |
|
| ECBasisType |
RFC 4492 5.4.
|
| ECCurveType |
RFC 4492 5.4
|
| ECPointFormat |
RFC 4492 5.1.2
|
| EncryptionAlgorithm |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| ExporterLabel |
RFC 5705
|
| ExtensionType |
|
| FiniteFieldDHEGroup |
|
| HandshakeType |
|
| HashAlgorithm |
RFC 5246 <IP_ADDRESS>.1
|
| HeartbeatExtension |
|
| HeartbeatMessage |
|
| HeartbeatMessageType |
|
| HeartbeatMode |
|
| KeyExchangeAlgorithm |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| MACAlgorithm |
RFC 2246
Note that the values here are implementation-specific and arbitrary.
|
| MaxFragmentLength |
|
| NamedCurve |
RFC 4492 5.1.1
The named curves defined here are those specified in SEC 2 [13].
|
| NameType |
|
| NewSessionTicket |
|
| OCSPStatusRequest |
RFC 3546 3.6
|
| PRFAlgorithm |
RFC 5246
Note that the values here are implementation-specific and arbitrary.
|
| ProtocolVersion |
|
| PSKTlsClient |
|
| PSKTlsServer |
|
| SecurityParameters |
|
| ServerDHParams |
|
| ServerName |
|
| ServerNameList |
|
| ServerOnlyTlsAuthentication |
|
| ServerSRPParams |
|
| SessionParameters |
|
| SessionParameters.Builder |
|
| SignatureAlgorithm |
RFC 5246 <IP_ADDRESS>.1 (in RFC 2246, there were no specific values assigned)
|
| SignatureAndHashAlgorithm |
RFC 5246 <IP_ADDRESS>.1
|
| SimulatedTlsSRPIdentityManager |
An implementation of TlsSRPIdentityManager that simulates the existence of "unknown" identities
to obscure the fact that there is no verifier for them.
|
| SRPTlsClient |
|
| SRPTlsServer |
|
| SRTPProtectionProfile |
|
| SSL3Mac |
HMAC implementation based on original internet draft for HMAC (RFC 2104)
The difference is that padding is concatenated versus XORed with the key
H(K + opad, H(K + ipad, text))
|
| SupplementalDataEntry |
|
| SupplementalDataType |
RFC 4680
|
| TlsAEADCipher |
|
| TlsBlockCipher |
A generic TLS 1.0-1.2 / SSLv3 block cipher.
|
| TlsClientProtocol |
|
| TlsDHEKeyExchange |
|
| TlsDHKeyExchange |
(D)TLS DH key exchange.
|
| TlsDHUtils |
|
| TlsDSASigner |
|
| TlsDSSSigner |
|
| TlsECCUtils |
|
| TlsECDHEKeyExchange |
(D)TLS ECDHE key exchange (see RFC 4492).
|
| TlsECDHKeyExchange |
(D)TLS ECDH key exchange (see RFC 4492).
|
| TlsECDSASigner |
|
| TlsExtensionsUtils |
|
| TlsMac |
A generic TLS MAC implementation, acting as an HMAC based on some underlying Digest.
|
| TlsNullCipher |
A NULL CipherSuite with optional MAC
|
| TlsNullCompression |
|
| TlsProtocol |
|
| TlsPSKKeyExchange |
(D)TLS PSK key exchange (RFC 4279).
|
| TlsRSAKeyExchange |
(D)TLS and SSLv3 RSA key exchange.
|
| TlsRSASigner |
|
| TlsRSAUtils |
|
| TlsServerProtocol |
|
| TlsSRPKeyExchange |
(D)TLS SRP key exchange (RFC 5054).
|
| TlsSRPLoginParameters |
|
| TlsSRPUtils |
|
| TlsSRTPUtils |
RFC 5764 DTLS Extension to Establish Keys for SRTP.
|
| TlsStreamCipher |
|
| TlsUtils |
Some helper functions for MicroTLS.
|
| UDPTransport |
|
| URLAndHash |
RFC 6066 5.
|
| UserMappingType |
RFC 4681
|
| UseSRTPData |
RFC 5764 4.1.1
|


UI/UX/Front end development
Google Design Challenge/UX/UI
Creative Coding/Sound Visualization/Animation
Arduino/Processing/Circuit/Prototype
Electronic Art/Cloth Crat/Installation
Speculation Design/Interface Design/
Experimenting/HTML/CSS/Javascript
Interface Design/Programming/Utility
Creative Coding/HTML/CSS/p>


|
ci_example_python
|
Feel free to extend the list if you find a plugin for an editor not yet listed here or a better plugin for one that is already listed.
Note that you need to be careful to use flake8 for the correct Python version.
VS Code already has built-in support for flake8 but it needs to be enabled in the configuration. See the official documentation for instructions.
Syntastic is a plugin for running external style checkers that can run flake8.
let g:syntastic_python_checkers = ['flake8'] " to ensure flake8 checks for python 3 code: let g:syntastic_python_flake8_exe = 'python3 -m flake8'
ALE is a plugin for running linters asynchronously. As it runs the linter in the background, it is preferable over Syntastic, however, it needs Vim version 8 or later or Neovim.
To ensure using flake for Python 3, use the following configuration:
let g:ale_python_flake8_executable = 'python3' let g:ale_python_flake8_options = '-m flake8'


|
DSL-ABM
|
#include "contributions_tests.h"
Functions | |
| bool | contributions_main_test () |
| Test for correct computing of infection contributions. More... | |
| bool | contributions_treatment_test () |
| Test for correct computing of infection contributions for treated agents. More... | |
| bool | contributions_misc_test () |
| Test for correct computing of infection contributions of various other types of agents. More... | |
| bool | check_all_places (ABM &, const std::vector< Agent > &) |
| void | remove_agent_from_public_places (Agent &agent, std::vector< RetirementHome > &retirement_homes, std::vector< School > &schools, std::vector< Workplace > &workplaces, std::vector< Hospital > &hospitals) |
| Remove agent from all public places (hospital only if not hospitalized) More... | |
| int | main () |
| bool contributions_main_test | ( | ) |
Test for correct computing of infection contributions.
| bool contributions_misc_test | ( | ) |
Test for correct computing of infection contributions of various other types of agents.
| bool contributions_treatment_test | ( | ) |
Test for correct computing of infection contributions for treated agents.
| int main | ( | ) |
| void remove_agent_from_public_places | ( | Agent & | agent, |
| std::vector< RetirementHome > & | retirement_homes, | ||
| std::vector< School > & | schools, | ||
| std::vector< Workplace > & | workplaces, | ||
| std::vector< Hospital > & | hospitals | ||
| ) |
Remove agent from all public places (hospital only if not hospitalized)


THE CITY OF THE MONTH
THE GUIDE
THE TRIPS
YOUR LIFESTYLE
OUR OFFER
LOGIN
SIGN IN
Mail
Password
Login


module STLC
FIXME (Cătălin)
Any way I could have imported the existing code here without duplicating it? Without a way to do this maintaining this document and keeping it consistent will be a nightmare.
We now look at a larger case study: proving the soundness of a type-checker for the simply-typed \(\lambda\)-calculus (STLC). If you're not familiar with STLC, you can have a look at the Software Foundations book for a gentle introduction given by the textual explanations (you can ignore the Coq parts there). The formalization and proof here closely follows the one in Software Foundations. Our proofs are, however, shorter and much more readable than Coq proofs.
We represent STLC types by the F* inductive datatype ty.
type ty = | TBool : ty | TArrow : tin:ty -> tout:ty -> ty type var = int
We consider Booleans as the only base type (TBool). Function types are represented by the TArrow constructor taking two type arguments. For instance we write TArrow TBool TBool for the type of functions taking a Boolean argument and returning a Boolean result. This would be written as bool -> bool in F* syntax, and \(\mathsf{bool} \to \mathsf{bool}\) in paper notation.
We represent the expressions of STLC by the datatype exp.
type exp = | EVar : v:var -> exp | EApp : fn:exp -> arg:exp -> exp | EAbs : v:var -> vty:ty -> body:exp -> exp | ETrue : exp | EFalse : exp | EIf : test:exp -> btrue:exp -> bfalse:exp -> exp
Variables are represented as integer "names" decorated by the constructor EVar. Variables are "bound" by lambda abstractions (EAbs). For instance the identity function on Booleans is written EAbs 0 TBool (EVar 0). In paper notation one would write this function as \((\lambda x:\mathsf{bool}.~x)\). The type annotation on the argument (TBool) allows for very simple type-checking. We are not considering type inference here, to keep things simple. The expression that applies the identity function to the ETrue constant is written
let stlc_app_id_to_true = EApp (EAbs 0 TBool (EVar 0)) ETrue
(in paper notation \((\lambda x:\mathsf{bool}.~x)~\mathsf{true}\)).
The language also has a conditional construct (if-then-else). For instance, the Boolean "not" function can be written as
let stlc_not = EAbs 0 TBool (EIf (EVar 0) EFalse ETrue)
(in paper notation \(\lambda x:\mathsf{bool}.~\mathsf{if }~x~\mathsf{ then~false~else~true}\)).
We define a standard small-step call-by-value interpreter for STLC. The final result of successfully evaluating an expression is called a value. We postulate that functions and the Boolean constants are values by defining is_value, a boolean predicate on expressions (a total function):
val is_value : exp -> Tot bool let is_value e = match e with | EAbs _ _ _ | ETrue | EFalse -> true | _ -> false
The EAbs, ETrue, and EFalse cases share the same right-hand-side (true), which is a way to prevent duplication in definitions.
In order to give a semantics to function applications we define a function subst x e e' that substitutes x with e in e':
val subst : int -> exp -> exp -> Tot exp let rec subst x e e' = match e' with | EVar x' -> if x = x' then e else e' | EAbs x' t e1 -> EAbs x' t (if x = x' then e1 else (subst x e e1)) | EApp e1 e2 -> EApp (subst x e e1) (subst x e e2) | ETrue -> ETrue | EFalse -> EFalse | EIf e1 e2 e3 -> EIf (subst x e e1) (subst x e e2) (subst x e e3)
We traverse the expression and when we reach a variable (EVar x') we check whether this is the variable x we want to substitute, and if it is we replace it by e. For lambda abstractions (EAbs x' t e1) we only substitute inside the body e1 if x and x' are different; if they are the same we leave the body unchanged. The reason for this is that the x in e1 is bound by the abstraction: it is a new, local name that just happens to be spelled the same as some global name x. The global x is no longer accessible in this scope, since it is shadowed by the local x. The other cases are straightforward.
Note for experts: Because we will only reduce closed expressions, where all variables are bound by previous lambdas, we will only ever substitute closed expressions e, and this naive definition of substitution is good enough. Substitution would become trickier to define or the representation of variables would have to change if we were considering the case where e, the expression replacing a variable in some other expression, may itself contain free variables.
Given the definition of values and of substitution we can now define a small-step interpreter, as a function step that takes an expression e and it either returns the expression to which e reduces in a single step, or it returns None in case of an error (all errors in this language are typing errors, and will be prevented statically by the type system).
val step : exp -> Tot (option exp) let rec step e = match e with | EApp e1 e2 -> if is_value e1 then if is_value e2 then match e1 with | EAbs x t e' -> Some (subst x e2 e') | _ -> None else match (step e2) with | Some e2' -> Some (EApp e1 e2') | None -> None else (match (step e1) with | Some e1' -> Some (EApp e1' e2) | None -> None) | EIf e1 e2 e3 -> if is_value e1 then match e1 with | ETrue -> Some e2 | EFalse -> Some e3 | _ -> None else (match (step e1) with | Some e1' -> Some (EIf e1' e2 e3) | None -> None) | _ -> None
We execute an application expression EApp e1 e2 in multiple steps by first reducing e1 to a value, then reducing e2 to a value (following a call-by-value evaluation order), and if additionally e1 is an abstraction EAbs x t e'we continue by substituting the formal argument x by the actual argument e2. If not we signal a dynamic typing error (a non-functional value is applied to arguments) by returning None. For EIf e1 e2 e3 we first reduce the guard e1: if the guard reduces to true then we continue with e2, if the guard reduces to false we continue with e3, and if the guard reduces to something else (e.g. a function) we report a dynamic typing error. The None -> None cases simply propagate errors to the top level.
let _ = assert (step (EApp (EAbs 0 TBool (EVar 0)) ETrue) = Some ETrue) let _ = assert (step (EApp ETrue ETrue) = None)
In order to assign a type to a term, we need to know what assumptions we should make about the types of its free variables. So typing happens with respect to a typing environment—a mapping from the variables in scope to their types. We represent such partial maps as functions taking an integer variable name and returning an optional type:
type env = int -> Tot (option ty)
We start type-checking closed terms in the empty environment, i.e. initially no variables are in scope.
val empty : env let empty = fun _ -> None
When we move under a binder we extend the typing environment.
val extend : env -> int -> ty -> Tot env let extend g x t = fun x' -> if x = x' then Some t else g x'
For instance we type-check EAbs x t e in typing environment g by first type-checking the body e in the environment extend g x t.
The type-checker is a total function taking an environment g and an expression e and producing either the type of e or None if e is not well-typed.
val typing : env -> exp -> Tot (option ty) let rec typing g e = match e with | EVar x -> g x | EAbs x t e1 -> (match typing (extend g x t) e1 with | Some t' -> Some (TArrow t t') | None -> None) | EApp e1 e2 -> (match typing g e1, typing g e2 with | Some (TArrow t11 t12), Some t2 -> if t11 = t2 then Some t12 else None | _ , _ -> None) | ETrue -> Some TBool | EFalse -> Some TBool | EIf e1 e2 e3 -> (match typing g e1, typing g e2, typing g e3 with | Some TBool, Some t2, Some t3 -> if t2 = t3 then Some t2 else None | _ , _ , _ -> None)
Variables are simply looked up in the environment. For abstractions EAbs x t e1 we type-check the body e1 under the environment extend g x t, as explained above. If that succeeds and produces a type t', then the whole abstraction is given type TArrow t t'. For applications EApp e1 e2 we type-check e1 and e2 separately, and if e1 has a function type TArrow t11 t12 and e2 has type t11, then the whole application has type t12. ETrue and EFalse have type TBool. For conditionals, we require that the guard has type TBool and the two branches have the same type, which is also the type of the conditional.
FIXME (Cătălin)
I generally find giving people finished proofs uninformative and unhelpful.
This seems like something to do from scratch in an emacs buffer. Trying to capture that kind of interaction in the current format seems very hard.
We prove progress and preservation for STLC. The progress theorem tells us that closed, well-typed terms do not produce (immediate) dynamic typing errors: either a well-typed term is a value, or it can take an evaluation step. The proof is a relatively straightforward induction.
val progress : e:exp -> Lemma (requires (Some? (typing empty e))) (ensures (is_value e \/ (Some? (step e)))) let rec progress e = match e with | EApp e1 e2 -> progress e1; progress e2 | EIf e1 e2 e3 -> progress e1; progress e2; progress e3 | _ -> ()
Variables are not well-typed in the empty environment, so the theorem holds vacuously for variables. Boolean constants and abstractions are values, so the theorem holds trivially for these. All these simple cases are proved automatically by F*. For the remaining cases we need to use the induction hypothesis, but otherwise the proofs are fully automated. Under the hood F* and Z3 are doing quite a bit of work though.
In case e = (EApp e1 e2) F* and Z3 automate the following intuitive argument: We case split on the first instance of the induction hypothesis (is_value e1 \/ (Some? (step e1))).
The intuitive proof of the EIf case is similar.
The preservation theorem (sometimes also called "subject reduction") states that when a well-typed expression takes a step, the result is a well-typed expression of the same type. In order to show preservation we need to prove a couple of auxiliary results for reasoning about variables and substitution.
The case for function application has to reason about "beta reduction" steps, i.e. substituting the formal argument of a function with an actual value. To see that this step preserves typing, we need to know that the substitution itself does. So we prove a substitution lemma, stating that substituting a (closed) term v for a variable x in an expression e preserves the type of e. The tricky cases in the substitution proof are the ones for variables and for function abstractions. In both cases, we discover that we need to take an expression e that has been shown to be well-typed in some context g and consider the same expression e in a slightly different context g'. For this we prove a context invariance lemma, showing that typing is preserved under "inessential changes" to the context g—in particular, changes that do not affect any of the free variables of the expression. For this, we need a definition of the free variables of an expression—i.e., the variables occurring in the expression that are not bound by an abstraction.
A variable x appears free in e if e contains some occurrence of x that is not under an abstraction labeled x:
val appears_free_in : x:int -> e:exp -> Tot bool let rec appears_free_in x e = match e with | EVar y -> x = y | EApp e1 e2 -> appears_free_in x e1 || appears_free_in x e2 | EAbs y _ e1 -> x <> y && appears_free_in x e1 | EIf e1 e2 e3 -> appears_free_in x e1 || appears_free_in x e2 || appears_free_in x e3 | ETrue | EFalse -> false
We also need a technical lemma connecting free variables and typing contexts. If a variable x appears free in an expression e, and if we know that e is well typed in context g, then it must be the case that g assigns some type to x.
val free_in_context : x:int -> e:exp -> g:env -> Lemma (requires (Some? (typing g e))) (ensures (appears_free_in x e ==> Some? (g x))) let rec free_in_context x e g = match e with | EVar _ | ETrue | EFalse -> () | EAbs y t e1 -> free_in_context x e1 (extend g y t) | EApp e1 e2 -> free_in_context x e1 g; free_in_context x e2 g | EIf e1 e2 e3 -> free_in_context x e1 g; free_in_context x e2 g; free_in_context x e3 g
The proof is a straightforward induction. As a corollary for g == empty we obtain that expressions typable in the empty environment have no free variables.
val typable_empty_closed : x:int -> e:exp -> Lemma (requires (Some? (typing empty e))) (ensures (not(appears_free_in x e))) [SMTPat (appears_free_in x e)] let typable_empty_closed x e = free_in_context x e empty
The quantifier pattern [SMTPat (appears_free_in x e)] signals to Z3 that it should consider applying this lemma when its context contains a term of the form appears_free_in
Sometimes, we know that typing g e = Some t, and we will need to replace g by an "equivalent" context g'. We still need to define formally when two environments are equivalent. A natural definition is extensional equivalence of functions:
logic type equal (g1:env) (g2:env) = forall (x:int). g1 x = g2 x
According to this definition two environments are equivalent if have the same domain and they map all variables in the domain to the same type. We remark equal in particular and logical formulas in general are types in F*, thus the different syntax for this definition.
FIXME (Cătălin)
What does opaque do exactly? What does logic do? Hints for the SMT solver / logical encoding only?
The context invariance lemma uses in fact a weaker variant of this equivalence in which the two environments only need to agree on the variables that appear free in an expression e:
logic type equalE (e:exp) (g1:env) (g2:env) = forall (x:int). appears_free_in x e ==> g1 x = g2 x
The context invariance lemma is then easily proved by induction:
val context_invariance : e:exp -> g:env -> g':env -> Lemma (requires (equalE e g g')) (ensures (typing g e == typing g' e)) let rec context_invariance e g g' = match e with | EAbs x t e1 -> context_invariance e1 (extend g x t) (extend g' x t) | EApp e1 e2 -> context_invariance e1 g g'; context_invariance e2 g g' | EIf e1 e2 e3 -> context_invariance e1 g g'; context_invariance e2 g g'; context_invariance e3 g g' | _ -> ()
Because equal is a stronger relation than equalE we obtain the same property for equal:
val typing_extensional : g:env -> g':env -> e:exp -> Lemma (requires (equal g g')) (ensures (typing g e == typing g' e)) let typing_extensional g g' e = context_invariance e g g'
We can use these results to show the following substitution lemma:
val substitution_preserves_typing : x:int -> e:exp -> v:exp -> g:env -> Lemma (requires (Some? (typing empty v) /\ Some? (typing (extend g x (Some?.v (typing empty v))) e))) (ensures (Some? (typing empty v) /\ typing g (subst x v e) == typing (extend g x (Some?.v (typing empty v))) e)) let rec substitution_preserves_typing x e v g = let Some t_x = typing empty v in let gx = extend g x t_x in match e with | ETrue -> () | EFalse -> () | EVar y -> if x=y then context_invariance v empty g (* uses lemma typable_empty_closed *) else context_invariance e gx g | EApp e1 e2 -> substitution_preserves_typing x e1 v g; substitution_preserves_typing x e2 v g | EIf e1 e2 e3 -> substitution_preserves_typing x e1 v g; substitution_preserves_typing x e2 v g; substitution_preserves_typing x e3 v g | EAbs y t_y e1 -> let gxy = extend gx y t_y in let gy = extend g y t_y in if x=y then typing_extensional gxy gy e1 else (let gyx = extend gy x t_x in typing_extensional gxy gyx e1; substitution_preserves_typing x e1 v gy)
The proof proceeds by induction on the expression e; we give the intuition of the two most interesting cases:
Case e = EVar y
Case x = y: We have subst x v e = v and we already know that typing empty v == Some t_x. However, what we need to show is typing g v == Some t_x for some arbitrary environment g. From the typable_empty_closed lemma we obtain that v contains no free variables, so we have equalE v empty g. This allows us to apply the context_invariance lemma to obtain that typing empty v = typing g v and complete the proof of this case.
Case x <> y We have subst x v e = e and typing gx e = Some t_e and need to show that
typing g e == Some t_e
We have that EquivE (EVar y) gx g since x <> y so we can apply the context_invariance lemma to conclude.
Case e = EAbs y t_y e1: We have that typing gxy e1 = Some t_e1, and need to show that typing gy e1 == Some t_e1
Case x = y We have subst x v e = EAbs y t_y e1. Since x = y the x binder in gxy is spurious (we have equal gy gxy) and can apply the typing_extensional lemma.
Case x <> y We have subst x v e = EAbs y t_y (subst x v e1). Since x <> y (and since we are in a simply typed calculus, not a dependently typed one) we can swap the x and y binding to show that equal gxy xyx. By the typing_extensional lemma we obtain that typing gxy e1 == typing gyx e1. By the induction hypothesis we thus obtain that
typing gy (subst x v e1) == Some t_e1
and by the definition of typing we conclude that typing g (EAbs y t_y (subst x v e)) = t_e.
We now have the tools we need to prove preservation: if a closed expression e has type t and takes an evaluation step to e', then e' is also a closed expression with type t. In other words, the small-step evaluation relation preserves types.
val preservation : e:exp -> Lemma (requires (Some? (typing empty e) /\ Some? (step e) )) (ensures (Some? (step e) /\ typing empty (Some?.v (step e)) == typing empty e)) let rec preservation e = match e with | EApp e1 e2 -> if is_value e1 then (if is_value e2 then let EAbs x _ ebody = e1 in substitution_preserves_typing x ebody e2 empty else preservation e2) else preservation e1 | EIf e1 _ _ -> if not (is_value e1) then preservation e1
We only have two cases to consider, since only applications and conditionals can take successful execution steps. The case for e = EIf e1 e2 e3 is simple: either e1 is a value and thus the conditional reduces to e2 or e3 which by the typing hypothesis also have type t, or e1 takes a successful step and we can apply the induction hypothesis. We use the Some?.v projector, which requires F* to prove that indeed e1 can take a step; this is immediate since we know that the whole conditional takes a step and we know that e1 is not a value.
The case for e = EApp e1 e2 is a bit more complex. If e1 steps or if e1 is a value and e2 steps then we just apply the induction hypothesis. If both e1 and e2 are values it needs to be the case that e1 is an abstraction EAbs x targ ebody and step e = subst x e2 ebody. From the typing assumption we have typing (extend empty x tags) ebody = Some t and typing empty e2 = Some targ, so we can use the substitution lemma to obtain that typing empty (subst x e2 ebody) = Some t, which concludes the proof.
Define a typed_step step function that takes a well-typed expression e that is not a value and produces the expression to which e steps. Give typed_step the following strong type (basically this type captures both progress and preservation):
val typed_step : e:exp{Some? (typing empty e) /\ not(is_value e)} -> Tot (e':exp{typing empty e' = typing empty e})
(Hint: the most direct solution to this exercise fits on one line)
let typed_step e = progress e; preservation e; Some?.v (step e)
To add pairs to this formal development we add the following to the definition of types, expressions, values, substitution, and step:
type tyP = (* {{{ 2 unchanged cases *) | TBoolP : tyP | TArrowP : tin:tyP -> tout:tyP -> tyP (* }}} *) | TPairP : tyP -> tyP -> tyP type expP = (* {{{ 6 unchanged cases *) | EVarP : v:var -> expP | EAppP : fn:expP -> arg:expP -> expP | EAbsP : v:var -> vty:tyP -> body:expP -> expP | ETrueP : expP | EFalseP : expP | EIfP : test:expP -> btrue:expP -> bfalse:expP -> expP (* }}} *) | EPairP : expP -> expP -> expP | EFstP : expP -> expP | ESndP : expP -> expP let rec is_valueP e = (* Note the extra let rec! *) match e with (* {{{ 3 unchanged cases *) | EAbsP _ _ _ | ETrueP | EFalseP -> true (* }}} *) | EPairP e1 e2 -> is_valueP e1 && is_valueP e2 | _ -> false let rec substP x e e' = match e' with (* {{{ 6 unchanged cases *) | EVarP x' -> if x = x' then e else e' | EAbsP x' t e1 -> EAbsP x' t (if x = x' then e1 else (substP x e e1)) | EAppP e1 e2 -> EAppP (substP x e e1) (substP x e e2) | ETrueP -> ETrueP | EFalseP -> EFalseP | EIfP e1 e2 e3 -> EIfP (substP x e e1) (substP x e e2) (substP x e e3) (* }}} *) | EPairP e1 e2 -> EPairP (substP x e e1) (substP x e e2) | EFstP e1 -> EFstP (substP x e e1) | ESndP e1 -> ESndP (substP x e e1) let rec stepP e = match e with (* {{{ 2 unchanged cases *) | EAppP e1 e2 -> if is_valueP e1 then if is_valueP e2 then match e1 with | EAbsP x t e' -> Some (substP x e2 e') | _ -> None else match (stepP e2) with | Some e2' -> Some (EAppP e1 e2') | None -> None else (match (stepP e1) with | Some e1' -> Some (EAppP e1' e2) | None -> None) | EIfP e1 e2 e3 -> if is_valueP e1 then match e1 with | ETrueP -> Some e2 | EFalseP -> Some e3 | _ -> None else (match (stepP e1) with | Some e1' -> Some (EIfP e1' e2 e3) | None -> None) (* }}} *) | EPairP e1 e2 -> if is_valueP e1 then if is_valueP e2 then None else (match (stepP e2) with | Some e2' -> Some (EPairP e1 e2') | None -> None) else (match (stepP e1) with | Some e1' -> Some (EPairP e1' e2) | None -> None) | EFstP e1 -> if is_valueP e1 then (match e1 with | EPairP v1 v2 -> Some v1 | _ -> None) else (match (stepP e1) with | Some e1' -> Some (EFstP e1') | None -> None) | ESndP e1 -> if is_valueP e1 then (match e1 with | EPairP v1 v2 -> Some v2 | _ -> None) else (match (stepP e1) with | Some e1' -> Some (ESndP e1') | None -> None) | _ -> None
Add cases to typingP for the new constructs and fix all the proofs.
We extend the typingP and appears_free_inP functions with cases for EPairP, EFstP, and ESndP:
type envP = int -> Tot (option tyP) val emptyP : envP let emptyP = fun _ -> None
When we move under a binder we extend the typing environment.
val extendP : envP -> int -> tyP -> Tot envP let extendP g x t = fun x' -> if x = x' then Some t else g x' val typingP : envP -> expP -> Tot (option tyP) let rec typingP g e = match e with (* {{{ 6 unchanged cases *) | EVarP x -> g x | EAbsP x t e1 -> (match typingP (extendP g x t) e1 with | Some t' -> Some (TArrowP t t') | None -> None) | EAppP e1 e2 -> (match typingP g e1, typingP g e2 with | Some (TArrowP t11 t12), Some t2 -> if t11 = t2 then Some t12 else None | _ , _ -> None) | ETrueP -> Some TBoolP | EFalseP -> Some TBoolP | EIfP e1 e2 e3 -> (match typingP g e1, typingP g e2, typingP g e3 with | Some TBoolP, Some t2, Some t3 -> if t2 = t3 then Some t2 else None | _ , _ , _ -> None) (* }}} *) | EPairP e1 e2 -> (match typingP g e1, typingP g e2 with | Some t1, Some t2 -> Some (TPairP t1 t2) | _ , _ -> None) | EFstP e1 -> (match typingP g e1 with | Some (TPairP t1 t2) -> Some t1 | _ -> None) | ESndP e1 -> (match typingP g e1 with | Some (TPairP t1 t2) -> Some t2 | _ -> None) val appears_free_inP : x:int -> e:expP -> Tot bool let rec appears_free_inP x e = match e with (* {{{ 6 unchanged cases *) | EVarP y -> x = y | EAppP e1 e2 -> appears_free_inP x e1 || appears_free_inP x e2 | EAbsP y _ e1 -> x <> y && appears_free_inP x e1 | EIfP e1 e2 e3 -> appears_free_inP x e1 || appears_free_inP x e2 || appears_free_inP x e3 | ETrueP | EFalseP -> false (* }}} *) | EPairP e1 e2 -> appears_free_inP x e1 || appears_free_inP x e2 | EFstP e1 -> appears_free_inP x e1 | ESndP e1 -> appears_free_inP x e1
The proofs of the lemmas are also easy to extend by just calling the induction hypothesis:
val free_in_contextP : x:int -> e:expP -> g:envP -> Lemma (requires (Some? (typingP g e))) (ensures (appears_free_inP x e ==> Some? (g x))) let rec free_in_contextP x e g = match e with (* {{{ 6 unchanged cases *) | EVarP _ | ETrueP | EFalseP -> () | EAbsP y t e1 -> free_in_contextP x e1 (extendP g y t) | EAppP e1 e2 -> free_in_contextP x e1 g; free_in_contextP x e2 g | EIfP e1 e2 e3 -> free_in_contextP x e1 g; free_in_contextP x e2 g; free_in_contextP x e3 g (* }}} *) | EPairP e1 e2 -> free_in_contextP x e1 g; free_in_contextP x e2 g | EFstP e1 | ESndP e1 -> free_in_contextP x e1 g logic type equalEP (e:expP) (g1:envP) (g2:envP) = forall (x:int). appears_free_inP x e ==> g1 x = g2 x val context_invarianceP : e:expP -> g:envP -> g':envP -> Lemma (requires (equalEP e g g')) (ensures (typingP g e == typingP g' e)) let rec context_invarianceP e g g' = match e with (* {{{ 3 unchanged cases *) | EAbsP x t e1 -> context_invarianceP e1 (extendP g x t) (extendP g' x t) | EAppP e1 e2 -> context_invarianceP e1 g g'; context_invarianceP e2 g g' | EIfP e1 e2 e3 -> context_invarianceP e1 g g'; context_invarianceP e2 g g'; context_invarianceP e3 g g' (* }}} *) | EPairP e1 e2 -> context_invarianceP e1 g g'; context_invarianceP e2 g g' | EFstP e1 | ESndP e1 -> context_invarianceP e1 g g' | _ -> () (* {{{ similar definitions skipped *) logic type equalP (g1:envP) (g2:envP) = forall (x:int). g1 x = g2 x val typing_extensionalP : g:envP -> g':envP -> e:expP -> Lemma (requires (equalP g g')) (ensures (typingP g e == typingP g' e)) let typing_extensionalP g g' e = context_invarianceP e g g' val typable_empty_closedP : x:int -> e:expP -> Lemma (requires (Some? (typingP emptyP e))) (ensures (not(appears_free_inP x e))) [SMTPat (appears_free_inP x e)] let typable_empty_closedP x e = free_in_contextP x e emptyP (* }}} *) val substitution_preserves_typingP : x:int -> e:expP -> v:expP -> g:envP -> Lemma (requires (Some? (typingP emptyP v) /\ Some? (typingP (extendP g x (Some?.v (typingP emptyP v))) e))) (ensures (Some? (typingP emptyP v) /\ typingP g (substP x v e) == typingP (extendP g x (Some?.v (typingP emptyP v))) e)) let rec substitution_preserves_typingP x e v g = (* {{{ unchanged preamble skipped *) let Some t_x = typingP emptyP v in let gx = extendP g x t_x in match e with | ETrueP -> () | EFalseP -> () | EVarP y -> if x=y then context_invarianceP v emptyP g (* uses lemma typable_empty_closed *) else context_invarianceP e gx g | EAppP e1 e2 -> substitution_preserves_typingP x e1 v g; substitution_preserves_typingP x e2 v g | EIfP e1 e2 e3 -> substitution_preserves_typingP x e1 v g; substitution_preserves_typingP x e2 v g; substitution_preserves_typingP x e3 v g | EAbsP y t_y e1 -> let gxy = extendP gx y t_y in let gy = extendP g y t_y in if x=y then typing_extensionalP gxy gy e1 else (let gyx = extendP gy x t_x in typing_extensionalP gxy gyx e1; substitution_preserves_typingP x e1 v gy) (* }}} *) | EPairP e1 e2 -> (substitution_preserves_typingP x e1 v g; substitution_preserves_typingP x e2 v g) | EFstP e1 | ESndP e1 -> substitution_preserves_typingP x e1 v g | _ -> ()
As for the other cases, the preservation proof when e = EPair e1 e2 follows the structure of the step function. If e1 is not a value then it further evaluates, so we apply the induction hypothesis to e1. If e1 is a value, then since we know that the pair evaluates, it must be the case that e2 is not a value and further evaluates, so we apply the induction hypothesis to it. The cases for EFst and ESnd are similar.
val preservationP : e:expP{Some? (typingP emptyP e) /\ Some? (stepP e)} -> Tot (u:unit{typingP emptyP (Some?.v (stepP e)) == typingP emptyP e}) let rec preservationP e = match e with (* {{{ two unchanged cases *) | EAppP e1 e2 -> if is_valueP e1 then (if is_valueP e2 then let EAbsP x _ ebody = e1 in substitution_preserves_typingP x ebody e2 emptyP else preservationP e2) else preservationP e1 | EIfP e1 _ _ -> if not (is_valueP e1) then preservationP e1 (* }}} *) | EPairP e1 e2 -> (match is_valueP e1, is_valueP e2 with | false, _ -> preservationP e1 | true , false -> preservationP e2) | EFstP e1 | ESndP e1 -> if not (is_valueP e1) then preservationP e1
We want to add a let construct to this formal development. We add the following to the definition of expressions:
type exp = ... | ELet : int -> exp -> exp -> exp
Add cases for ELet to all definitions and proofs.
FIXME (Cătălin)
Make the prev kind of link a macro of some sorts. It doesn't have a proper body so it's not an environment, but what is it? Entity?
Define a big-step interpreter for STLC as a recursive function eval that given a well-typed expression e either produces the well-typed value v to which e evaluates or it diverges if the evaluation of e loops. Give eval the following strong type ensuring that v has the same type as e (basically this type captures both progress and preservation):
val eval : e:exp{Some? (typing empty e)} -> Dv (v:exp{is_value v && typing empty v = typing empty e})
The Dv effect is that of potentially divergent computations. We cannot mark this as Tot since a priori STLC computations could loop, and it is hard to prove that well-typed ones don't.
Here is a solution that only uses typed_step (suggested by Santiago Zanella):
let rec eval e = if is_value e then e else eval (typed_step e)
or using the progress and preservation lemmas instead of typed_step (suggested by Guido Martinez):
val eval' : e:exp{Some? (typing empty e)} -> Dv (v:exp{is_value v && typing empty v = typing empty e}) let rec eval' e = match step e with | None -> progress e; e | Some e' -> preservation e; eval' e'
Here is another solution that only uses the substitution lemma:
val eval'' : e:exp{Some? (typing empty e)} -> Dv (v:exp{is_value v && typing empty v = typing empty e}) let rec eval'' e = let Some t = typing empty e in match e with | EApp e1 e2 -> (let EAbs x _ e' = eval' e1 in let v = eval' e2 in substitution_preserves_typing x e' v empty; eval'' (subst x v e')) | EAbs _ _ _ | ETrue | EFalse -> e | EIf e1 e2 e3 -> (match eval'' e1 with | ETrue -> eval'' e2 | EFalse -> eval'' e3)


Given the deﬁnition of a magnetic surface coordinate system (ψ,𝜃,ϕ), the Jacobian of this system is fully determined. On the other hand, given the deﬁnition of ψ, ϕ, and the Jacobian, the deﬁnition of 𝜃 is fully determined (can have some trivial shifting freedoms). Next, let us discuss how to calculate 𝜃 in this case. In (ψ,𝜃,ϕ) coordinates, a line element is written
|
| (165) |
The line element that lies on a magnetic surface (i.e., dψ = 0) and in a poloidal plane (i.e., dϕ = 0) is then written
|
| (167) |
Using the fact that ∇ψ and ∇ϕ are orthogonal and ∇ϕ = ∕R, the above equation is written as
|
| (168) |
Given |𝒥∇ψ|, Eq. (168) can be integrated to determine the 𝜃 coordinate of points on a magnetic surface.


paginate(str, x, y, width, height, **options)
Generate Text objects for a string with the given x/y and width/height
paginate(x, y, width, height, str="", **options)
The string can be omitted as the first arg if provided as a keyword argument
paginate(x, y, width, height, xml="", **options)
If an xml string is passed as a keyword argument, its tags will be mapped to font definitions in the canvas's Stylesheet
paginate(x, y, width, height, src="<path or url>", **options)
Load the file pointed to by the src argument and draw its contents
paginate(Text, folio=1, verso=None)
Generate pages from an existing Text object
Returns a generator which yields one or more Text objects with a fixed position and size. The syntax is identical to that of the text() command, but rather than drawing to the canvas it returns the resulting Text objects for your script to plot() manually.
The paginate() command can be useful when drawing long passages of text that may not fit in a single text block (or on a single canvas frame). The objects it returns are standard Text objects but contain two additional "counter" attributes that may be useful during layout:
txt.folio # the "page number" of the object (typically counting from one) txt.pg # the index of the object in the series (counting from zero)
folio
Sets the "page number" of the first Text object in the sequence – accessible through its corresponding .folio attribute. Subsequent objects in the sequence count up from there. Defaults to 1 if omitted.
verso
Pass a 2-tuple to set x/y coordinates for "even" pages in the sequence. If omitted, all the Text objects will use the same x/y position as defined in the positional arguments.
an iterable generator of Text objects (as many as needed to fully lay out the string)
with export('~/book.pdf') as book: size(340, 450) for txt in paginate(40,40, 600,800, src='~/Documents/war-and-peace.txt'): with book.page: plot(txt) text(WIDTH/2, 430, align=CENTER, size=9, str=txt.pg+1)


HOME
GALLERY
ABOUT
EVENTS
HOVER
ACTIVE
LINK
CONTACT
COURSES
HTML
CSS
JAVASCRIPT
BOOTSTRAP
JQUERY
AJAX
REACT JS


hello
my name Hummer1972 my real name its freerk
iam from netherlands (town groningen )
iam 40 years old and play battelfield 2 and 3 ohter game,s
nice tool Battlelog works good on firefox i like it now
and sorry for wrong english word my english not so good :(
iam happy to join the Better Battlelog Big Hooah for the makers fron this tool great work :)
José Ortega
Global Moderator
Welcome.

Meaurk
Global Moderator
Welcome Freerk, not a usual Dutch name, is it?
Have fun with the tool and with the people on this forum. :-)
Don't be so rude Wasakakero, don't forget your avatar is a Dutch guy, haha.


markebrooks.github.io
http://markebrooks.github.io
RSS feed for document changes
en
© Sun Microsystems Inc. 2009
Administrator
Administrator
XWiki Logo
http://markebrooks.github.io
https://markebrooks.github.io/skins/oso/logo.png
-
alansam
https://markebrooks.github.io/bin/view/XWiki/alansam?language=
Version 1.1 edited by on Wed Jan 06 06:44:30 UTC 2010
2010-01-06T06:44:30+00:00
-
khiyama
https://markebrooks.github.io/bin/view/XWiki/khiyama?language=
Version 1.1 edited by on Wed Jan 06 06:21:13 UTC 2010
2010-01-06T06:21:13+00:00
-
mwright
https://markebrooks.github.io/bin/view/XWiki/mwright?language=
Version 1.1 edited by on Wed Jan 06 06:17:56 UTC 2010
2010-01-06T06:17:56+00:00
-
breadson
https://markebrooks.github.io/bin/view/XWiki/breadson?language=
Version 1.2 edited by on Wed Jan 06 06:04:54 UTC 2010
2010-01-06T06:04:54+00:00
-
rizwanln
https://markebrooks.github.io/bin/view/XWiki/rizwanln?language=
Version 1.1 edited by on Wed Jan 06 05:24:40 UTC 2010
2010-01-06T05:24:40+00:00
-
zulfaqar
https://markebrooks.github.io/bin/view/XWiki/zulfaqar?language=
Version 1.1 edited by on Wed Jan 06 05:22:04 UTC 2010
2010-01-06T05:22:04+00:00
-
OSUG Locations
https://markebrooks.github.io/bin/view/Community+Group+advocacy/ug-leaders?language=en
Version 42.1 edited by jimgris on Wed Jan 06 05:21:15 UTC 2010
2010-01-06T05:21:15+00:00
admin
jimgris
-
smunzani
https://markebrooks.github.io/bin/view/XWiki/smunzani?language=
Version 1.1 edited by on Wed Jan 06 05:12:28 UTC 2010
2010-01-06T05:12:28+00:00
-
imai-sun
https://markebrooks.github.io/bin/view/XWiki/imai-sun?language=
Version 1.1 edited by on Wed Jan 06 05:10:11 UTC 2010
2010-01-06T05:10:11+00:00
-
usuke
https://markebrooks.github.io/bin/view/XWiki/usuke?language=
Version 1.1 edited by on Wed Jan 06 05:02:39 UTC 2010
2010-01-06T05:02:39+00:00
-
candy26
https://markebrooks.github.io/bin/view/XWiki/candy26?language=
Version 1.1 edited by on Wed Jan 06 04:45:25 UTC 2010
2010-01-06T04:45:25+00:00
-
cabsun
https://markebrooks.github.io/bin/view/XWiki/cabsun?language=
Version 1.1 edited by on Wed Jan 06 04:41:52 UTC 2010
2010-01-06T04:41:52+00:00
-
designma
https://markebrooks.github.io/bin/view/XWiki/designma?language=
Version 1.1 edited by on Wed Jan 06 04:32:57 UTC 2010
2010-01-06T04:32:57+00:00
-
kevinge
https://markebrooks.github.io/bin/view/XWiki/kevinge?language=
Version 1.1 edited by on Wed Jan 06 04:15:22 UTC 2010
2010-01-06T04:15:22+00:00
-
mc123
https://markebrooks.github.io/bin/view/XWiki/mc123?language=
Version 1.1 edited by on Wed Jan 06 03:19:09 UTC 2010
2010-01-06T03:19:09+00:00
-
newly12
https://markebrooks.github.io/bin/view/XWiki/newly12?language=
Version 1.1 edited by on Wed Jan 06 03:06:59 UTC 2010
2010-01-06T03:06:59+00:00
-
dj928
https://markebrooks.github.io/bin/view/XWiki/dj928?language=
Version 1.1 edited by on Wed Jan 06 02:51:47 UTC 2010
2010-01-06T02:51:47+00:00
-
ada_feng
https://markebrooks.github.io/bin/view/XWiki/ada_feng?language=
Version 1.1 edited by on Wed Jan 06 02:32:42 UTC 2010
2010-01-06T02:32:42+00:00
-
ydzhang
https://markebrooks.github.io/bin/view/XWiki/ydzhang?language=
Version 1.1 edited by on Wed Jan 06 02:09:51 UTC 2010
2010-01-06T02:09:51+00:00


NXT TakeOver: WarGames 2019 results
by WWE.comCheck out full WWE NXT TakeOver: WarGames 2019 results below. Streaming live from Allstate Arena in Chicago, Ill., the WWE Network special event features two WarGames Matches, including a Women’s WarGames Match for the first time ever, as well as Finn Bálor return to NXT action and a match to determine who will challenge NXT Champion Adam Cole at Survivor Series.
First-ever Women’s WarGames Match
Team Ripley (Rhea Ripley, Candice LeRae, Tegan Nox & Dakota Kai) def. Team Baszler (NXT Women’s Champion Shayna Baszler, NXT UK Women’s Champion Kay Lee Ray, Bianca Belair & Io Shirai)
Pre-Show Match
Angel Garza def. Isaiah “Swerve” Scott (RESULTS | PHOTOS)
WarGames Match
Team Ciampa (Tommaso Ciampa, Keith Lee, Dominik Dijakovic & ???) vs. The Undisputed ERA (NXT Champion Adam Cole, NXT North American Champion Roderick Strong & NXT Tag Team Champion Kyle O’Reilly & Bobby Fish)
Matt Riddle vs. Finn Bálor
Triple Threat Match – Winner to challenge NXT Champion Adam Cole at Survivor Series
Pete Dunne vs. Killian Dain vs. Damian Priest


One-hand usage of handheld devices results in poor reachability, re-gripping, occlusion and reduced accuracy. This results in poor user experiences, especially with user interactions that require multi-finger usage. Use of deformation gestures can augment touch gestures to extend the limited functionalities experienced in one-handed usage.
BendSwipe is a combined bend and touch enabled input interaction to perform target zooming on a flexible handheld device. It uses the bend gestures to augment a swipe interaction performed anywhere at the back of the device to perform target zoom-in and out on any area of the display content.
We chose a combination of bend gestures and touch supported swipe gesture on the backside of the flexible handheld device to reduce the problem of occlusion and regripping. We chose a center bend gesture due to its ease of use and intuitiveness identified in the literature. Swiping the index finger in a particular direction while performing the center bend zooms in the direction of swipe.
Zoom-in and out is triggered by performing a bend and swipe gesture simultaneously.The direction of bend (in or out) detrmines the choice between zooming in and out. The direction of swipe determined the direction in which the zooming happens. The zooming is performed for as long the both the gestures are detected.
Bending In the center of the display surface towards the user triggers a navigation wheel that is displayed as an overlay on the center of the flexible device. Performing a swipe gesture in any direction on the rear side triggers a zoom-in in the direction of swipe gesture.
Bending in and swiping in the SE direction for Zoom-In in the same direction.
Bending Out the center of the display away from the user triggers a navigation wheel that is displayed as an overlay on the center of the flexible device. Performing a swipe gesture in any direction triggers a zoom-out in the direction of swipe
Bending out and swiping in the SE direction for Zoom Out in the same direction.
Rear of the handheld prototype [L] and The working prototype [R].
The flexible sheet is made out of thin laminated paper. A bend sensor is located horizontally on the rear side to detect the bending direction. A conductive touch sensor is used to detect the direction of swipe gestures
The 16th IFIP TC.13 International Conference on Human-Computer Interaction, 2017, Mumbai, India [Publication]
The ACM Canadian Celebration of Women in Computing, 2017, Montreal, Canada [Publication]


Currently, Decentralized games can’t meet the needs of developers to do fancy games for commercial needs, because of the higher barrier of technical requirements for different public chains.
Some of the pain points encountered by the developers：
• Difficulty of integrate with chains
• Slow transaction confirmation speed
• High Gas fee
• Small sending and receiving data
• Security verification difficulty
UDAP game engine for decentralized games, that solves the slow, inefficient and high GAS cost issues on Ethereum and other public chains.
• No GAS fee requires during a game, saving cost for players
• Instant confirmation results for multiple parties, that’s the key for all games
• Secured Random Mechanism, the random results can be verified and open sourced
• Built-in common game rules, configuration can be automatically executed
• No registration required, users can play game directly from digital wallets.
• On-chain and off-chain Arbitration system that protect players
• On-chain setting system to withdraw balance to users automatically
• Compatible with popular wallets like MetaMask, ImToken, CoinBase Wallet, Opera, Trust, etc.
• Enable mint or use other tokens
UDGE used the State Channel technology, transfers the unnecessary on-chain transactions to the state channel, verify the validity of transactions through the digital signatures of all parties. If Any party cheats, the other parties can initiate arbitration on-chain and the Arbitration system can ensure the fairness.
Deposit assets before entering the channel
Define the game rule
Provides the contracts for updating channel states
Provides the arbitration for any disputes
State exchange, game rules and signature verification logics.
Maintenance and saving of the status of all parties
Validation of off-chain state validity
Timely updates of the off-chain states
Submit off-chain disputes to on-chain arbitration
Currently, UDGE can be used in fixed number of parties, game rule is clear, more interactions, may requires a secured random mechanism game, like chess, turn-base strategy games, etc. UDGE has been tested and running perfectly on some of the games, and we are looking for more game developer using UDGE to develop more decentralized game and or apps.
Contact us at info@udap.io


Why Cosmiqo?
Cosmiqo helps organizations remove material and process flow inefficiencies through orchestration, optimization and visibility for human loose-picking & robot warehousing.
Challenges
Dead time in operations today means much more than ever, affecting not only your operational excellence but also customer satisfaction and price competitiveness. At the same time, there is more complexity than ever in warehousing, in more places than ever, and everything is a black-box. This is a challenge that legacy solutions aren’t equipped to handle.
Existing software is system-dependent.
There is no flexibility for cross-platform configuration and leads to inefficiency.
Legacy systems that do not adapt to your operations can be very detrimental to your efficiency. Today's data provided tomorrow is not good enough for our fast-paced logistics world.
Greater fulfilment complexity and more inefficiencies are currently being solved by spending increasingly on deficient systems. Fixed capital costs increase duration for ROI significantly.
Want to get more out of your current warehouse assets
but without spending a fortune on changing it?
Opt for a single platform with flexible modules that complements and improves the areas that
you need help with most today.
Optimize assets without constant human intervention with our low-touch
self-learning engines.
Increase productivity of assets rapidly with data analytics and A.I.
Utilize modules individually or have them work together, depending on priorities.
Integrate Cosmiqo into any stack, regardless of system and brand type.
We give you the platform and insights to orchestrate a robot-human operation, accelerating and making it easier for your transition to a automated future. We also optimize present fleets for greater productivity and increase robot ROI, all while ensuring you have complete operational integration across all your automated assets in the warehouses.
Simulate and analyze operations before any physical deployment or execution.
One robot controller to coordinate any type of robot, brand or operations together.
Utilize A.I. to increase
robot productivity for
higher warehouse throughput and quicker robot ROI.
One platform that coordinates human and robot operations together seamlessly.
We ensure that you have complete visibility across all automated assets in the warehouse. Cosmiqo delivers this visibility in real-time, to a granular level or consolidated for your reporting and analytics needs.
Have a complete view of fleet and people performance to execute data-driven operations.
Understand key data points not previously utilized to drive productivity.
Streamline data from different operations
to a centralised platform for analysis.
Orchestration, optimization and visibility is available in every IRIS module for both people and robot-centric operations. Leverage on this cohesive suite for your operating systems today and for the future.
Cosmiqo and our partners provide end-to-end services from system conceptualization to implementation, ensuring these tools maximize your current resources.
Work with us to develop new operations with our tools that allows you to do more than your current state.
Increase in lines per hour
Reduction in labour
Reduction in short pick-list
Increase in jobs completed
Reduction in excess robots acquired
Cost reduction vs traditional plan execution