|
PX4 Firmware
PX4 Autopilot Software http://px4.io
|
#include <sensor_correction.h>
Public Attributes | |
| uint64_t | timestamp |
| float | gyro_offset_0 [3] |
| float | gyro_scale_0 [3] |
| float | gyro_offset_1 [3] |
| float | gyro_scale_1 [3] |
| float | gyro_offset_2 [3] |
| float | gyro_scale_2 [3] |
| float | accel_offset_0 [3] |
| float | accel_scale_0 [3] |
| float | accel_offset_1 [3] |
| float | accel_scale_1 [3] |
| float | accel_offset_2 [3] |
| float | accel_scale_2 [3] |
| float | baro_offset_0 |
| float | baro_scale_0 |
| float | baro_offset_1 |
| float | baro_scale_1 |
| float | baro_offset_2 |
| float | baro_scale_2 |
| uint8_t | selected_gyro_instance |
| uint8_t | selected_accel_instance |
| uint8_t | selected_baro_instance |
| uint8_t | gyro_mapping [3] |
| uint8_t | accel_mapping [3] |
| uint8_t | baro_mapping [3] |
| uint8_t | _padding0 [4] |
Definition at line 51 of file sensor_correction.h.
| uint8_t sensor_correction_s::_padding0[4] |
Definition at line 78 of file sensor_correction.h.
| uint8_t sensor_correction_s::accel_mapping[3] |
Definition at line 76 of file sensor_correction.h.
Referenced by do_accel_calibration(), and sensors::VotedSensorsUpdate::parameters_update().
| float sensor_correction_s::accel_offset_0[3] |
Definition at line 60 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), and read_accelerometer_avg().
| float sensor_correction_s::accel_offset_1[3] |
Definition at line 62 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), and read_accelerometer_avg().
| float sensor_correction_s::accel_offset_2[3] |
Definition at line 64 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), and read_accelerometer_avg().
| float sensor_correction_s::accel_scale_0[3] |
Definition at line 61 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), read_accelerometer_avg(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::accel_scale_1[3] |
Definition at line 63 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), read_accelerometer_avg(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::accel_scale_2[3] |
Definition at line 65 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll(), read_accelerometer_avg(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| uint8_t sensor_correction_s::baro_mapping[3] |
Definition at line 77 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::parameters_update().
| float sensor_correction_s::baro_offset_0 |
Definition at line 66 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll().
| float sensor_correction_s::baro_offset_1 |
Definition at line 68 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll().
| float sensor_correction_s::baro_offset_2 |
Definition at line 70 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll().
| float sensor_correction_s::baro_scale_0 |
Definition at line 67 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::baro_scale_1 |
Definition at line 69 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::baro_scale_2 |
Definition at line 71 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| uint8_t sensor_correction_s::gyro_mapping[3] |
Definition at line 75 of file sensor_correction.h.
Referenced by do_gyro_calibration(), and sensors::VotedSensorsUpdate::parameters_update().
| float sensor_correction_s::gyro_offset_0[3] |
Definition at line 54 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), and sensors::VotedSensorsUpdate::gyro_poll().
| float sensor_correction_s::gyro_offset_1[3] |
Definition at line 56 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), and sensors::VotedSensorsUpdate::gyro_poll().
| float sensor_correction_s::gyro_offset_2[3] |
Definition at line 58 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), and sensors::VotedSensorsUpdate::gyro_poll().
| float sensor_correction_s::gyro_scale_0[3] |
Definition at line 55 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), sensors::VotedSensorsUpdate::gyro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::gyro_scale_1[3] |
Definition at line 57 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), sensors::VotedSensorsUpdate::gyro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| float sensor_correction_s::gyro_scale_2[3] |
Definition at line 59 of file sensor_correction.h.
Referenced by gyro_calibration_worker(), sensors::VotedSensorsUpdate::gyro_poll(), and sensors::VotedSensorsUpdate::VotedSensorsUpdate().
| uint8_t sensor_correction_s::selected_accel_instance |
Definition at line 73 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::accel_poll().
| uint8_t sensor_correction_s::selected_baro_instance |
Definition at line 74 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::baro_poll().
| uint8_t sensor_correction_s::selected_gyro_instance |
Definition at line 72 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::gyro_poll().
| uint64_t sensor_correction_s::timestamp |
Definition at line 53 of file sensor_correction.h.
Referenced by sensors::VotedSensorsUpdate::sensors_poll().


{{ template "header.html" . }}
{{ .Log }}
An attempt has been made to remove sensitive info, but make sure to check yourself.
{{ .SanitizedLog }}


As a member of the Foothills Facility for Remote Sensing and GIScience (F3GISci) research group, I am working on Heat Energy Assessment Technologies (HEAT) — the MIT award winning project from University of Calgary. It has been featured in the Canadian Geographic, CBC, Calgary Herald, and more. My role is prototype and develop user–centric components seen on the project’s web mapping application to increase client engagement and enhance their experience. I am also partly responsible for creating various cartographic products such as digital maps representing waste heat leaving homes, communities, and cities using very high resolution airborne thermal imagery and large–scale GIS datasets.
Additionally, I am an MSc Candidate in the Department of Geography at the University of Calgary with research interests in geospatial technologies such as GIS, remote sensing, and the geospatial web. I believe in buildings tools that can be used for the greater good by citizens. I am motivated by the open data and energy efficiency movement as they have created new opportunities for collaboration and dialogue between people. For my thesis, I am developing a volunteered geographic information (VGI) system as part of the HEAT project to showcase a home’s energy efficiency record over time. With the help of local residents, this VGI system will be used to promote green real–estate and support residential energy efficiency in Calgary.
Some of my contributions to the HEAT project can be seen below.
Cartography isn’t the only domain where I get to showcase my appreciation for aesthetic details. I became involved with visual design such as branding/identity, typography, posters, and other miscellaneous graphics at an early age. As a result, in 2004 I launched XEENAT, which has been my online portfolio featuring selected projects I have worked on for various satisfied clients ranging from non-profit organizations to musicians.
I am fascinated by simplicity of shapes, contrasting and vibrant colour palettes, and sharp angles. With each project, my goal is to ensure balance, harmony, and purity in design to leave a long-lasting effect. All of these qualities lead to simplicity, which is reflected in the work I do and appreciated by my clients. XEENAT is also a medium through which I share self initiated projects that force me to think differently and creatively. Creativity has enhanced my analytical skills by empowering me with the ability to approach each problem differently. This allows me to deliver innovative and cost-effective solutions to real world issues. Moreoever, each personal project provides me with the opportunity to constantly challenge myself in order to produce the highest quality of work, and to keep raising the bar.
Some of my recent work can be seen below.
Two plus years of proficiency with GIS and remote sensing software packages for performing geospatial analyses, managing spatial databases, and producing rich cartographic products with thorough understanding of projections, datums, and transformations.
Extensive experience in working with large-scale spatial datasets including street networks, points of interest, landcover, buildings, ownership parcels, and high-resolution airborne imagery.
Delivering innovative and cost-effective solutions to real world problems with positive results while working in fast paced environments through personal organization, time management skills, and prioritization of tasks.
Strong ability to communicate complex concepts in a simple manner through professional reports and presentations.
Establishing clearly defined goals and roles to ensure high quality of work when working with diverse teams and committees.
I will be completing my MSc in Fall 2014. Currently, I am looking for my next exciting and challenging venture. You can request my full CV or contact me via email if you are interested in working with me.
Sincerely,
Bilal Karim


{{ lower }}-{{ upper }} of {{ content.nbHits }} results for "{{ query }}"
by {{ product.owner.name }}
{{ product.price | currency }}


Bubble
is a simple tooltip based theme. Try double clicking on text, you should see bubble with toolbars for editing.
Quill is a free, open source WYSIWYG editor built for the modern web. With its modular architecture and expressive API, it is completely customizable to fit any need.
// <link href="https://cdn.quilljs.com/1.0.5/quill.snow.css" rel="stylesheet"> // <script src="https://cdn.quilljs.com/1.0.5/quill.min.js" type="text/javascript"></script> var quill = new Quill('#editor', { modules: { toolbar: '#toolbar' }, theme: 'snow' }); // Open your browser's developer console to try out the API!
Built with
Snow is a clean, flat toolbar theme.
Quill is a free, open source WYSIWYG editor built for the modern web. With its modular architecture and expressive API, it is completely customizable to fit any need.
// <link href="https://cdn.quilljs.com/1.0.5/quill.snow.css" rel="stylesheet"> // <script src="https://cdn.quilljs.com/1.0.5/quill.min.js" type="text/javascript"></script> var quill = new Quill('#editor', { modules: { toolbar: '#toolbar' }, theme: 'snow' }); // Open your browser's developer console to try out the API!
Built with
By default all formats are enabled and allowed to exist within a Quill editor and can be configured with the formats
option. This is separate from adding a control in the Toolbar
. For example, you can configure Quill to allow bolded content to be pasted into an editor that has no bold button in the toolbar.
Quill is a free, open source WYSIWYG editor built for the modern web. With its modular architecture and expressive API, it is completely customizable to fit any need.
// <link href="https://cdn.quilljs.com/1.0.5/quill.snow.css" rel="stylesheet"> // <script src="https://cdn.quilljs.com/1.0.5/quill.min.js" type="text/javascript"></script> var quill = new Quill('#editor', { modules: { toolbar: '#toolbar' }, theme: 'snow' }); // Open your browser's developer console to try out the API!
Built with


SITE MAP
News, Reviews, Features, Videos, Photos & Categories Pages
Sections
News
Reviews
Features
Photos
Videos
Gadget Guru
Cell Guru
Category Pages
Mobiles
Tablets
Apps
Social
Telecom
Android-Hub
India-Hub
Home Entertainment
PC/ Laptops
Internet
Microsoft-Hub
360 Daily
Google-Hub
Nokia-Hub
Gaming
Samsung-Hub
Culture
Apple-Hub
Cameras
Science
Entertainment
Wearables
Transportation
Podcasts
BlackBerry-Hub
Others
Sony-Hub
How to
Contests
BlogView
Polls
Hubs
Apple
Android
BlackBerry
Google
Microsoft
Nokia
Samsung
Sony


Second ECOOP WORKSHOP on
MOBILE OBJECT SYSTEMS
(or "Agents on the Move")
Linz, Austria, July 8-9, 1996
Call for Participation
OVERVIEW
A mobile object system is a collection of objects that may move from
one execution environment to another, which may be located on another
machine with a different hardware and software platform, resuming their
computation in this new context.
This workshop deals with design and implementation issues of
programming languages and systems for mobile objects.
TOPIC
The recent interest in software agents --software entities operating on
behalf of some user over a large-scale and heterogeneous network-- has
been a driving factor for the development of a number of new languages
and systems, with the most widely publicized effort being the
Telescript language (General Magic), but some degree of agent support
is present in languages such as Tycoon (Uni Hamburg), Phantom (Trinity
College), Safe-Tcl, M0 (University of Geneva), Facile (ECRC), Joule
(Agorics), Object REXX (IBM), Obliq (Digital) and Java (SUN), and in
system such as MOLE (IVPR, Stuttgart), Ara (Uni Kaiserslautern), Tcl
Agents (Dartmouth) and Map (IMAG Grenoble).
The common characteristic of all of these projects is their emphasis on
mobile computation and remote programming.
The goal of this workshop is to investigate the requirements of mobile
object systems, evaluate how current languages respond to these
requirements and chart new research directions.
Mobile object systems address distributed programming from a different
angle than remote procedure call (RPC) based distributed systems. Where
RPC based systems rely on high-level interfaces to communicate passive
data between remote sites, mobile object systems offer a flexible lower
level interface for the exchange of active programs. Mobile object
system are geared towards distributed computation in very-large,
distributed and heterogeneous computer systems where security and
performance are key concerns.
This workshop will be a forum for discussing implementation and design
issues. A non-exhaustive list of topics include:
- Semantics of mobile object systems
- Linguistic support for mobility
- Portable intermediate representations
- Dynamic compilation vs. interpretation
- Static analysis of mobile object systems
- Resource management
- Code distribution and versioning schemes
- Security considerations
- Experience reports
AUDIENCE
This workshop brings together researchers working on object-oriented
languages and systems that support mobile computation.
The emphasis of the workshop will be on language and system implementation issues rather than on applications of the mobile object
technology.
Workshop attendees are expected to take an active part in the discussions. A position paper will be written to summarize the results of
the workshop.
HOW TO APPLY
Prospective participants should submit a position paper describing
current research in the field (<=10 pages) AND a problem statement
outlining a particular problem to discuss at the workshop (1-2 pages).
Both should be submitted via e-mail to:
<EMAIL_ADDRESS>Submissions should survey technology, or describe original research,
design and development, and/or implementation. Results should be clear
and useful to other practitioners in the field. Description of a new
system should include reproducible, useful results or lessons learned.
Every paper will get at least three reviews. Final papers will follow
the Springer Verlag LNCS format:
(gopher://trick.ntp.springer.de/11/tex/latex/llncs).
Submitted URL's of papers and/or of home pages will be included into
the WWW page of the workshop (URL see below). A selection of the best
papers will be considered for publication by Springer-Verlag.
FORMAT
The workshop will take place in the two days before the conference.
The first day of the workshop will be devoted to presentations of
on-going work and of state of the art systems. Discussions of the
problem topics submitted by the participants will take place on the
second day.
TIMETABLE
- Apr. 29, '96: submission deadline
- May 20, '96: notification of acceptance
- June 30, '96: camera-ready versions of papers
PROGRAM COMMITTEE
- Joachim Baumann, IVPR Stuttgart
- Luca Cardelli, DEC SRC
- Paolo Ciancarini, U. of Bologna
- Doug Lea, SUNY Oswego
- Christian Tschudin, U. of Zurich
- Jan Vitek, U. of Geneva
WORKSHOP URL
http://cuiwww.unige.ch/~ecoopws/ws96/cfp.html
ORGANIZATION
Jan Vitek
University of Geneva, Object Systems Group,
24, rue General-Dufour, CH-1211 Geneve 4, Switzerland
e-mail<EMAIL_ADDRESS>http://cuiwww.unige.ch/~jvitek
Christian Tschudin
Institut f\"ur Informatik, Universit\"at Z\"urich
Winterthurerstr. 190, CH - 8057 Z\"urich, Switzerland
e-mail<EMAIL_ADDRESS>tel/fax: (+41'1) 257'4579/363'0035
Joachim Baumann
Institute of Parallel and Distributed High-Performance Systems (IPVR)
Breitwiesenstr. 20 - 22, D-70565 Stuttgart, Germany
e-mail<EMAIL_ADDRESS>Tel: +49 711 7816 218 Fax: +49 711 7816 424


This is a general-purpose WebSocket implementation extracted from the Faye project. It provides classes for easily building WebSocket servers and clients in Node. It does not provide a server itself, but rather makes it easy to handle WebSocket connections within an existing Node application. It does not provide any abstraction other than the standard WebSocket API.
It also provides an abstraction for handling EventSource connections, which are one-way connections that allow the server to push data to the client. They are based on streaming HTTP responses and can be easier to access via proxies than WebSockets.
$ npm install faye-websocket
You can handle WebSockets on the server side by listening for HTTP Upgrade requests, and creating a new socket for the request. This socket object exposes the usual WebSocket methods for receiving and sending messages. For example this is how you'd implement an echo server:
var WebSocket = require('faye-websocket'),
http = require('http');
var server = http.createServer();
server.on('upgrade', function(request, socket, body) {
if (WebSocket.isWebSocket(request)) {
var ws = new WebSocket(request, socket, body);
ws.on('message', function(event) {
ws.send(event.data);
});
ws.on('close', function(event) {
console.log('close', event.code, event.reason);
ws = null;
});
}
});
server.listen(8000);
WebSocket
objects are also duplex streams, so you could replace the
ws.on('message', ...)
line with:
ws.pipe(ws);
Note that under certain circumstances (notably a draft-76 client connecting
through an HTTP proxy), the WebSocket handshake will not be complete after you
call new WebSocket()
because the server will not have received the entire
handshake from the client yet. In this case, calls to ws.send()
will buffer
the message in memory until the handshake is complete, at which point any
buffered messages will be sent to the client.
If you need to detect when the WebSocket handshake is complete, you can use the
onopen
event.
If the connection's protocol version supports it, you can call ws.ping()
to
send a ping message and wait for the client's response. This method takes a
message string, and an optional callback that fires when a matching pong message
is received. It returns true
if and only if a ping message was sent. If the
client does not support ping/pong, this method sends no data and returns
false
.
ws.ping('Mic check, one, two', function() {
// fires when pong is received
});
The client supports both the plain-text ws
protocol and the encrypted wss
protocol, and has exactly the same interface as a socket you would use in a web
browser. On the wire it identifies itself as hybi-13
.
var WebSocket = require('faye-websocket'),
ws = new WebSocket.Client('ws://www.example.com/');
ws.on('open', function(event) {
console.log('open');
ws.send('Hello, world!');
});
ws.on('message', function(event) {
console.log('message', event.data);
});
ws.on('close', function(event) {
console.log('close', event.code, event.reason);
ws = null;
});
The WebSocket client also lets you inspect the status and headers of the
handshake response via its statusCode
and headers
properties.
To connect via a proxy, set the proxy
option to the HTTP origin of the proxy,
including any authorization information, custom headers and TLS config you
require. Only the origin
setting is required.
var ws = new WebSocket.Client('ws://www.example.com/', [], {
proxy: {
origin<EMAIL_ADDRESS>headers: {'User-Agent': 'node'},
tls: {cert: fs.readFileSync('client.crt')}
}
});
The tls
value is a Node 'TLS options' object that will be passed to
tls.connect()
.
The WebSocket protocol allows peers to select and identify the application protocol to use over the connection. On the client side, you can set which protocols the client accepts by passing a list of protocol names when you construct the socket:
var ws = new WebSocket.Client('ws://www.example.com/', ['irc', 'amqp']);
On the server side, you can likewise pass in the list of protocols the server supports after the other constructor arguments:
var ws = new WebSocket(request, socket, body, ['irc', 'amqp']);
If the client and server agree on a protocol, both the client- and server-side
socket objects expose the selected protocol through the ws.protocol
property.
faye-websocket is based on the
websocket-extensions
framework that allows extensions to be negotiated via the
Sec-WebSocket-Extensions
header. To add extensions to a connection, pass an
array of extensions to the :extensions
option. For example, to add
permessage-deflate:
var deflate = require('permessage-deflate');
var ws = new WebSocket(request, socket, body, [], {extensions: [deflate]});
Both the server- and client-side classes allow an options object to be passed in at initialization time, for example:
var ws = new WebSocket(request, socket, body, protocols, options);
var ws = new WebSocket.Client(url, protocols, options);
protocols
is an array of subprotocols as described above, or null
.
options
is an optional object containing any of these fields:
extensions
- an array of
websocket-extensions
compatible extensions, as described aboveheaders
- an object containing key-value pairs representing HTTP headers to
be sent during the handshake processmaxLength
- the maximum allowed size of incoming message frames, in bytes.
The default value is 2^26 - 1
, or 1 byte short of 64 MiB.ping
- an integer that sets how often the WebSocket should send ping frames,
measured in secondsThe client accepts some additional options:
proxy
- settings for a proxy as described abovetls
- a Node 'TLS options' object containing TLS settings for the origin
server, this will be passed to
tls.connect()
ca
- (legacy) a shorthand for passing {tls: {ca: value}}
Both server- and client-side WebSocket
objects support the following API.
on('open', function(event) {})
fires when the socket connection is
established. Event has no attributes.on('message', function(event) {})
fires when the socket receives a
message. Event has one attribute, data
, which is either a String
(for text frames) or a Buffer
(for binary frames).on('error', function(event) {})
fires when there is a protocol error
due to bad data sent by the other peer. This event is purely informational,
you do not need to implement error recover.on('close', function(event) {})
fires when either the client or the
server closes the connection. Event has two optional attributes, code
and reason
, that expose the status code and message sent by the peer
that closed the connection.send(message)
accepts either a String
or a Buffer
and sends a
text or binary message over the connection to the other peer.ping(message, function() {})
sends a ping frame with an optional
message and fires the callback when a matching pong is received.close(code, reason)
closes the connection, sending the given status
code and reason text, both of which are optional.version
is a string containing the version of the WebSocket
protocol the connection is using.protocol
is a string (which may be empty) identifying the subprotocol
the socket is using.EventSource connections provide a very similar interface, although because they
only allow the server to send data to the client, there is no onmessage
API.
EventSource allows the server to push text messages to the client, where each
message has an optional event-type and ID.
var WebSocket = require('faye-websocket'),
EventSource = WebSocket.EventSource,
http = require('http');
var server = http.createServer();
server.on('request', function(request, response) {
if (EventSource.isEventSource(request)) {
var es = new EventSource(request, response);
console.log('open', es.url, es.lastEventId);
// Periodically send messages
var loop = setInterval(function() { es.send('Hello') }, 1000);
es.on('close', function() {
clearInterval(loop);
es = null;
});
} else {
// Normal HTTP request
response.writeHead(200, {'Content-Type': 'text/plain'});
response.end('Hello');
}
});
server.listen(8000);
The send
method takes two optional parameters, event
and id
. The default
event-type is 'message'
with no ID. For example, to send a notification
event with ID 99
:
es.send('Breaking News!', {event: 'notification', id: '99'});
The EventSource
object exposes the following properties:
url
is a string containing the URL the client used to create the
EventSource.lastEventId
is a string containing the last event ID received by the
client. You can use this when the client reconnects after a dropped connection
to determine which messages need resending.When you initialize an EventSource with new EventSource()
, you can pass
configuration options after the response
parameter. Available options are:
headers
is an object containing custom headers to be set on the
EventSource response.retry
is a number that tells the client how long (in seconds) it
should wait after a dropped connection before attempting to reconnect.ping
is a number that tells the server how often (in seconds) to send
'ping' packets to the client to keep the connection open, to defeat timeouts
set by proxies. The client will ignore these messages.For example, this creates a connection that allows access from any origin, pings every 15 seconds and is retryable every 10 seconds if the connection is broken:
var es = new EventSource(request, response, {
headers: {'Access-Control-Allow-Origin': '*'},
ping: 15,
retry: 10
});
You can send a ping message at any time by calling es.ping()
. Unlike
WebSocket, the client does not send a response to this; it is merely to send
some data over the wire to keep the connection alive.
(The MIT License)
Copyright (c) 2010-2015 James Coglan
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the 'Software'), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


{% include head.html %}
{% include navbar.html %} {% include header.html %} {% include sponsors.html %} {% include videos.html %} {% include agenda.html %} {% include committee.html %} {% include about.html %} {% include sponsorship.html %} {% include footer.html %} {% include js.html %} {% include analytics.html %}


Summary Report
Since your first use of Panoptes, you have accumulated 67 hours of data. From that data, we know you have experienced at least 47 dropped calls. Of these, 27 were due to your signal dropping out. The longest period of time your phone spent without signal was 28 minutes. During periods of no signal, you unsuccessfully attempted to make 3 calls.
From: 25th Nov 2011 18:20:22 GMT+0
To: 25th Nov 2011 18:22:22 GMT+0
Avg. Dropped Calls Per Week
Description


{% extends 'layout.html' %} {% load static %} {% block title %}ARCH hints for {{ problem }}{% endblock %} {% block layout-content %}
{{ problem.description }}
{% if problem.aops_url %} {% endif %}The following hints are available for this problem.
{% for hint in hint_list %}Some of the hints may be pretty oblique or not apply to you. Remember, you can always ask the OTIS Discord or Evan for more personalized help!
{% else %}There aren't any hints here yet. If you've solved this problem, please help future students by adding a hint.
{% endif %}


Language:
Scope:
{{ glossScope.name }}
{{glossScope.name}}
Submit
No Results Found
Make a new entry for "{{lastSearch.term}}"
Tag
Delete
Export


private fun deleteChildFromUi(child: Person): Unit
Updates the UI to delete a child from the Person being edited. Nothing is deleted from the database at this stage.
See Also
addChildToUi


Today's the day! The Cal State Apply priority deadline is tonight, Nov. 30 at 11:59 p.m.
If you need assistance, please call<PHONE_NUMBER> or live chat with a representative here: http://ow.ly/5ogm30gViET .
Doctor of Nursing Practice (DNP) becomes permanent at CSU campuses with passage of AB 422: http://ow.ly/4BF330gQtsh .
There are no more Tweets in this timeline.


this
keyword
articles
understanding-the-this-keyword-in-javascript : toddmotto.com
Tests, closures and arrow functions : glebbahmutov.com
this
keyword in JavaScript will burn you one day.  If Dante Alighieri were alive today, he would put writing object-oriented JavaScript among one of the first levels of Hell for sure.
‘this’ in TypeScript - TypeScript/wiki
code demo
Every new function
defined its own this
value :
function Person() {
// The Person() constructor defines `this` as an instance of itself.
this.age = 0;
this.printAge = function () {
console.log(this.age);
};
setInterval(function growUp() {
// In non-strict mode, the growUp() function defines `this`
// as the global object, which is different from the `this`
// defined by the Person() constructor.
this.age++;
}, 1000);
}
var p = new Person();
p.printAge(); // 0
In ECMAScript 3/5, the this
issue was fixable by assigning the value in this
to a variable that could be closed over.
function Person() {
var that = this;
that.age = 0;
that.printAge = function () {
console.log(this.age);
};
setInterval(function growUp() {
// The callback refers to the `that` variable of which
// the value is the expected object.
that.age++;
}, 1000);
}
var p = new Person();
p.printAge(); // 0 then ++ each second
In ECMAScript 6, an arrow function does not create its own this
, the this
value of the enclosing execution context is used.
function Person(){
this.age = 0;
this.sayAge = function () {
console.log(this.age);
};
setInterval(() => {
this.age++; // |this| properly refers to the person object
}, 1000);
}
var p = new Person();
p.sayAge(); // 0 then ++ each second


This DID method spec conforms to the requirements in the DID specification currently published by the W3C Credentials Community Group. For more information about DIDs and DID method specifications, please see the DID Primer and DID Spec.
This document defines a "peer" DID Method that can be used independent of any central source of truth. The method is intended to be cheap, fast, scalable, and secure. It is suitable for most private relationships between people, organizations, and things. DIDs associated with this method are also promotable to a more public context. That is, blockchains with different DID methods could choose to graft some or all peer DIDs into their namespace(s) with no risk of accidental collision, and no loss of meaning. A particular peer DID would have a recognizable and consistent identity in all of them.
We expect that peer-to-peer relationships in every blockchain ecosystem can benefit by offloading pairwise and n-wise relationships to peer DIDs.
Most introductions to DIDs describe them as identifiers that are rooted in a public source of truth like a blockchain, a database, a distributed filesystem, or similar. This publicness lets arbitrary parties resolve the DIDs to an endpoint and keys. It is an important feature for many use cases.
However, the vast majority of relationships between people, organizations, and things are simpler. When Alice(Corp|Device) and Bob want to interact, there are exactly and only 2 parties in the world who should care: Alice and Bob. We call these parties "peers" because there is an equality rather than a hierarchy to them, at least insofar as their DID management is concerned. Letting the world resolve the identifiers and keys that only peers care about is unnecessary, and it represents a privacy and security risk as well as a problem of cost, scale, and performance.
DIDs are by nature pseudonyms, in the sense that an entity can use a DID as an alias for themselves in some context i.e a relationship. Therefore the different forms of a DID acting as a pseudonym can be defined in three ways.
The omnipresence of peer relationships raises the possibility of DIDs that are only resolvable and usable by peers within the context of a given relationship. Such pairwise or n-wise identifiers can still have all the other characteristics that make DIDs useful -- DID Documents, endpoints, keys, authorizations, interoperability, and tooling.
Terminology note: as used in this spec, "peer DID" means a DID that uses the "did:peer" DID method we're defining. Such DIDs are often pairwise, but "pairwise DID" is not a synonym, since peer DIDs can also be used to model n-wise relationships. Similarly, "peer DID" is not intended to be a synonym for a DID that is not publicly resolvable. Many different approaches to such DIDs might exist; "peer DID" is just the name for the approach described here.
This spec uses a protocol, rather than a public oracle, as the root of trust. It is worthy of trust because it guarantees the following properties:
Peer DIDs are not suitable for anywise use cases, which are usually public by intent. However, peer DIDs have certain virtues that make them desirable for private relationships between a small number of enumerable parties:
Public-ledger-based DIDs (e.g. did:sov:...) could be used, in principle, for pairwise and N-wise. The disadvantage of that is the associated registration and maintenance cost, as the number of pairwise or n-wise relationships is likely to become large, even for small organisations. Also privacy considerations make public-ledger-based DIDs less desirable for pairwise and (small-scale) n-wise.
Similarly, Peer DID (did:peer:...) could be used, hypothetically, for public use. The main disadvantage is the lack of a formal publication mechanism. Whereas nothing refrains a user to publish a Peer DID and its associated DID Document on some website, such publication will be hard to discover, maintain (DID Document roll-over) and integrate into interoperable applications. Public-ledger-based DIDs all have their intrinsic and authoratitive publication mechanism, as identified by its DID method name.
Most of this doc is framed by a pairwise Alice:Bob context. This sort of pair (no matter whether its members are people, IoT devices, or institutions) will be the most common peer relationship in the SSI landscape. Groups larger than 2 can also have a peer-style relationship--but not all groups will be modeled that way. Therefore, applying this method to groups should be done thoughtfully.
Some groups, such as Doctor+Hospital+Patient, are clearly n-wise. Each party can enumerate all the other parties, and each party uses the same identifier in all directions within the group. N-wise groups are peer groups by definition: (see HIPE 0014 for help on the SSI notation used in this diagram).
N-wise groups often exist alongside pairwise relationships. For example, a 3-wise business partnership between Alice, Bob, and Carol is probably preceded by pairwise relationships between each of the parties. When the business is founded, a new 3-wise relationship is created, with the parties allocating new DIDs, keys, and DID Docs to this relationship independent of the ones they use in their pairwise friendships. This keeps business and personal relationships separate. If a new partner is added, the 3-wise relationship can become 4-wise; if a partner dies, the partnership can lose an active participant, but continue to recognize that party in the relationship history. This shows the close affinity but also the separation between pairwise and n-wise. For more details, see this exploratory doc.
Groups can also be modeled with a hub-and-spoke model. That model is commonly used in group chats, for example: each member of the group chat sends and receives via a central service, which in turn broadcasts to all other members of the group. This hub-and-spoke model is actually just a pairwise variant, because the relationship is between a member and the hub; all other relationships are only indirect:
We do not cover hub-and-spoke groups explicitly below. They are compatible with this method, if reanalyzed as pairwise. Otherwise, the protocol may need adaptation.
In centralized systems, security is enforced at the center. This is so obvious that we take it for granted--you can't access a database unless you log in first, and it's the database that enforces this.
Despite their other decentralized features, blockchains are no different in this respect. If a blockchain accepts updates to a DID Doc, then the blockchain must guarantee that those updates are only made by authorized parties. Thus, most DID methods imagine a blockchain parsing the authorization section of a DID Doc, and rejecting mischief from hackers.
However, in a peer relationship, there IS no centralized authority. This leads to an interesting inversion of responsibility that must be understood: Bob enforces Alice's authorization policy, and Alice enforces Bob's.
This might seem wrong--shouldn't Alice enforce her own security? But it is quite rational. Who cares whether the agents he is dealing with truly belong to Alice and are authorized by her? Bob does.  Bob is.
Another way to think about this is that, within the Alice:Bob relationship, Bob acts as a substitute for a centralized resource that Alice's agents try to access. In such a mental model, of course, Bob would be a logical place to enforce access rules for Alice.
The namestring that shall identify this DID method is: peer
A DID that uses this method MUST begin with the following prefix: did:peer
.
Per the DID specification, this string MUST be in lowercase. The remainder of the DID, after the prefix,
is the namespace specific identifier specified below.
Early feedback on this method suggested that we embed it beneath the namespace of a particular blockchain,
as in did:sov:peer
or did:v1:nym
.
However, this DID method is not captive to any particular blockchain, does not take its resolution rules
from a parent method, and does not require anchoring or reference to a blockchain to be valid.
Furthermore, any direct or indirect anchoring of a peer DID to a specific blockchain is driven by
circumstance and changeable at any time. For example, a peer DID could specify that it is using
a dead drop on blockchain 1, then change to blockchain 2, then change to blockchains 3 and 4 at
the same time. Therefore, "peer" belongs at the top of the DID namespace. How this method may be
used in conjunction with various blockchains is discussed later.
This DID method applies to any identity management implementation that meets the following two requirements:
The Peer DID scheme is defined by the following ABNF:
peer-did = "did:peer:" keyfmtchar ":" idstring
keyfmtchar = "1"
idstring = 21*22base58char
base58char = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "A" / "B" / "C"
/ "D" / "E" / "F" / "G" / "H" / "J" / "K" / "L" / "M" / "N" / "P" / "Q"
/ "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c"
/ "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "m" / "n" / "o" / "p"
/ "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z"
All Peer DIDs are base58 encoded values. The underlying number represented in base58 is a cryptographic
public key or a derivative (e.g., hash) thereof. For future extensibility, the scheme includes a key format
character field (keyfmtchar
) that identifies the corresponding idstring
to define
the length of the NSI.
At the time of this writing, only one keyfmtchar
is defined. This is "1", denoting a format
where idstring
is the upper 16 bytes of an Ed25519 public key. This gives idstring
a length of either 21 or 22 base58 characters. The encoding of idstring
uses most alphas and digits,
omitting 0 (zero), O (capital o), I (capital i), and l (lower L) to avoid readability problems. Regardless of
the length of idstring
, peer DIDs are case-sensitive and may not be case-normalized, even though
the prefix is always lower-case.
Note that this spec may be updated to include other keyfmtchar
variants for
SecP256, Curve448, or similar. Such updates might change the length of idstring
as well.
The unique numeric value underlying a Peer DID MUST be generated by using a cryptographically robust
algorithm with secure randomness to create an Ed25519 keypair (or, when additional formats are supported,
an analogous keypair on a different curve), and then selecting as the NSI a subset of the public
verification key that is at least 128 bits, and that is dependent on keyfmtchar
. For
keyfmtchar
= "1", the NSI = the most significant 16 bytes of the public verification key.
In this way, the DID can be known to begin its existence already associated with keys, and the controller of the new DID can immediately assert they are the only entity in the world who possesses the private key. This guarantees the initial integrity of the DID's chain of custody.
A convenient regex to match peer
DIDs is:
^did:peer:1:[1-9A-HJ-NP-Za-km-z]{21,22}$
.
A valid peer
DID might be: did:peer:1:YTEFYzByfU2RwJPyULfLLn
.
We call this the "peer" DID method because it enables peers--parties with no relative hierarchy--to
exchange DIDs without recourse to a central authority. Thus, we expect only one role in our
protocol: peer
. And this is the case, at a high level.
However, at another level of detail, each peer may interact through various pieces of software and hardware that proxy them. They may need to reveal a modest amount of information about such agents to achieve cooperative security. For example, Alice may control 3 devices and may wish to protect herself from hacking by saying that at least 2 of her existing devices must agree before a new device can be added or an existing device can be revoked. This requires her to share her M-of-N policy with Bob, with enough information about agent keys that he can validate a multi-party digital signature. Thus, our protocol must occasionally contemplate details about this more granular level of each peer's sovereign domain.
Peers interact via messages. This is a more general claim than saying that peers expose an API because it doesn't assume that peers are directly callable by each other. It must be possible to exchange DIDs in this method in a very asynchronous fashion (e.g., one party sends a message while the other party is offline; a response is returned when the original sender may not be actively listening).
Message transmission is transport-agnostic. That is, the messages can flow over any combination of HTTP, Bluetooth, NFC, email, AMPRNet (TCP/IP over ham radio), snail mail, sneakernet, intermediaries, or future protocols we have not yet invented.
Messages are JSON. They are compatible with basic concepts of JSON-LD, but no deep knowledge of JSON-LD is required to understand them, and no dependency on JSON-LD libraries is necessary. The specifics of JSON format are discussed below.
Messages are serialized and encrypted in a standard way for transport. This method associates security guarantees with the message envelope rather than the transport, and is aligned philosophically with the approach of IETF's Message Level Security initiative. However, the first version of this spec predates MLS's maturity, so the wire format uses JWEs with some extensions, instead. The extensions allow the same message to be encrypted once for multiple recipients and sent to them all in an efficient manner:
These extensions are under review by the maintainers of JWE/JWT and are likely to be mainstreamed eventually. The particulars are detailed in a doc that explains how agents in the Hyperledger Indy ecosystem have implemented the format - but the format is easy to implement without any Indy dependencies, and its design has no connection to the Indy blockchain. See this implementation in pure javascript, and this one in pure python, in addition to Indy's C-callable implementation in Rust.
All JSON messages in this protocol are part of a "message family" named connections
. This
family is identified by the following DID
reference:
did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0
Of course, subsequent evolutions of the message family will replace `1.0` with an appropriate update per semver rules.
Although the cryptographic operation of creating a peer DID and its first keypair can be done at any time and does not require a message, registering a peer DID with the other party or parties in a relationship involves a specific sequence of messages known as the connection protocol. The protocol is formally documented in a HIPE; only a summary is offered here. It has 3 steps:
These three steps have been carefully defined to achieve a number of important goals:
(This operation, as well as Update and Delete, are documented in greater detail in a HIPE about connection management protocols. Here, we offer only a summary.)
A peer DID can be resolved to a DID Document by sending a state_request message from one peer to another:
{ "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/state_request", "@id": "6a4986dd-f50e-4ed5-a389-718e61517207", "for": "did:peer:rjHiqAzCbsNYhMZDTUASHg", "as_of_time": "2019-07-23 18:05:06.123Z" }
The as_of_time
property is optional and often omitted; if so, the DID Doc at
the current time is returned.
A state_response message is returned. It includes a DID Doc and some additional metadata, and looks like this:
{ "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/relmgmt/1.0/state_response", "@id": "1517207d-f50e-4ed5-a389-6a4986d718e6", "~thread": { "thid": "6a4986dd-f50e-4ed5-a389-718e61517207" }, "for": "did:peer:1:rjHiqAzCbsNYhMZDTUASHg", "did_doc": { "@context": "https://w3id.org/did/v1", "id": "did:peer:1:qQk1twjzCmEMgLDRNmo7oS", "publicKey": [ {"id": "routing", "type": "Ed25519Verkey2018", "owner": "did:peer:1:rjHiqAzCbsNYhMZDTUASHg","publicKey": "4x6qAfCNrqQqEB3nS7Zfu7K8HH5gYEeNc3z7PYXmd54d"}, {"id": "1", "type": "Ed25519Verkey2018", "owner": "did:peer:1:rjHiqAzCbsNYhMZDTUASHg","publicKey": "Ar5P8bBr3vXMguTw3U14S6mN2rxrDsYV8Tt75FZ2ZTu4"} ], "authentication": [ {"type": "Ed25519Verkey2018", "publicKey": "#1"} ], "service": [ {"type": "Agency", "serviceEndpoint": "did:sov:Av1e1Cpu2MavT6QN8nuLJ4" } ] }, "as_of_time": "2019-07-23 18:05:06.123Z" }
Note the use of ~thread
in the response, with thid
equal to the
@id
property of the previous request, to connect the two messages. This is a
standard message threading feature of DID Communication, and also shows up in other
message interactions described here.
The owner of a peer DID can update their associated DID Document with anyone who knows the DID--one or more agents of the peer, or agents of the owner itself--by sending a sync_state message to another peer. An example of this type of message is:
{ "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/relmgmt/1.0/sync_state", "@id": "e61586dd-f50e-4ed5-a389-716a49817207", "for": "did:peer:1:rjHiqAzCbsNYhMZDTUASHg", "base_hash": "d48f058771956a305e12a3b062a3ac81bd8653d7b1a88dd07db8f663f37bf8e0", "base_hash_time": "2019-07-23 18:05:06.123Z", "deltas": [ { "ops": [ { "op": "add_key", "fragment": { "id": "6", "type": "Ed25519Verkey2018", "owner": "did:peer:1:EMmo7oSqQk1twmgLDRNjzC", "publicKey": "DjbU8jgf1MjGWu6hGwr4N4EoAfhfTjutjWc8fgdxb3QP" } }, { "op": "remove_key", "fragment": {"id": "5"} } ], "delta_time": "2019-07:23 19:00:01", "result_hash": "058771956a305e12a3b062a3ac81d48fbd8653d7f663f37bf8e0b1a88dd07db8", "proofs": [ { "by": "#4", "signature": "MIIB6gYJKoZIhvcNAQcCoIIB2zCCAdcCAQE...wYDVQQKEwR" } ] } ] }
This message does not follow a simple request~response pattern, and does not have "update"
in its name, because either party
may know details that the other party lacks. The sender picks a point in time, delta_time
,
where it believes it and the receiver were probably in sync; it then describes the deltas
that it knows about, that have happened since.
If the recipient already has the same state, it replies with an ACK.
If the recipient knew about a subset of the delta, but not all of it, it applies what is left of the delta, and sends an ACK.
If the recipient has a more evolved state, the recipient sends a reply
that is a new sync_state
message informing the sender of hitherto unknown information. As with
the ACKs, this new message is known to be a reply to the original sync_state
because its
~thread
decorator identifies the previous message's @id
as its thid
.
If the recipient does not recognize the base_hash, it selects a hash from a point in time earlier than
base_hash_time
and sends back a new sync_state
message with that earlier base.
If the recipient detects a conflict, it attempts to merge states. If the merge is successful, it sends a
new sync_state
that shows the merge. If the merge is not successful, then a merge
conflict exists, and the merge conflict policy for the sovereign domain of the associated DID is
invoked. See "Merges and Merge Conflicts".
In a self-sovereign paradigm, abandoning a relationship can be done unilaterally, and does not require formal announcement; one party can simply stop communicating with the other. Since there is no public record of the relationship to delete, no further action is strictly required. Indeed, sometimes a formal announcement is impossible, if one of the parties is offline.
However, it is best practice to announce that the relationship is being abandoned. This
should cause the other party to clean up by removing the DID, DID Doc, and associated metadata from its
local cache. It should also prevent the other party from trying to communicate in the future.
Formally terminating a connection happens by sending a
leave
message to a peer:
{ "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connection/1.0/leave", "@id": "c17147d2-ada6-4d3c-a489-dc1e1bf778ab", "~please_ack": {} }
If Bob receives a message like this, he should assume that Alice no longer considers herself connected, and take appropriate action. This could include destroying data about Alice that he has accumulated over the course of their relationship, removing her peer DID and its public key(s) and endpoints from his wallet, and so forth. The nature of the relationship, the need for a historical audit trail, regulatory requirements, and many other factors may influence what's appropriate; the protocol simply requires that the message be understood to have permanent termination semantics.
The
~please_ack
decorator is optional. It asks the receiver to
send an acknowledgement that it has processed the message. If used, the receiver
should send an ACK that looks like this:
{ "@type": "did:sov:BzCbsNYhMrjHiqZDTUASHg;spec/connections/1.0/ack", "@thread": { "thid": "c17147d2-ada6-4d3c-a489-dc1e1bf778ab" } }
All the messages in this protocol (except for a connection invitation that requires no security, by design) must be sent encrypted, using the encryption format specified in DIDComm's wire format. This gives strong guarantees about the confidentiality and integrity of exchanged data, regardless of the transport mechanism used to transmit the messages.
Because peer DIDs are generated from their initial public key, they cannot be created without the creator controlling them. As mentioned earlier, this prevents man-in-the-middle attacks at the time of creation. Since keys must be created from keys generated by a secure random number generator, they are guaranteed to be unpredictable and globally unique at creation time.
The keys authorized to participate in a peer relationship may not all have the same
privileges. All keys have the privilege of rotating themselves. Keys that have the privilege
of adding keys can only add keys with equal or lesser privileges than themselves. All other
authorizations on keys must be specified in the authorization
section of a peer DID doc.
Its structure is:
“authorization”: [ list of grants ]
grant = { "let": recipient , “do”: privs }
recipient block = one of the following:
“key”: keyref, e.g., “#1”
"group":
“and”: [ list of recipient block ]
“or”: [ list of recipient block ]
“m_of_n”: {“m”: number, “n”: [ list of recipient block ]}
privs = a string that enumerates the privileges being granted.
This string is list-like but is not modeled using a JSON list or dict
because of some specialized syntax that conflicts with canonicalization
requirements. Its format is a space-delimited list of privileges in string form, where each
privilege is an op code name. The list must be sorted in ascending
alphabetical order to aid normalization.
 Grants identify the recipient, which is either a key or a combination of keys, and the privileges that the recipient is receiving.
An example might be:
What this says is:
Keys used to control peer DIDs, or keys authorized to communicate and update the DID Docs for peer DIDs, should be managed according to best practices for DKMS, as described in the DKMS spec.
Peer DIDs should remain pairwise or n-wise, not being reused across relationships. This allows proper isolation to defeat correlation. It also enables granular exercise of sovereignty in a robust, multidimensional identity.
Because peer DIDs are guaranteed to be globally unique at the moment of creation, their 128-bit NSI should not exist on any blockchain. Blockchain-based DID methods can register a peer DID Doc using their own method. As the DID value, they can either combine their own method prefix with peer DID's NSI ("did:peer:abc123" --> "did:xyz:abc123"), or they can create a child namespace for peer DIDs beneath their own ("did:peer:abc123" --> did:xyz:peer:abc123").
If a peer DID is registered and grafted into another DID namespace, using either method, the result is two DIDs with different namespaces, one peer and one anchored, each with its own DID Doc. A decision must be made about which DID is normative for the relationship, or whether both should continue to be used. If both will be used, it should be understood that the two DID Docs hold keys and other data for two different DIDs, regardless of the shared history of those DIDs. Ideally, there would be no difference between the DID Docs stored in each place, but even with the best intentions of the DID controller, differences may arise.
One reason why this grafting and cross-registering feature is interesting is that peer DIDs could be supported by existing DID tools (e.g., the universal resolver) that require a blockchain, without any retooling.
The wire format for DID Communication encryption has three independent implementations--one in libindy, one in python with no Indy dependencies, and one in javascript with no Indy dependencies.
The connection protocol that creates and registers peer DIDs, including support for DID resolution after forming a connection, has been fully implemented by half a dozen different organizations, as of March 2019. One of these organizations did not use libindy. The connection management protocols that allow update of DIDs are in various states of implementation. An up-to-date summary of implementation status, including links to the implementations, can be found in the indy-agent repo on github.
There is a formal test suite for the protocols as well, in the same github repo.
Developers maintaining this spec and its reference implementations are often found on RocketChat at chat.hyperledger.org, #indy, #indy-sdk, and #aries. You might also connect with them via the Hyperledger Indy mailing list at<EMAIL_ADDRESS>the Hyperledger Aries mailing list at<EMAIL_ADDRESS>in Hyperledger and W3C working groups, or at the semi-annual Internet Identity Workshop conferences.


RiceBook
RiceBook
Register Form
Account name:
Display name (Optional):
Email address:
Phone number: (like<PHONE_NUMBER>)
Date of birth:
Zip code:
Password:
Password confirmation:
Register
Login Form
Account name:
Password:
Remember me
Login


--- layout: base --- {% include post.html post=page link_title=false %} {% include about.html %} {% include related.html post=page %}


Catalog Builder
Before getting started, make sure you:
- Are using a new Interaction Studio dataset
- Have read the user guide on how to use this tool. You can find it here.
- Have created the relevant Dimensions within your demo dataset
- Have mapped the Dimensions against the relevant catalog type within your demo dataset
- Have downloaded the Product Catalog template and guide from here
- Read the frequently asked questions.


Open your browser's debug console and play around with turing()
turing()
The $t() alias is also available.
$t()


Shenmue 3 bell tower puzzle – where to find the tokens and complete the puzzle
by Kirk McKeandStruggling to complete the Shenmue 3 bell tower puzzle? Come here and we’ll sort you out.
At one point during Shenmue 3’s story you have to speak to Elder Yeh about the Verdant Bridge. During the conversation, she tells you must find six tokens in her house and climb the bell tower. Here’s what you need to do.
First, the locations of those tokens:
- The first token is in a sliding cabinet opposite where Elder Yeh sits.
- Behind that is a shelf that you need to push. Focus on it with L2 and push it.
- It will open up a gap where you need to push another piece of furniture.
- Before you go through that gap, go into the right corner and open a sliding cupboard door there on the right for another token.
- Now head through the gap and open the glass fronted cabinet immediately on your right for a token.
- To the left of that, third drawer down, is the next token.
- Two cabinets to the left of that is another token in the small drawer on the left.
- There’s one in the sliding door to the left of that as well.
Now you’ll go to bed. In the morning, head to the bell tower. You can’t go back once you do this, so finish up everything you need to do in Bailu Village first.
In the bell tower there are symbols on the pillars. You need to put the token in each that means the opposite of what you see.
The shield needs a sword, the sun needs a moon, the steamed buns need some wine, the open palm needs a fist, the Phoenix needs a dragon, and the turtle needs the crane.
When you get upstairs, focus with L2 and look at each of the symbols. This triggers a cutscene.
Now you must turn the centerpiece.
The sequence you need to turn is, if you’re using a PS4 controller, Circle, Circle, Circle, Square, Square, Square, Circle Circle. That’s left, left, left, right, right, right, left, left.
Games featured in this article


We would love for you to contribute to SVOGV and help make it ever better! As a contributor, here are the guidelines we would like you to follow:
In case of any questions please contact me at
Help us keep Angular open and inclusive. Please read and follow our Code of Conduct.
If you have questions about how to use SVOGV, please direct them to the Google Group discussion list or StackOverflow. Please note that SVOGV is still in very early development, and the team's capacity to answer usage questions is limited. Community chat is also available on Gitter.
If you find a bug in the source code or a mistake in the documentation, you can help us by submitting an issue to our GitHub Repository. Including an issue reproduction (via CodePen, JsBin, Plunkr, etc.) is the absolute best way to help the team quickly diagnose the problem. Screenshots are also helpful.
You can help the team even more and submit a Pull Request with a fix.
You can request a new feature by submitting an issue to our GitHub Repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first, to be sure that we can use it. SVOGV is in very early stages and we are not ready to accept major contributions ahead of the full release. Please consider what kind of change it is:
Before you submit an issue, search the archive, maybe your question was already answered.
If your issue appears to be a bug, and hasn't been reported, open a new issue. Help us to maximize the effort we can spend fixing issues and adding new features by not reporting duplicate issues. Providing the following information will increase the chances of your issue being dealt with quickly:
You can file new issues by providing the above information here.
Before you submit your Pull Request (PR) consider the following guidelines:
Make your changes in a new git branch:
git checkout -b my-fix-branch master
Create your patch, including appropriate test cases.
 Adherence to these conventions is necessary because release notes are automatically generated from these messages.
git commit -a
Note: the optional commit -a
command line option will automatically "add" and "rm" edited files.
Push your branch to GitHub:
git push my-fork my-fix-branch
In GitHub, send a pull request to svogv:master
.
If we suggest changes then:
Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
git rebase master -i
git push -f
That's it! Thank you for your contribution!
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:
Delete the remote branch on GitHub either through the GitHub web UI or your local shell as follows:
git push my-fork --delete my-fix-branch
Check out the master branch:
git checkout master -f
Delete the local branch:
git branch -D my-fix-branch
Update your master with the latest upstream version:
git pull --ff upstream master
To ensure consistency throughout the source code, keep these rules in mind as you are working:
We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the SVOGV change log.
Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
The header is mandatory and the scope of the header is optional.
Any line of the commit message cannot be longer 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.
If the commit reverts a previous commit, it should begin with revert:
, followed by the header of
the reverted commit. In the body it should say: This reverts commit <hash>.
, where the hash is
the SHA of the commit being reverted.
Must be one of the following:
(example scopes: gulp, broccoli, npm)
src
or test
filesThe scope could be anything specifying place of the commit change. For example
datepicker
, dialog
, etc.
The subject contains succinct description of the change:
Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.
The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.
Breaking Changes should start with the word BREAKING CHANGE:
with a space or two newlines.
The rest of the commit message is then used for this.
A detailed explanation can be found in this document.
Please sign our Contributor License Agreement (CLA) before sending pull requests. For any code changes to be accepted, the CLA must be signed. It's a quick process, we promise!


Cookie Sales Table
City
Minimum Customers In Any Given Hour
Maximum Customers In Any Given Hour
Average Cookies Sold Per Customer
Home


| New York, US | Seoul, Korea | Tokyo, Japan | Beijing, China |
|---|---|---|---|
| Milan, Italy | Singapore, Singapore | London, UK | Bangkok, Thailand |
| Amsterdam, Netherlands | Dubai, UAE | Istanbul, Turkey | Paris, France |
| Madrid, Spain | Taipei, Taiwan | Auckland, NewZealand | Vienna, Austria |
| Prague, Czech | Kuala Lumpur, Malaysia | Lagos Nigeria | |


?6
7
8
9
10
„
The
New
York
copyright
reserved
botanical
Garden
New
York
Botanical
Garden
lblflTS?
7
DISTRIBUTED
BY
THE
FIELD
COLUMBIAN
MUSEUM.
PLANTS
OF
THE
WEST
INDIES.
COLLECTED
BY
H.
A.
VAN
HERMANN.
Erythrina
glauca
Willd,
^
40
*
<£To
loovnv^
i/.
livunuvV'OnmtMiA/.
<0
Oi
PROVINCE
OF
PINAR
DEL
RIO:
?Vlavc*,,190fi1
CUBA
Det.
by
B.A.Krukoff,
1938.
1618957
Legend -
Level of confidence that token is an accurately-transcribed word
extremely low
very low
low
undetermined
medium
high
very high


Siberian Koryak Use Description: --from Disembodied Eyes
'Other subjects became very jolly or sad, jumped about, danced, sang or gave way to great fright. Their pupils were enlarged. Lewin believed this was responsible for the distortions in size which occurred. Small objects appeared much too large.
In large quantities more severe hallucinations and rages occurred. The initial excitation could become more and more severe leading to attacks of raving madness. In some cases motor excitation was dominant. The eyes became savage, the face bloated and red, the hands trembled and the individual danced or rushed about until exhausted when he apparently slept. But he then experienced more hallucinations. This could then be replaced by another spasm of overactivity followed by more hallucinations and fantasy.'
Hallucinari's Effects Description: --from http://www.heureka.fi/i/Illuusiot/hallu/apt.e.html
'The extract of Amanita muscaria is intoxicating and results in a depressed state (a stupor), with concomitant sleep, hallucinations, delirium, and muscle spasms. Stupor may be followed by behavioral excitment accompanied by visual and auditory hallucinations and distortions of sensory input.'
MycoFAQ's Amanita Muscaria Effects Description:
'Symptoms appear within 30 minute to 2 hours after ingestion, and last for several hours. Nausea and vomiting are quite common, but the principle effects are on the central nervous system: confusion, visual distortion, a feeling of greater strength, delusions and convulsions. Drowsiness is a common symptom and many who ingest these mushrooms fall asleep and can not be roused. This facet of the syndrome can be particularly frightening for the attending physician, as most cases involve patients who arrive in this apparently comatose state. The resulting panicked reaction and overtreatment, generally produces no benefit to the patient.
Treatment is largely supportive -- reassuring the patient that the effects are only temporary. Recovery is normally sponanteous.'
Johnathan Ott Effects Description: --from Jonathan Ott in Psychedelics Encyclopedia
'After oral ingestion, the full effects will begin in about 90 minutes. For me, these are characterized by wavy motion in the visual field, an 'alive' quality to inanimate objects, auditory hallucinations and a sense of great mental stillness and clarity. The effects are distinctly different from psilocybin, LSD, or mescaline, and may last up to eight hours. Side effects often include nausea, slight loss of balance and coordination and drowsiness. Smoking produces a more rapid effect of shorter duration.'
J. Doe's Effects Summary:
'[I was] relaxed but not tired, flushed face, slight motor impairment no logic impairment, able to play logic games competitvely, easy to move into unsolicited conversation weirdness, seemed like stuff was moving, effects lasted 6-7 hours, no hangover, sleep came easily, pulverized in gel caps with milk thistle.
[my companion was comfortably sleepy], a bit hotter than usual, no adverse effects.'
Petri's Experience Summary:
'sleepy, nausea, no color patterns or visuals, internal visualizations, confusing, sometimes scarey, 'lost in a parking lot', euphoric, aphrodisiac, funny'
--- B's Experience Summary:
1/3+ of a 4 1/2 ' cap, nausea, body proportion change, body euphoria, motor impairment, desire for linear conversation diminished, mental 'discomfort', 'deliriogen', vomiting, lasted 3 hours, approach with respect and caution.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


MUSIC MAN
December 2009
Director – Juna Broome
Assistant Director – Dr. Bill Myers
Musical Director – Nikki Johnson
Choreographer – Alisha Powell
THE CAST
Harold Hill - Gerald Wansely
Marcellus Washburn - Wesley Slade
Tommy Djilas / Salesman #5 - Scotty Whitehurst
Mayor Shinn / Newspaper Man #3 - Kenny James
Constable Locke / Farmer Soloist / Newspaper Man # 1 - Brent Holifield
Charlie Cowel - Weslie Guthrie
Jacey Squires - Mike Travis
Ewart Dunlop / Salesman # 3 - Steffan Myers
Oliver Hix & News Paper Man # 4- Roger Kuyrkendall
Olin Britt & Salesman # 4 – Jackie Thomas
Salesman #2 / Man #2 - Dustin Adcock
Salesman #1 / Wells Fargo Soloist - Zadrian Cooley
Newspaper #2 / Wells Fargo Soloist / Man # 1 - David Ruffin
Boy - Allen Giovengo
Conductor - Tod Lightsey
Winthrop - Dagan White, Wade Parker
Marian Paroo - Holly McCann
Mrs. Paroo - Alice Miller
Eulalie Shinn - Marian Latimer
Gracie Shinn - Gracie Travis
Lacie Shinn - Amelia Sisk
Tracie Shinn - Mary Caroline Rogers
Maud Dunlop - Cynthia Welborn
Ethel Toffelmier - Jennifer Rogers
Alma Hicks– Teresa Raybourn
Mrs. Squires- Laurie Hodge
Farmer's Wife / Wells Fargo Soloist– Mariah Vaicicnas
Woman #1 - Sarah Robinson
Woman #2 - Kathryn Walters
Woman #3 - Becky Thomas
Amaryllis – Landra Gavin, Alden Swindle
Zaneeta - Keely Parker
Wells Fargo Soloists
Lydia Myers, Scarlett Sandifer, Kayla Shelby, Danielle Nichols,
Kalee Phillips
Ballet Duet
Lindsay Middleton & Megan Ruffin (choreography by Kristen Jones)
River City Townspeople
Mariah Vaicicnas, David Ruffin, Wesley Guthrie, Megan Ruffin,
Zadrian Cooley, Dustin Adcock, Brent Holifield, Kayla Creel,
Theresa Phillips, Becky Thomas, Kathryn Walters, Heather Patterson,
Haley Beasley, Laurie Hodge
River City Kids Band
Kaitlin Evans, Kaylb Sims, Wade Parker, Dagan White, Eli White,
Cooper White, Alden Swindle, Landra Gavin, Lydia Myers,
Scarlett Sandifer, Kayla Shelby, Danielle Nichols, Maddy Woodrow,
Skylar Smith, McKade Walters, Kaylee Phillips, Isabella Harrison,
Allen Giovengo, Mary Caroline Rogers, Landri Warren, Gracie Tavis,
Amelia Sisk, Angel Welch, Katelynn Perry, Anna Kelpey, Abbie Thrash,
Brooke Patterson, Brinna Moss, Cambri Smith, Samantha Grafton,
RJ Hughes


401 error - invalid token
The verification token you sent doesn't match the one in the database.
If you recently changed devices, you need to copy your old meta.json file into the leaderboard add-on folder of your new device.
If you need help, please contact me via Reddit or send an email to leaderboard_support@protonmail.com.


Showing from
{{ pagestart }}
to
{{ pageend }}
{{ filtered-text }}
in pages of
10
20
30
50
100
entries
Previous
Next
select all
unselect all
{{ title }}
Download dataset as:


Located on the south west corner of the island, about 8nm south of Fort-de-France.
Position 14°29′26″N, 61°04′50″W.
Les Anses d'Arlet : ©patrickk
See the main Noonsite/Martinique/Formalities page for full details.
Clearance can be made using the terminal at the internet cafe on the front in the bay marked Petite Anse D’Arlet. Their opening hours may be irregular.
Last updated October 2015.
There are two bays here. Both are anchorages and both have a pier where it is possible to land with a dinghy.
Last updated March 2016.


HDIM¶
Iterative Solvers¶
Iterative solve the following problem, \(\hat{\beta} = \underset{ \beta \in \mathbb{R}^p }{\mathrm{argmin}} ||Y - X \beta||_2^2 + \lambda || \beta ||_1\)
For a given design matrix X, a vector of predictors Y and vector \(\beta\).
-
hdim.
ISTA
(X, Y, Beta_0, convergence_criteria, Lambda, L_0=0.1, use_screening_rules=True)[source]¶ Use the Iterative Shrinkage Thresholding Algorithm ( ISTA ) to iteratively solve the LASSO.
- Args:
X: An n x p 2D array representing the design matrix.
Y: A 1 x p 1D array representing the predictors
Beta_0: A 1 x p 1D array describing initial condition for Beta. convergence_criteria: Can be either an positive integer descrbing the number if iterations that the solve should be run for, or a positive float describing the smallest allowable Duality Gap.
Lambda: Regularization hyper-parameter for the LASSO ( e.g. Lambda x || Beta ||_1 )
L_0: Learning rate used by the backtracking line search.
use_screening_rules: Enable or disable GAPSAFE screening rules. Enabling these rules MAY speed up the algorithm.
- Returns:
- numpy array containing the coefficients of Beta after the specified convergence criteria has been meet.
- Raises:
- ValueError: Raised if convergence_criteria is neither a positive integer or a positive float.
-
hdim.
FISTA
(X, Y, Beta_0, convergence_criteria, Lambda, L_0=0.1, use_screening_rules=True)[source]¶ Use the Fast Iterative Shrinkage Thresholding Algorithm ( FISTA ) to iteratively solve the LASSO.
- Args:
X: An n x p 2D array representing the design matrix.
Y: A 1 x p 1D array representing the predictors
Beta_0: A 1 x p 1D array describing initial condition for Beta.
convergence_criteria: Can be either an positive integer descrbing the number if iterations that the solve should be run for, or a positive float describing the smallest allowable Duality Gap.
Lambda: Regularization hyper-parameter for the LASSO ( e.g. Lambda x || Beta ||_1 )
L_0: Learning rate used by the backtracking line search.
use_screening_rules: Enable or disable GAPSAFE screening rules. Enabling these rules MAY speed up the algorithm.
- Returns:
- numpy array containing the coefficients of Beta after the specified convergence criteria has been meet.
- Raises:
- ValueError: Raised if convergence_criteria is neither a positive integer or a positive float.
-
hdim.
CoordinateDescent
(X, Y, Beta_0, Lambda, convergence_criteria, use_screening_rules=True)[source]¶ Use Coordinate Descent to iteratively solve the LASSO.
Generally performs better than sub-gradient descent methods such as ISTA or FISTA.
- Args:
X: An n x p 2D array representing the design matrix.
Y: A 1 x p 1D array representing the predictors
Beta_0: A 1 x p 1D array describing initial condition for Beta.
convergence_criteria: Can be either an positive integer descrbing the number if iterations that the solve should be run for, or a positive float describing the smallest allowable Duality Gap.
Lambda: Regularization hyper-parameter for the LASSO ( e.g. Lambda x || Beta ||_1 ) use_screening_rules: Enable or disable GAPSAFE screening rules. Enabling these rules MAY speed up the algorithm.
- Returns:
- numpy array containing the coefficients of Beta after the specified convergence criteria has been meet.
- Raises:
- ValueError: Raised if convergence_criteria is neither a positive integer or a positive float.
Variable Selection & Support Estimation¶
Use the LASSO objective function to estimate signifigant, non-zero enteries in a L1 regularized regression.
-
hdim.
FOS
(X, Y, Beta_0, solver=4, screening_rules=True)[source]¶ Use the Fast and Optimal Support ( FOS ) method to estimate the support for a given LASSO problem.
- Args:
X: An n x p 2D array representing the design matrix.
Y: A 1 x p 1D array representing the predictors
Beta_0: A 1 x p 1D array describing initial condition for Beta.
solver: The type of iterative solver used internally. Can used sub-gradient descent methods or coordinate descent, both of which can use GAPSAFE screening rules or not.
- Returns:
- numpy array containing the estimated support and intercept term.


To award points to everyone who submitted before a specific date, fill out this form
{% call forms.render_form(form, action_text='Award Points') %} {{ forms.render_field(form.kind) }} {{ forms.render_field(form.score) }} {{ forms.render_field(form.message) }} {{ forms.render_field(form.deadline, class_="form-control datetime-picker") }} {{ forms.render_checkbox_field(form.include_backups) }} {{ forms.render_checkbox_field(form.grade_backups) }} {% endcall %}


What is the difference between em and rem units?
Answer
Both em and rem units are based on the font-size CSS property. The only
difference is where they inherit their values from.
em units inherit their value from the font-size of the parent element
rem units inherit their value from the font-size of the root element
(html)
In most browsers, the font-size of the root element is set to 16px by
default.
Good to hear
Benefits of using em and rem units
Additional links
CSS units for font-size: px | em | rem


Jiangren CMS
Home
CMS
Glorious Content
Content is shared across the world. We are open.
Default
Nathan
Arthur
Kevin
Miley
阎潇洋Shuai
Lucine
Ula
Katie
Simon
Davis
Default


In an RDBMS datastore each class is represented as a Table (maybe shared with other classes). Each field/property of the class is represented as a JavaTypeMapping (see classes under org.datanucleus.store.rdbms.mapping.java). Each JavaTypeMapping has [0-N] DatastoreMapping(s) (see classes under org.datanucleus.store.rdbms.mapping.column).


Launch Google Colab¶
When you launch a Google Colab notebook, much of the software we will use in class is already installed. It is not always the latest version of the software, however. In fact, as of early January 2021, Colab is running Python 3.6, whereas you will run Python 3.8 on your machine through your Anaconda installation. Nonetheless, all of the analyses we do for this class will work just fine in Colab.
Because the notebooks in Colab have software preinstalled, and no more, you will often need to install software before you can run the rest of the code in a notebook. To enable this, when necessary, in the first code cell of each notebook in this class, we will have the following code (or a variant thereof depending on what is needed or if the default installations of Colab change). Running this code will not affect running your notebook on your local machine; the same notebook will work on your local machine or on Colab.
# Colab setup ------------------
%%capture
import os, sys
if "google.colab" in sys.modules:
!pip install pyTEMlib
# ------------------------------
In addition to installing the necessary software on a Colab instance, we also have to have access to the data we want to analyse. We expect these data to be on your google drive. You will have to follow the directions to give permission to the notebook to access these data.
# Google Drive setup -----------
if "google.colab" in sys.modules:
from google.colab import drive
drive.mount("/content/drive")
# ------------------------------
When running on your local machine, the path to the data can be chosen without restrictions.
Collaborating with Colab¶
If you want to collaborate with another student or with the course staff on a notebook, you can click “Share” on the top right corner of the Colab window and choose with whom and how (the defaults are fine) you want to share.