The source code you typed in the editor window is send to the C++ Insights server. At the server your source code is temporarily stored just to compile it, after that the source code on the server is deleted and the result is sent back to your browser.
Web logs
C++ Insights keeps web logs to be able to track down issues with the website. These logs are kept for a short period, after which they are permanently deleted.
Cookies & Local Storage
C++ Insights uses small pieces of information stored on your computer: Cookies and Local Storage. These help to restore your source code the next time you visit C++ Insights. It also keeps the C++ Standard you have selected. This information is stored on your computer. Only during the translation it is temporarily transferred to the C++ Insights server.
They are only used with the user's permission. See the Cookie Policy for more information.
Short Links
A user can decide to create a short link using the C++ Insights web-interface. The code as well as a time stamp and all compiler/insights options are stored in a database together with the short link id. You have no guarantees, that the links will be kept forever.
C++ Insights and the GDPR
Name and Address of the controller
The Controller for the purposes of the General Data Protection Regulation (GDPR), other data protection laws applicable in member states of the European Union and other provisions related to data protection is:
Andreas Fertig, andy at cppinsights.io


div with a paragraph within it
blck div 1 blck div 2 blck div 3 blck div 4
paragraph1
paragraph2
paragraph3
paragraph4
paragraph5
paragraph6


Enter an array of positive integers, which correspond to IDs.
Enter an array of positive integers, which correspond to values.
Enter an array of positive integers [0,3], which correspond to types.


Cache web pages
- C
- N
- U
- W
| [RW] | enabled | Enable/disable caching |
| [RW] | directory | Set the directory to use for caching |
| [RW] | uri_translator | Set to a proc that given an URI, translates it to a file system name default is to MD5 the URL |
Source: show
# File lib/scrapes/cache.rb, line 46 def initialize @directory = File.expand_path('cache') @enabled = false @uri_translator = nil end
Checks the cache to see if there is a match for the given URI
Source: show
# File lib/scrapes/cache.rb, line 63 def check (uri) return nil unless @enabled # FIXME check some time limits around this cache_name = translate_uri(uri) file = File.join(@directory, cache_name) File.exist?(file) and File.open(file) do |f| return OpenStruct.new(:body => f.read, :cache_file => file) end end
Updates the cache by placing the data for the give URI on the file system.
Source: show
# File lib/scrapes/cache.rb, line 77 def update (uri, data) return nil unless @enabled cache_name = translate_uri(uri) mkdir # FIXME include cache_name to build all necessary directories File.open(File.join(@directory, cache_name), 'w') do |f| f << data end end
helper method to translate a URL to a MD5
Source: show
# File lib/scrapes/cache.rb, line 90 def uri_to_md5 (uri) Digest::MD5.hexdigest(uri.to_s) end
Disables caching while the given block is active.
Source: show
# File lib/scrapes/cache.rb, line 54 def without_cache state = @enabled @enabled = false yield if block_given? @enabled = state end


when you work with us you're part of the committed collaborators. All aspects of our software
development
process are intergrated, interactive
and agile.
Our approch unifies design, development and product management to create exception.
We start each project by understanding your business goals, the user needs and product
requirements.
Then we help translate them into effective and elegant solutions.
Before we can a contract or write a line of code our team will spend the necesssary time needed to
understand your product vision
The outcome of this scoping session is a proposal or high-level statement of work.
based on your requirements, we can provide a complete offering or just the pieces you need.
Our design practice offers a full range of services
including brand strategy, interaction and visual design
and user experience testing.
Throughout your project, our designers create
and implement visual design and workflows, solicit user
feedback and work with you to make sure what gets built
is what is needed.
All engineers are fluent in the latest enterprise, mobile
and web development technologies.
They collaborate with your team to write, and improve
code on a daily basis, using proven practices such as
test-driven development and pair programming.
Planning and development is iterative. Because we are
constantly coding and testing, the products we build are
always ready to go live.
This iterative process allows for changes as business
requirements evolve.


It is a long established fact that a
reader will be distracted by the readable content of a page
when looking at its layout. The point of using Lorem Ipsum is
that it has a more-or-less normal distribution of letters,
02/3
02/3
2019
TRENDS
FURNITURE
It is a long established fact that a
reader will be distracted by the readable content of a page
when looking at its layout. The point of using Lorem Ipsum is
that it has a more-or-less normal distribution of letters,
02/3
02/3
2019
TRENDS
FURNITURE
It is a long established fact that a
reader will be distracted by the readable content of a page
when looking at its layout. The point of using Lorem Ipsum is
that it has a more-or-less normal distribution of letters,
page when looking at its layout. The point of using
Lorem Ipsum is that it has a more-or-less normal distribution o
NEW DESIGN
Testi Monial
Helina
It is a long established fact that a reader
will be distracted by the readable content of a page when looking
at its layout. The point of using Lorem Ipsum is that it has a
more-or-less normal distribution of letters, as opposed to using
'Content here, content here', making it look
Testi Monial
Helina
It is a long established fact that a reader
will be distracted by the readable content of a page when looking
at its layout. The point of using Lorem Ipsum is that it has a
more-or-less normal distribution of letters, as opposed to using
'Content here, content here', making it look
Testi Monial
Helina
It is a long established fact that a reader
will be distracted by the readable content of a page when looking
at its layout. The point of using Lorem Ipsum is that it has a
more-or-less normal distribution of letters, as opposed to using
'Content here, content here', making it look


An hybrid image creation tool. Read more about the optical illusion and implemention here.
Created by @charliecm


Generate a link that will redirect to your whatsapp number. Only works on mobile.
Phone number (+6 not required):
Text:
Link:
Test: Click here


Toggle navigation
MedImage Server
Privacy and Security Information
Purchase Unlimited Transfers
MedImage Website
Documentation
Technical Documentation
FAQ
AJ Service Status
Settings


Failures are indicated by adding a class="failure"
attribute to the element,
and replacing the contents with a
and
elements containing the expected value and the actual value respectively.
The output of running this:

ABB

Looks like this:

 _ ABB == false _

Note: The underscores indicate line continuations for readability only. They are not output. In reality, it is all in one long line.


Hello fellow reader, good to see you actually care about the world. Nice Job👌(got em!!)
Now that we have established the fact that you actually care about the world. Let me tell you about of website from which you can learn how to help in preventing the Climate Change.
The first website I am going to tell you about is Curbed. Curbed tells you about things you can do in your day-to-day lifestyle that can help in figthing climate change.
The second website is Reset. Reset is another website that tells you about things that you can implement in your life that can help in figthing climate change.
Since Climate Change is such a big topic, there are many websites on the interent that can tell how to do your part in saving the world. But these were just some of the websites that we liked. Hope you like these as well!


| %T>% {magrittr} | R Documentation |
Pipe a value forward into a function- or call expression and return the original value instead of the result. This is useful when an expression is used for its side-effect, say plotting or printing.
lhs %T>% rhs
lhs |
A value or the magrittr placeholder. |
rhs |
A function call using the magrittr semantics. |
The tee pipe works like %>%
, except the
return value is lhs
itself, and not the result of rhs
function/expression.
rnorm(200) %>% matrix(ncol = 2) %T>% plot %>% # plot usually does not return anything. colSums


Co Galway punter wins over €6,000 from €7.50 horse racing bet
The anonymous punter placed the €0.25 each-way Lucky 15 bet in a BoyleSports shop
by Robert HynesA lucky Co Galway punter is over €6,000 richer today after seeing all four of his selections win on Tuesday.
The anonymous punter placed the €0.25 each-way Lucky 15 bet in a BoyleSports shop selecting three horses at Kempton and one at Fairyhouse, investing a total stake of €7.50.
The first winner came at Fairyhouse with The Chapel Field winning the 3.05 race at a handsome price of 10/1 to get the wager off to a flying start.
The customer then secured a fantastic treble across the pond at Kempton with All Yours (8/1), Pianissimo (20/1) and Ginger Fox (8/1) all obliging at healthy odds meaning the Galway punter could start celebrating.
When all the results where known, the client exchanged their €7.50 bet slip for the tasty amount of €6,677.26, a windfall that took just over an hour to win.

"We wish them happy spending and hope they enjoy the festive season with their winnings.”
If you haven't already, be sure to like our Irish Mirror Sport and Irish Mirror GAA pages on Facebook and follow us on Twitter.
How to follow the Irish Mirror on social media
You can like our main Facebook page here.
Our Irish Mirror Sports page - which brings you all your Irish and UK sports news - can be found here.
You can also check out our Irish Mirror GAA sports page.
The Irish Mirror Twitter account is @IrishMirror while our sports account is @MirrorSportIE.
Our Instagram account can be found here.


All The Best Reactions To The My Chemical Romance Australian Tour
by Joseph EarpBy now, the unbelievable news has probably sunk in: My Chemical Romance are coming to Australia, somehow.
After all, when the news of the reunion first broke, it wasn’t even clear that My Chemical Romance were going to play more than a handful of American shows, let alone that they would be coming down to Australia.
Related
Sometimes these reunions can be a one and done kind of thing — a flash in the pan that is squeezed in around often confused and hectic schedules. Think of the few Eddy Current Suppression Ring gigs that have been dropped since that band officially broke up.
But nup, looks like the emo legends are really committing to this thing. They’ll be playing two headlining gigs at Download Festival, before moving on to New Zealand with old friends Jimmy Eat World.
And nobody can really deal.
In fact, in the hours since the announcement first dropped, the internet has been a mess of emotional, overwhelmed emo fans trying to process a range of complicated feelings.
Particularly difficult for fans to process is the limited number of dates that the band are playing down here. There will be no Download sideshows — you’ve gotta catch them at a festival, or not at all.
Which is kinda tricky for most dyed-in-the-wool emo fans, who are now feeling old, and uncool, and thoroughly unprepared for standing in the hot sun and drinking overpriced beer.
Of course, there’s still the hope that all of this will result in new music for My Chemical Romance.
The fact that the band are going on something of an international tour means that they’ll be spending a lot of time with one another once again, playing the songs that made them famous. Surely at some point in that process you start thinking, ‘Hey, let’s get a coupla new bangers out’, right?
Right?


Suspect sought in Punta Gorda vehicle burglaries
by WFTX Digital TeamPUNTA GORDA, Fla. -- Police have released a surveillance image of a suspect in several vehicle burglaries in Punta Gorda.
According to Punta Gorda Police, somebody illegally entered several vehicles on West Henry Street and stole several items.
It happened in the early morning hours of October 29th.
If you have any information on this incident, please contact Southwest Florida Crime Stoppers at 1-800-780-TIPS, by visiting www.southwestfloridacrimestoppers.com , or through the P3 Tips mobile app.
You could be eligible for a cash reward for information leading to an arrest.


Our team is passionate about AI and Human progress, we firmly believe that combining communities with technology is the best way to catalyze change to make the world a better place.
© Copyright 2018. All Rights Reserved.


WITNESS LIST Appropriations-S/C on Health & Human Services Committee February 12, 2003-8:00A Budget For: Bower, Bruce P. (Texas Senior Advocacy Coalition) Cummings, Bill (Texas Silver-Haired Legislature) Dannenbaum, James D. (Texas Cancer Council) Higgins, Carlos (Texas Silver-Haired Legislature) Ingram, Danny (American Cancer Society) On: Jacobs, Mickey (Texas Cancer Council) Jessee, Gary (Department on Aging) Oliver, Thomas E. (Department on Aging) Sapp, Mary (Department on Aging) Spencer, M.D., Donald C. (Texas Cancer Council) Thompson, Jerry (Corporation for National and Community Service)


Dynamo Core is an open source code project
for beginners as well as experienced programmers meant to pick up as
well as cultivate interest in computers and its many major roles
played in present times.
This platform provides a variety of features for related parties
which facilitates interaction between contemporary thinkers with
contemporary times so as to be kept well informed in a fast paced
world.
SEMINAR
Dynamo Core provide means to commence meetings for seminars and
conferences to talk and discuss with different people on
contemporary ideas and tech the world is developing. we can also
share our current works and some information on different works or
researches worked on
Articles
Articles of the contemporary discoveries and thoughts which
decides the path taken in future or the updates on tech or gizmos
which could make one have a head start in their professional lives
or have secure knowledge of one’s personal life’s privacy and
security.
Programming-Lang-Guide
A look into the workings of software/program languages, on the
basic but essential knowledge which one should know so as to enter
the world of data and applications on which we are deliberately
dependent upon in our day to day lives as ones sees through
software like google maps, notes, calendar etc.


The image above depicts the Sun, and the stars that constitute the 3
star system Alpha Centauri: Alpha Centauri A, Alpha Centauri B,
and Proxima Centauri. The Alpha Centauri is the closest star system
to our solar system.
| Name | Status |
|---|---|
| Alpha Centauri A | Star |
| Alpha Centauri B | Star |
| Proxima Centauri | Dwarf Star |


Materialize provides a toast implementation that will be automatically placed and sized according to the device's screen resolution. Toasts are programmatically triggered using the service MzToastService
and can be customized through the parameters of the method show
.
Basic toast using a custom message with a 4000 ms delay
Toasts can be customized by providing a class name to the MzToastService
You can pass an HTML string as the first argument as well as shown in this example where we pass in text a flat button. If you call an external function instead of in-line JavaScript, you will not need to escape quotation marks.
You can tell the toast to execute a callback function when it has been dismissed
To trigger a toast you must use the service MzToastService
and invoke show
method with the desired parameters. A common example is to add the click event to a button to trigger the toast as shown below.
example.component.html
example.component.ts
Toasts can be customized using the following parameters on the method show
of the service ToastService
.
show(message: string, displayLength: number, className?: string, completeCallback?: Function): void
| {{ property.name }} | {{ property.type }} |


| ICNRG | M. Mosko |
| Internet-Draft | PARC, Inc. |
| Intended status: Experimental | I. Solis |
| Expires: September 14, 2017 | |
| C. Wood | |
| University of California Irvine | |
| March 13, 2017 |
CCNx Messages in TLV Format
draft-irtf-icnrg-ccnxmessages-latest
This document specifies version "1" of CCNx message TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the CCNx Semantics specification.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 14, 2017.
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
This document specifies a Type-Length-Value (TLV) packet format and the TLV type and value encodings for CCNx messages. A full description of the CCNx network protocol, providing an encoding-free description of CCNx messages and message elements, may be found in [CCNSemantics]. Several additional protocols specified in their own documents are in use that extend this specification.
This document specifies:
This document is supplemented by this document:
The type values in Section 4 represent the values in common usage today. These values may change pending IANA assignments. All type values are relative to their parent containers. It is possible for a TLV to redefine a type value defined by its parent. For example, each level of a nested TLV structure might define a "type = 1" with a completely different meaning.
Packets are represented as 32-bit wide words using ASCII art. Due to the nested levels of TLV encoding and the presence of optional fields and variable sizes, there is no concise way to represent all possibilities. We use the convention that ASCII art fields enclosed by vertical bars "|" represent exact bit widths. Fields with a forward slash "/" are variable bit widths, which we typically pad out to word alignment for picture readability.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
We use 16-bit Type and 16-bit Length fields to encode TLV based packets. This provides 64K different possible types and value field lengths of up to 64KiB. With 64K possible types, there should be sufficient space for basic protocol types, while also allowing ample room for experimentation, application use, and growth.
Specifically, the TLV types in the range 0x1000 - 0x1FFF are reserved for experimental use. These type values are reserved in all TLV container contexts. In the event that more space is needed, either for types or for length, a new version of the protocol would be needed. See Section 3.3.2 for more information about organization specific TLVs.
| Abbrev | Name | Description |
|---|---|---|
| T_ORG | Vendor Specific Information [vendor] | Information specific to a vendor implementation (see below). |
| n/a | Experimental | Experimental use. |
1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Type | Length | +---------------+---------------+---------------+---------------+
The Length field contains the length of the Value field in octets. It does not include the length of the Type and Length fields. They length MAY be zero.
TLV structures are nestable, allowing the Value field of one TLV structure to contain additional TLV structures. The enclosing TLV structure is called the container of the enclosed TLV.
Type values are context-dependent. Within a TLV container, one may re-use previous type values for new context-dependent purposes.
Each packet includes the 8 byte fixed header described below, followed by a set of TLV fields. These fields are optional hop-by-hop headers and the Packet Payload.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PacketType | PacketLength | +---------------+---------------+---------------+---------------+ | PacketType specific fields | HeaderLength | +---------------+---------------+---------------+---------------+ / Optional Hop-by-hop header TLVs / +---------------+---------------+---------------+---------------+ / PacketPayload TLVs / +---------------+---------------+---------------+---------------+
The packet payload is a TLV encoding of the CCNx message, followed by optional Validation TLVs.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | CCNx Message TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationAlgorithm TLV / +---------------+---------------+---------------+---------------+ / Optional CCNx ValidationPayload TLV (ValidationAlg required) / +---------------+---------------+---------------+---------------+
This document describes the Version "1" TLV encoding.
After discarding the fixed and hop-by-hop headers the remaining PacketPayload should be a valid protocol message. Therefore, the PacketPayload always begins with a 4 byte TLV defining the protocol message (whether it is an Interest, Content Object, or other message type) and its total length. The embedding of a self-sufficient protocol data unit inside the fixed and hop-by-hop headers allows a network stack to discard the headers and operate only on the embedded message.
The range of bytes protected by the Validation includes the CCNx Message and the ValidationAlgorithm.
The ContentObjectHash begins with the CCNx Message and ends at the tail of the packet.
CCNx messages begin with an 8 byte fixed header (non-TLV format). The HeaderLength field represents the combined length of the Fixed and Hop-by-hop headers. The PacketLength field represents the entire Packet length.
A specific PacketType may assign meaning to the "PacketType specific fields".
The PacketPayload of a CCNx packet is the protocol message itself. The Content Object Hash is computed over the PacketPayload only, excluding the fixed and hop-by-hop headers as those might change from hop to hop. Signed information or Similarity Hashes should not include any of the fixed or hop-by-hop headers. The PacketPayload should be self-sufficient in the event that the fixed and hop-by-hop headers are removed.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PacketType | PacketLength | +---------------+---------------+---------------+---------------+ | PacketType specific fields | HeaderLength | +---------------+---------------+---------------+---------------+
The PacketType field indicates how the forwarder should process the packet. A Request Packet (Interest) has PacketType PT_INTEREST, a Response (Content Object) has PacketType PT_CONTENT, and an InterestReturn Packet has PacketType PT_RETURN.
HeaderLength is the number of octets from the start of the packet (Version) to the end of the hop-by-hop headers. PacketLength is the number of octets from the start of the packet to the end of the packet.
The PacketType specific fields are reserved bits whose use depends on the PacketType. They are used for network-level signaling.
If the PacketType in the Fixed Header is PT_INTEREST, it indicates that the PacketPayload should be processed as an Interest message. For this type of packet, the Fixed Header includes a field for a HopLimit as well as Reserved and Flags fields. The Reserved field MUST be set to 0 in an Interest - this field will be set to a return code in the case of an Interest Return. There are currently no Flags defined, so this field MUST be set to 0.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PT_INTEREST | PacketLength | +---------------+---------------+---------------+---------------+ | HopLimit | Reserved | Flags | HeaderLength | +---------------+---------------+---------------+---------------+
For an Interest message, the HopLimit is a counter that is decremented with each hop. It limits the distance an Interest may travel on the network. The node originating the Interest MAY put in any value - up to the maximum of 255. Each node that receives an Interest with a HopLimit decrements the value upon reception. If the value is 0 after the decrement, the Interest MUST NOT be forwarded off the node.
It is an error to receive an Interest with a 0 hop-limit from a remote node.
If the PacketType in the Fixed Header is PT_CONTENT, it indicates that the PacketPayload should be processed as a Content Object message. A Content Object defines a Flags field, however there are currently no flags defined, so the Flags field must be set to 0.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PT_CONTENT | PacketLength | +---------------+---------------+---------------+---------------+ | Reserved | Flags | HeaderLength | +---------------+---------------+---------------+---------------+
If the PacketType in the Fixed Header is PT_RETURN, it indicates that the PacketPayload should be processed as a returned Interest message. The only difference between this InterestReturn message and the original Interest is that the PacketType is changed to PT_RETURN and a ReturnCode is is put into the Reserved octet. All other fields are unchanged. The purpose of this encoding is to prevent packet length changes so no additional bytes are needed to return an Interest to the previous hop. See [CCNSemantics] for a protocol description of this packet type.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | Version | PT_RETURN | PacketLength | +---------------+---------------+---------------+---------------+ | HopLimit | ReturnCode | Flags | HeaderLength | +---------------+---------------+---------------+---------------+
This is the original Interest's HopLimit, as received. It is the value before being decremented at the current node (i.e. the received value).
These are the original Flags as set in the Interest.
The numeric value assigned to the return types is defined below. This value is set by the node creating the Interest Return.
A return code of "0" MUST NOT be used, as it indicates that the returning system did not modify the Return Code field.
| Type | Return Type |
|---|---|
| T_RETURN_NO_ROUTE | No Route |
| T_RETURN_LIMIT_EXCEEDED | Hop Limit Exceeded |
| T_RETURN_NO_RESOURCES | No Resources |
| T_RETURN_PATH_ERROR | Path Error |
| T_RETURN_PROHIBITED | Prohibited |
| T_RETURN_CONGESTED | Congested |
| T_RETURN_MTU_TOO_LARGE | MTU too large |
| T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Unsupported ContentObjectHashRestriction |
| T_RETURN_MALFORMED_INTEREST | Malformed Interest |
This section defines global formats that may be nested within other TLVs.
The pad type may be used by protocols that prefer word-aligned data. The size of the word may be defined by the protocol. Padding 4-byte words, for example, would use a 1-byte, 2-byte, and 3-byte Length. Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length.
A pad MAY be inserted after any TLV in the CCNx Message or in the Validation Dependent Data In the remainder of this document, we will not show optional pad TLVs.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_PAD | Length | +---------------+---------------+---------------+---------------+ / variable length pad MUST be zeros / +---------------+---------------+---------------+---------------+
Organization specific TLVs MUST use the T_ORG type. The Length field is the length of the organization specific information plus 3. The Value begins with the 3 byte organization number derived from the last three digits of the IANA Private Enterprise Numbers [EpriseNumbers], followed by the organization specific information.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_ORG | Length (3+value length) | +---------------+---------------+---------------+---------------+ | PEN[0] | PEN[1] | PEN[2] | / +---------------+---------------+---------------+ + / Vendor Specific Value / +---------------+---------------+---------------+---------------+
Hash values are used in several fields throughout a packet. This TLV encoding is commonly embedded inside those fields to specify the specific hash function used and it's value. Note that the reserved TLV types are also reserved here for user-defined experimental functions.
The LENGTH field of the hash value MUST be less than or equal to the hash function length. If the LENGTH is less than the full length, it is taken as the left LENGTH bytes of the hash function output. Only the specified truncations are allowed.
This nested format is used because it allows binary comparison of hash values for certain fields without a router needing to understand a new hash function. For example, the KeyIdRestriction is bit-wise compared between an Interest's KeyIdRestriction field and a ContentObject's KeyId field. This format means the outer field values do not change with differing hash functions so a router can still identify those fields and do a binary comparison of the hash TLV without need to understand the specific hash used. An alternative approach, such as using T_KEYID_SHA512-256, would require each router keep an up-to-date parser and supporting user-defined hash functions here would explode the parsing state-space.
A CCN entity MUST support the hash type T_SHA-256. An entity MAY support the remaining hash types.
| Abbrev | Lengths (octets) |
|---|---|
| T_SHA-256 | 32 |
| T_SHA-512 | 64, 32 |
| n/a | Experimental TLV types |
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_FOO | 36 | +---------------+---------------+---------------+---------------+ | T_SHA512 | 32 | +---------------+---------------+---------------+---------------+ / 32-byte hash value / +---------------+---------------+---------------+---------------+
Example nesting inside type T_FOO
A Link is the tuple: {Name, [KeyIdRestr], [ContentObjectHashRestr]}. It is a general encoding that is used in both the payload of a Content Object with PayloadType = "Link" and in the KeyLink field in a KeyLocator.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ / Mandatory CCNx Name / +---------------+---------------+-------------------------------+ / Optional KeyIdRestriction / +---------------------------------------------------------------+ / Optional ContentObjectHashRestriction / +---------------------------------------------------------------+
Hop-by-hop TLV headers are unordered and meaning MUST NOT be attached to their ordering. Three hop-by-hop headers are described in this document:
| Abbrev | Name | Description |
|---|---|---|
| T_INTLIFE | Interest Lifetime [Lifetime] | The time an Interest should stay pending at an intermediate node. |
| T_CACHETIME | Recommended Cache Time [RCT] | The Recommended Cache Time for Content Objects. |
| T_MSGHASH | Message Hash [MH] | The hash of the CCNx Message to end of packet using Section 3.3.3 format. |
Additional hop-by-hop headers are defined in higher level specifications such as the fragmentation specification.
The Interest Lifetime is the time that an Interest should stay pending at an intermediate node. It is expressed in milliseconds as an unsigned, network byte order integer.
A value of 0 (encoded as 1 byte %x00) indicates the Interest does not elicit a Content Object response. It should still be forwarded, but no reply is expected.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_INTLIFE | Length | +---------------+---------------+---------------+---------------+ / / / Lifetime (length octets) / / / +---------------+---------------+---------------+---------------+
The Recommended Cache Time (RCT) is a measure of the useful lifetime of a Content Object as assigned by a content producer or upstream node. It serves as a guideline to the Content Store cache in determining how long to keep the Content Object. It is a recommendation only and may be ignored by the cache. This is in contrast to the ExpiryTime (described in Section <IP_ADDRESS>.2)which takes precedence over the RCT and must be obeyed.
Because the Recommended Cache Time is an optional hop-by-hop header and not a part of the signed message, a content producer may re-issue a previously signed Content Object with an updated RCT without needing to re-sign the message. There is little ill effect from an attacker changing the RCT as the RCT serves as a guideline only.
The Recommended Cache Time (a millisecond timestamp) is a network byte ordered unsigned integer of the number of milliseconds since the epoch in UTC of when the payload expires. It is a 64-bit field.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_CACHETIME | 8 | +---------------+---------------+---------------+---------------+ / / / Recommended Cache Time / / / +---------------+---------------+---------------+---------------+
Within a trusted domain, an operator may calculate the message hash at a border device and insert that value into the hop-by-hop headers of a message. An egress device should remove the value. This permits intermediate devices within that trusted domain to match against a ContentObjectHashRestriction without calculating it at every hop.
The message hash is a cryptographic hash from the start of the CCNx Message to the end of the packet. It is used to match against the ContentObjectHashRestriction [COH]. The Message Hash may be of longer length than an Interest's restriction, in which case the device should use the left bytes of the Message Hash to check against the Interest's value.
The Message Hash may only carry one hash type and there may only be one Message Hash header.
The Message Hash header is unprotected, so this header is only of practical use within a trusted domain, such as an operator's autonomous system.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_MSGHASH | (length + 4) | +---------------+---------------+---------------+---------------+ | (hash type) | length | +---------------+---------------+---------------+---------------+ / hash value / +---------------+---------------+---------------+---------------+
Message Hash Header
The top-level TLV types listed below exist at the outermost level of a CCNx protocol message.
| Abbrev | Name | Description |
|---|---|---|
| T_INTEREST | Interest [CCNMessage] | An Interest MessageType. |
| T_OBJECT | Content Object [CCNMessage] | A Content Object MessageType |
| T_VALIDATION_ALG | Validation Algorithm [ValAlg] | The method of message verification such as Message Integrity Check (MIC), a Message Authentication Code (MAC), or a cryptographic signature. |
| T_VALIDATION_PAYLOAD | Validation Payload [ValPayload] | The validation output, such as the CRC32C code or the RSA signature. |
This is the format for the CCNx protocol message itself. The CCNx message is the portion of the packet between the hop-by-hop headers and the Validation TLVs. The figure below is an expansion of the "CCNx Message TLV" depicted in the beginning of Section 3. The CCNx message begins with MessageType and runs through the optional Payload. The same general format is used for both Interest and Content Object messages which are differentiated by the MessageType field. The first enclosed TLV of a CCNx Message is always the Name TLV. This is followed by an optional Message TLVs and an optional Payload TLV.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | MessageType | MessageLength | +---------------+---------------+---------------+---------------+ | Name TLV (Type = T_NAME) | +---------------+---------------+---------------+---------------+ / Optional Message TLVs (Various Types) / +---------------+---------------+---------------+---------------+ / Optional Payload TLV (Type = T_PAYLOAD) / +---------------+---------------+---------------+---------------+
| Abbrev | Name | Description |
|---|---|---|
| T_NAME | Name [names] | The CCNx Name requested in an Interest or published in a Content Object. |
| T_PAYLOAD | Payload [content] | The message payload. |
A Name is a TLV encoded sequence of segments. The table below lists the type values appropriate for these Name segments. A Name MUST NOT include PAD TLVs.
As described in CCNx Semantics [CCNSemantics], using the CCNx URI [CCNxURI] notation, a T_NAME with 0 length corresponds to ccnx:/ (the default route) and is distinct from a name with one zero length segment, such as ccnx:/NAME=. In the TLV encoding, ccnx:/ corresponds to T_NAME with 0 length, while ccnx:/NAME= corresponds to T_NAME with 4 length and T_NAMESEGMENT with 0 length.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_NAME | Length | +---------------+---------------+---------------+---------------+ / Name segment TLVs / +---------------+---------------+---------------+---------------+
| Symbolic Name | Name | Description |
|---|---|---|
| T_NAMESEGMENT | Name segment [name_segment] | A generic name Segment. |
| T_IPID | Interest Payload ID [name_ipid] | An identifier that represents the Interest Payload field. As an example, the Payload ID might be a hash of the Interest Payload. This provides a way to differentiate between Interests based on their payloads without having to parse all the bytes of the payload itself; instead using only this Payload ID Name segment. |
| T_APP:00 - T_APP:4096 | Application Components [name_segment] | Application-specific payload in a name segment. An application may apply its own semantics to the 4096 reserved types. |
4096 special application payload name segments are allocated. These have application semantics applied to them. A good convention is to put the application's identity in the name prior to using these name segments.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | (T_NAME) | %x14 (20) | +---------------+---------------+---------------+---------------+ | (T_NAME_SEGMENT) | %x03 (3) | +---------------+---------------+---------------+---------------+ | f o o |(T_NAME_SEGMENT) +---------------+---------------+---------------+---------------+ | | %x03 (3) | b | +---------------+---------------+---------------+---------------+ | a r | (T_NAME_SEGMENT) | +---------------+---------------+---------------+---------------+ | %x02 (2) | h | i | +---------------+---------------+---------------+---------------+
For example, a name like "ccnx:/foo/bar/hi" would be encoded as:
The InterestPayloadID is a name segment created by the origin of an Interest to represent the Interest Payload. This allows the proper multiplexing of Interests based on their name if they have different payloads. A common representation is to use a hash of the Interest Payload as the InterestPayloadID.
As part of the TLV 'value', the InterestPayloadID contains a one identifier of method used to create the InterestPayloadID followed by a variable length octet string. An implementation is not required to implement any of the methods to receive an Interest; the InterestPayloadID may be treated only as an opaque octet string for purposes of multiplexing Interests with different payloads. Only a device creating an InterestPayloadID name segment or a device verifying such a segment need to implement the algorithms.
It uses the Section 3.3.3 encoding of hash values.
In normal operations, we recommend displaying the InterestPayloadID as an opaque octet string in a CCNx URI, as this is the common denominator for implementation parsing.
The InterestPayloadID, even if it is a hash, should not convey any security context. If a system requires confirmation that a specific entity created the InterestPayload, it should use a cryptographic signature on the Interest via the ValidationAlgorithm and ValidationPayload or use its own methods inside the Interest Payload.
Each message type (Interest or Content Object) is associated with a set of optional Message TLVs. Additional specification documents may extend the types associated with each.
There are two Message TLVs currently associated with an Interest message: the KeyIdRestriction selector and the ContentObjectHashRestr selector are used to narrow the universe of acceptable Content Objects that would satisfy the Interest.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | MessageType | MessageLength | +---------------+---------------+---------------+---------------+ | Name TLV | +---------------+---------------+---------------+---------------+ / Optional KeyIdRestriction TLV / +---------------------------------------------------------------+ / Optional ContentObjectHashRestriction TLV / +---------------------------------------------------------------+
| Abbrev | Name | Description |
|---|---|---|
| T_KEYIDRESTR | KeyIdRestriction [KeyIdRes] | A Section 3.3.3 representation of the KeyId |
| T_OBJHASHRESTR | ContentObjectHashRestriction [COH] | A Section 3.3.3 representation of the hash of the specific Content Object that would satisfy the Interest. |
An Interest MAY include a KeyIdRestriction selector. This ensures that only Content Objects with matching KeyIds will satisfy the Interest. See Section <IP_ADDRESS>.4.1 for the format of a KeyId.
An Interest MAY contain a ContentObjectHashRestriction selector. This is the hash of the Content Object - the self-certifying name restriction that must be verified in the network, if an Interest carried this restriction. It is calculated from the beginning of the CCNx Message to the end of the packet. The LENGTH MUST be from one of the allowed values for that hash (see Section 3.3.3).
The ContentObjectHashRestriction SHOULD be of type T_SHA-256 and of length 32 bytes.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_OBJHASHRESTR | LENGTH+4 | +---------------+---------------+---------------+---------------+ | <hash type> | LENGTH | +---------------+---------------+---------------+---------------+ / LENGTH octets of hash / +---------------+---------------+---------------+---------------+
The following message TLVs are currently defined for Content Objects: PayloadType (optional) and ExpiryTime (optional).
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | MessageType | MessageLength | +---------------+---------------+---------------+---------------+ | Name TLV | +---------------+---------------+---------------+---------------+ / Optional PayloadType TLV / +---------------------------------------------------------------+ / Optional ExpiryTime TLV / +---------------------------------------------------------------+
| Abbrev | Name | Description |
|---|---|---|
| T_PAYLDTYPE | PayloadType [payload_type] | Indicates the type of Payload contents. |
| T_EXPIRY | ExpiryTime [expiry] | The time at which the Payload expires, as expressed in the number of milliseconds since the epoch in UTC. If missing, Content Object may be used as long as desired. |
The PayloadType is a network byte order integer representing the general type of the Payload TLV. Link [Link]. If this field is missing, a "Data" type is assumed.
The Data type indicate that the Payload of the ContentObject is opaque application bytes. The Key type indicates that the Payload is a DER encoded public key. The Link type indicates that the Payload is one or more
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_PAYLDTYPE | Length | +---------------+---------------+---------------+---------------+ | PayloadType / +---------------+
The ExpiryTime is the time at which the Payload expires, as expressed by a timestamp containing the number of milliseconds since the epoch in UTC. It is a network byte order unsigned integer in a 64-bit field. A cache or end system should not respond with a Content Object past its ExpiryTime. Routers forwarding a Content Object do not need to check the ExpiryTime. If the ExpiryTime field is missing, the Content Object has no expressed expiration and a cache or end system may use the Content Object for as long as desired.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_EXPIRY | 8 | +---------------+---------------+---------------+---------------+ / ExpiryTime / / / +---------------+---------------+---------------+---------------+
The Payload TLV contains the content of the packet. It MAY be of zero length. If a packet does not have any payload, this field MAY be omitted, rather than carrying a zero length.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_PAYLOAD | Length | +---------------+---------------+---------------+---------------+ / Payload Contents / +---------------+---------------+---------------+---------------+
Both Interests and Content Objects have the option to include information about how to validate the CCNx message. This information is contained in two TLVs: the ValidationAlgorithm TLV and the ValidationPayload TLV. The ValidationAlgorithm TLV specifies the mechanism to be used to verify the CCNx message. Examples include verification with a Message Integrity Check (MIC), a Message Authentication Code (MAC), or a cryptographic signature. The ValidationPayload TLV contains the validation output, such as the CRC32C code or the RSA signature.
An Interest would most likely only use a MIC type of validation - a crc, checksum, or digest.
The ValidationAlgorithm is a set of nested TLVs containing all of the information needed to verify the message. The outermost container has type = T_VALIDATION_ALG. The first nested TLV defines the specific type of validation to be performed on the message. The type is identified with the "ValidationType" as shown in the figure below and elaborated in the table below. Nested within that container are the TLVs for any ValidationType dependent data, for example a Key Id, Key Locator etc.
Complete examples of several types may be found in Section <IP_ADDRESS>.5
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_VALIDATION_ALG | ValidationAlgLength | +---------------+---------------+---------------+---------------+ | ValidationType | Length | +---------------+---------------+---------------+---------------+ / ValidationType dependent data / +---------------+---------------+---------------+---------------+
| Abbrev | Name | Description |
|---|---|---|
| T_CRC32C | CRC32C [MIC] | Castagnoli CRC32 (iSCSI, ext4, etc.), with normal form polynomial 0x1EDC6F41. |
| T_HMAC-SHA256 | HMAC-SHA256 [MAC] | HMAC (RFC 2104) using SHA256 hash. |
| T_RSA-SHA256 | RSA-SHA256 [signature_val] | RSA public key signature using SHA256 digest. |
| EC-SECP-256K1 | SECP-256K1 [signature_val] | Elliptic Curve signature with SECP-256K1 parameters (see [ECC]). |
| EC-SECP-384R1 | SECP-384R1 [signature_val] | Elliptic Curve signature with SECP-384R1 parameters (see [ECC]). |
MICs do not require additional data in order to perform the verification. An example is CRC32C that has a "0" length value.
MACs are useful for communication between two trusting parties who have already shared private keys. Examples include an RSA signature of a SHA256 digest or others. They rely on a KeyId. Some MACs might use more than a KeyId, but those would be defined in the future.
Signature type Validators specify a digest mechanism and a signing algorithm to verify the message. Examples include RSA signature og a SHA256 digest, an Elliptic Curve signature with SECP-256K1 parameters, etc. These Validators require a KeyId and a mechanism for locating the publishers public key (a KeyLocator) - optionally a PublicKey or Certificate or KeyLink.
Different Validation Algorithms require access to different pieces of data contained in the ValidationAlgorithm TLV. As described above, Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names all play a role in different Validation Algorithms. Any number of Validation Dependent Data containers can be present in a Validation Algorithm TLV.
Following is a table of CCNx ValidationType dependent data types:
| Abbrev | Name | Description |
|---|---|---|
| T_KEYID | SignerKeyId [KeyId] | An identifier of the shared secret or public key associated with a MAC or Signature. |
| T_PUBLICKEY | Public Key [PubKey] | DER encoded public key. |
| T_CERT | Certificate [Cert] | DER encoded X509 certificate. |
| T_KEYLINK | KeyLink [KeyLink] | A CCNx Link object. |
| T_SIGTIME | SignatureTime [SigTime] | A millsecond timestamp indicating the time when the signature was created. |
The KeyId is the publisher key identifier. It is similar to a Subject Key Identifier from X509 [RFC 5280, Section <IP_ADDRESS>]. It should be derived from the key used to sign, such as from the SHA-256 hash of the key. It applies to both public/private key systems and to symmetric key systems.
The KeyId is represented using the Section 3.3.3. If a protocol uses a non-hash identifier, it should use one of the reserved values.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_KEYID | LENGTH+4 | +---------------+---------------+---------------+---------------+ | <hash type> | LENGTH | +---------------+---------------+---------------+---------------+ / LENGTH octets of hash / +---------------+---------------+---------------+---------------+
A Public Key is a DER encoded Subject Public Key Info block, as in an X509 certificate.
1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---------------+---------------+---------------+---------------+ | T_PUBLICKEY | Length | +---------------+---------------+---------------+---------------+ / Public Key (DER encoded SPKI) / +---------------+---------------+---------------+---------------+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_CERT | Length | +---------------+---------------+---------------+---------------+ / Certificate (DER encoded X509) / +---------------+---------------+---------------+---------------+
A KeyLink type KeyLocator is a Link.
The KeyLink ContentObjectHashRestr, if included, is the digest of the Content Object identified by KeyLink, not the digest of the public key. Likewise, the KeyIdRestr of the KeyLink is the KeyId of the ContentObject, not necessarily of the wrapped key.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | T_KEYKINK | Length | +---------------+---------------+-------------------------------+ / Link / +---------------------------------------------------------------+
The SignatureTime is a millisecond timestamp indicating the time at which a signature was created. The signer sets this field to the current time when creating a signature. A verifier may use this time to determine whether or not the signature was created during the validity period of a key, or if it occurred in a reasonable sequence with other associated signatures. The SignatureTime is unrelated to any time associated with the actual CCNx Message, which could have been created long before the signature. The default behavior is to always include a SignatureTime when creating an authenticated message (e.g. HMAC or RSA).
SignatureTime is a network byte ordered unsigned integer of the number of milliseconds since the epoch in UTC of when the signature was created. It is a fixed 64-bit field.
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | T_SIGTIME | 8 | +---------------+---------------+-------------------------------+ / SignatureTime / +---------------------------------------------------------------+
As an example of a MIC type validation, the encoding for CRC32C validation would be:
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_VALIDATION_ALG | 4 | +---------------+---------------+---------------+---------------+ | T_CRC32C | 0 | +---------------+---------------+---------------+---------------+
As an example of a MAC type validation, the encoding for an HMAC using a SHA256 hash would be:
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_VALIDATION_ALG | 40 | +---------------+---------------+---------------+---------------+ | T_HMAC-SHA256 | 36 | +---------------+---------------+---------------+---------------+ | T_KEYID | 32 | +---------------+---------------+---------------+---------------+ / KeyId / /---------------+---------------+-------------------------------+
As an example of a Signature type validation, the encoding for an RSA public key signing using a SHA256 digest and Public Key would be:
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_VALIDATION_ALG | 44 + Variable Length | +---------------+---------------+---------------+---------------+ | T_RSA-SHA256 | 40 + Variable Length | +---------------+---------------+---------------+---------------+ | T_KEYID | 32 | +---------------+---------------+---------------+---------------+ / KeyId / /---------------+---------------+-------------------------------+ | T_PUBLICKEY | Variable Length (~ 160) | +---------------+---------------+---------------+---------------+ / Public Key (DER encoded SPKI) / +---------------+---------------+---------------+---------------+
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+---------------+---------------+ | T_VALIDATION_PAYLOAD | ValidationPayloadLength | +---------------+---------------+---------------+---------------+ / Type-dependent data / +---------------+---------------+---------------+---------------+
The ValidationPayload contains the validation output, such as the CRC32C code or the RSA signature.
This section details each kind of protocol value that can be registered. Each type registry can be updated by incrementally expanding the type space, i.e., by allocating and reserving new types. As per [RFC5226] this section details the creation of the "CCNx Registry" and several sub-registries.
| Property | Value |
|---|---|
| Name | CCNx Registry |
| Abbrev | CCNx |
The following packet types should be allocated. A PacketType MUST be 1 byte. New packet types are allocated via "RFC Required" action.
| Property | Value |
|---|---|
| Name | Packet Type Registry |
| Parent | CCNx Registry |
| Review process | RFC Required |
| Syntax | 1 octet (decimal) |
| Type | Name | Reference |
|---|---|---|
| 0 | PT_INTEREST | Fixed Header Types [header] |
| 1 | PT_CONTENT | Fixed Header Types [header] |
| 2 | PT_RETURN | Fixed Header Types [header] |
The following InterestReturn code types should be allocated.
| Property | Value |
|---|---|
| Name | Interest Return Code |
| Parent | CCNx Registry |
| Review process | Expert Review, should include public standard leading to RFC. |
| Syntax | 1 octet (decimal) |
| Type | Name | Reference |
|---|---|---|
| 1 | T_RETURN_NO_ROUTE | Fixed Header Types [ReturnCode] |
| 2 | T_RETURN_LIMIT_EXCEEDED | Fixed Header Types [ReturnCode] |
| 3 | T_RETURN_NO_RESOURCES | Fixed Header Types [ReturnCode] |
| 4 | T_RETURN_PATH_ERROR | Fixed Header Types [ReturnCode] |
| 5 | T_RETURN_PROHIBITED | Fixed Header Types [ReturnCode] |
| 6 | T_RETURN_CONGESTED | Fixed Header Types [ReturnCode] |
| 7 | T_RETURN_MTU_TOO_LARGE | Fixed Header Types [ReturnCode] |
| 8 | T_RETURN_UNSUPPORTED_HASH_RESTRICTION | Fixed Header Types [ReturnCode] |
| 9 | T_RETURN_MALFORMED_INTEREST | Fixed Header Types [ReturnCode] |
The following hop-by-hop types should be allocated.
| Property | Value |
|---|---|
| Name | Hop-by-Hop Type Registry |
| Parent | CCNx Registry |
| Review process | RFC Required |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 1 | T_INTLIFE | Hop-by-hop TLV headers [per-hop] |
| 2 | T_CACHETIME | Hop-by-hop TLV headers [per-hop] |
| 3 | T_MSGHASH | Hop-by-hop TLV headers [per-hop] |
| 4 - 7 | Reserved | |
| %x0FFE | T_PAD | Pad [pad] |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000-%x1FFF | Reserved | Experimental Use [TLV] |
The following top-level types should be allocated.
| Property | Value |
|---|---|
| Name | Top-Level Type Registry |
| Parent | CCNx Registry |
| Review process | RFC Required |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 1 | T_INTEREST | Top-Level Types [top_level] |
| 2 | T_OBJECT | Top-Level Types [top_level] |
| 3 | T_VALIDATION_ALG | Top-Level Types [top_level] |
| 4 | T_VALIDATION_PAYLOAD | Top-Level Types [top_level] |
The following name segment types should be allocated.
| Property | Value |
|---|---|
| Name | Name Segment Type Registry |
| Parent | CCNx Registry |
| Review process | Expert Review with public specification |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 1 | T_NAMESEGMENT | Name [names] |
| 2 | T_IPID | Name [names] |
| 16 - 19 | Reserved | Used in other drafts |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000 - %x1FFF | T_APP:00 - T_APP:4096 | Application Components [names] |
The following CCNx message segment types should be allocated.
| Property | Value |
|---|---|
| Name | Message Type Registry |
| Parent | CCNx Registry |
| Review process | RFC Required |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 0 | T_NAME | Message Types [CCNMessage] |
| 1 | T_PAYLOAD | Message Types [CCNMessage] |
| 2 | T_KEYIDRESTR | Message Types [CCNMessage] |
| 3 | T_OBJHASHRESTR | Message Types [CCNMessage] |
| 5 | T_PAYLDTYPE | Content Object Message Types [COmetadata] |
| 6 | T_EXPIRY | Content Object Message Types [COmetadata] |
| 7 - 12 | Reserved | Used in other RFC drafts |
| %x0FFE | T_PAD | Pad [pad] |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000-%x1FFF | Reserved | Experimental Use [TLV] |
The following payload types should be allocated.
| Property | Value |
|---|---|
| Name | PayloadType Registry |
| Parent | CCNx Registry |
| Review process | Expert Review with public specification |
| Syntax | Variable length unsigned integer (decimal) |
| Type | Name | Reference |
|---|---|---|
| 0 | T_PAYLOADTYPE_DATA | Payload Types [payload_type] |
| 1 | T_PAYLOADTYPE_KEY | Payload Types [payload_type] |
| 2 | T_PAYLOADTYPE_LINK | Payload Types [payload_type] |
The following validation algorithm types should be allocated.
| Property | Value |
|---|---|
| Name | Validation Algorithm Type Registry |
| Parent | CCNx Registry |
| Review process | Expert Review with public specification of the algorithm |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 2 | T_CRC32C | Validation Algorithm [ValAlg] |
| 4 | T_HMAC-SHA256 | Validation Algorithm [ValAlg] |
| 5 | T_RSA-SHA256 | Validation Algorithm [ValAlg] |
| 6 | EC-SECP-256K1 | Validation Algorithm [ValAlg] |
| 7 | EC-SECP-384R1 | Validation Algorithm [ValAlg] |
| %x0FFE | T_PAD | Pad [pad] |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000-%x1FFF | Reserved | Experimental Use [TLV] |
The following validation dependent data types should be allocated.
| Property | Value |
|---|---|
| Name | Validation Dependent Data Type Registry |
| Parent | CCNx Registry |
| Review process | RFC Required |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 9 | T_KEYID | Validation Dependent Data [vdd] |
| 10 | T_PUBLICKEYLOC | Validation Dependent Data [vdd] |
| 11 | T_PUBLICKEY | Validation Dependent Data [vdd] |
| 12 | T_CERT | Validation Dependent Data [vdd] |
| 13 | T_LINK | Validation Dependent Data [vdd] |
| 14 | T_KEYLINK | Validation Dependent Data [vdd] |
| 15 | T_SIGTIME | Validation Dependent Data [vdd] |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000-%x1FFF | Reserved | Experimental Use [TLV] |
The following CCNx hash function types should be allocated.
| Property | Value |
|---|---|
| Name | Hash Function Type Registry |
| Parent | CCNx Registry |
| Review process | Expert Review with public specification of the hash function |
| Syntax | 2 octet TLV type (decimal) |
| Type | Name | Reference |
|---|---|---|
| 1 | T_SHA-256 | Hash Format [hash_format] |
| 2 | T_SHA-512 | Hash Format [hash_format] |
| %x0FFF | T_ORG | Organization-Specific TLVs [vendor] |
| %x1000-%x1FFF | Reserved | Experimental Use [TLV] |
The CCNx message format includes the ability to attach MICs, MACs, and Signatures to all packet types. This does not mean that it is a good idea to use an arbitrary ValidationAlgorithm, nor to include computationally expensive algorithms in Interest packets, as that could lead to computational DoS attacks. Application protocols should use an explicit protocol to guide their use of packet signatures.
The CCNx message format does not include explicit guidance for encryption. This is covered by other specifications.
Because some implementations may store the entire Name at intermediate hops, application designers should use concise names and not store large fields there. Deployments may choose to use their own guidelines for name limitations. There is currently no recommended practices for Interest deployments.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |


The aim of healthcareai
is to make machine learning in healthcare as easy as possible. It does that by providing functions to:
healthcareai
can take you from messy data to an optimized model in one line of code:
models <- machine_learn(pima_diabetes, patient_id, outcome = diabetes) models # > Algorithms Trained: Random Forest, eXtreme Gradient Boosting, and glmnet # > Model Name: diabetes # > Target: diabetes # > Class: Classification # > Performance Metric: AUROC # > Number of Observations: 768 # > Number of Features: 12 # > Models Trained: 2018-09-01 18:19:44 # > # > Models tuned via 5-fold cross validation over 10 combinations of hyperparameter values. # > Best model: Random Forest # > AUPR = 0.71, AUROC = 0.84 # > Optimal hyperparameter values: # > mtry = 2 # > splitrule = extratrees # > min.node.size = 12
Make predictions and examine predictive performance:
For details on what’s happening under the hood and for options to customize data preparation and model training, see Getting Started with healthcareai as well as the helpfiles for individual functions such as ?machine_learn
, ?predict.model_list
, and ?explore
.
Documentation of all functions as well as vignettes on various uses of the package are available at the package website: https://docs.healthcare.ai/.
Also, be sure to read our blog and watch our broadcasts to learn more about what’s new in healthcare machine learning and how we are using this toolkit to put machine learning to work in real healthcare systems.
We have a Slack community that is a great place to introduce yourself, share what you’re doing with the package, ask questions, and troubleshoot your code.
If you are interested in contributing the package (great!), please read the contributing guide, and look for issues with the “help wanted” tag. Feel free to tackle any issue that interests you; those are a few issues that we feel would make a good place to start.
Your feedback is hugely appreciated. It is makes the package work well and helps us make it more useful to the community. Both feature requests and bug reports should be submitted as Github issues.
Bug reports should be filed with a minimal reproducable example. The reprex package is extraordinarily helpful for this. Please also include the output of sessionInfo()
or better yet, devtools::session_info()
.
Version 1 of healthcareai
has been retired. You can continue to use it, but its compatibility with changes in the R ecosystem are not guaranteed. You should always be able to install it from github with: install.packages("remotes"<EMAIL_ADDRESS>.
For an example of how to adapt v1 models to the v2 API, check out the Transitioning vignettes.


Inspirational Ellie is named our Local Hero
The Centre, Livingston, welcomed the teenager who was awarded this month’s title and a £100 gift card to spend in the mall
by Debbie Hall, https://www.dailyrecord.co.uk/authors/debbie-hall/An inspirational little girl who is battling cancer has been named this month’s Local Hero.
The Centre, Livingston, welcomed very special guest Ellie Beattie (13), who was awarded this month’s title and a £100 gift card to spend in the mall.
Ellie, who was diagnosed with a brain tumour in 2018, was joined by her mum Elaine, who nominated her for the Local Hero Award in recognition of her outstanding bravery throughout her treatment.
Since being diagnosed Ellie has endured 32 bouts of radiotherapy and life-threatening brain operations.
Her mum created a Facebook page for Ellie when she was first diagnosed and has charted her long battle with the disease on the page.
She also posts any fun things they get up to, like visiting the circus or cinema, and members of the page can interact and suggest things for them to do.
The page is called Ellie’s Brave Cancer Journal and anyone who would like to help out or just encourage can join the group.
Elaine said Ellie loves to visit The Centre, especially for anything art-related which is her favourite hobby, and books, in particular Harry Potter.

“It was great to be invited along to collect it and the gift card too, which I’m very grateful for.
“I thoroughly enjoyed my shopping spree with my mum buying some new books, DVDs and stationery, which I love.”
Centre director Patrick Robbertze said: “It was a real honour to meet the wonderful Ellie Beattie last week and present her with our Local Hero award and £100 gift card to treat herself to something nice, which she truly deserves.”
If you know someone who is worthy of being nominated for the Local Hero Award, perhaps someone who has gone the extra mile to help others in the community, such as volunteering in a community group, fundraising or caring for family members or even someone who has excelled at school or a sports club and deserves recognition, please send an email with the details to debbie.hall@trinitymirror.com.


Some Ways You Can Contact Me By are...
These are my main things that I would like people to contact me by.


Curv: A Language for making Art using Mathematics
What is Curv?
Curv is an open source† 3D solid modelling language,
for 3D printing and procedurally generated art.
It's easy to use for beginners. It's incredibly powerful for experts.
And it's fast: all rendering is performed by the GPU.
Curv is also an expressive file format
for the exchange of 2D and 3D procedurally generated graphics.
† github.com/doug-moen/curv -- BSD licence
How Curv Achieves these Design Goals
- Ease of use:
- For ease of use, the best choice is Constructive Solid Geometry (CSG)
embedded in a simple, pure functional language.
- Rendering Speed:
- To quickly render a wide range of CSG primitives,
the best choice is to render on a GPU,
and to represent shapes using Signed Distance Fields (SDF)
and Function Representation (F-Rep).
- Expressive Power:
- SDF/F-Rep is the best choice for CSG:
A wide range of CSG primitives are available in Open Source.
New CSG primitives can be defined directly in Curv.
OpenSCAD is Amazing
- Marius Kintel's April 2014 KWLUG presentation on OpenSCAD
- Procedurally generated, parametric 3D models.
Named model parameters, conditionals, loops, user defined functions.
- Pure functional CSG: primitive shapes, operations for constructing new
shapes from existing shapes.
- Minimal boilerplate,
compared to 3D modelling in JavaScript, Python, etc.
- Nice GUI.
The OpenSCAD Language is Weak
The language is weak and complicated:
- 4 universes of things: values, functions, modules, shapes
- 3 namespaces
- can't use functions as arguments, return as results
- Can't store shapes in variables
- Can't query a shape, eg can't ask for bounding box.
- no record values
OpenSCAD vs Curved and Coloured Shapes
Curved surfaces & organic shapes are hard to achieve:
- Lots of triangles are needed to make curved surfaces look good,
but this makes boolean operations (union etc) unusably slow.
- Few CSG operations for creating curved surfaces.
Very limited support for colour.
I Get Involved with the OpenSCAD Project
- 2014: series of proposals to strengthen the language.
- Function, shape & record values. Module system.
- Marius is supportive. The community is divided.
- OpenSCAD2 project: first commit May 2015
- A proposal to improve the language, 100% backward compatibility.
- Problems:
- Clean design means 1 namespace, 90% backward compatibility.
- Which means a fork, dividing the community.
- 100% backward compatibility is difficult to design,
time consuming to implement, creates a lot of language complexity.
- No time to create a better geometry kernel.
The Curv Project
Curv project on github: first commit May 2016
- New language: simple, orthogonal, powerful
- New geometry kernel: signed distance fields and F-Rep
- Volumetric colour (F-Rep)
- Curv programs compile into GPU code (fast rendering)
Language Goals
- Easy to use for novices and artists. Focus is artistic exploration,
not software engineering.
- Powerful enough for experts. Libraries of new CSG operations can
be written in Curv and distributed over the internet.
- Safe and secure. A Curv program downloaded over the internet can't
encrypt all your files or exfiltrate personal information to a server.
Language Characteristics
- Simple, elegant, powerful: One universe, one namespace.
- Dynamically typed.
- Pure functional language. No I/O. Programs are expressions.
- Curried functions, patterns, list/record/string comprehensions.
- Array language: scalar arithmetic operations work on
vectors, matrices and higher dimensional arrays.
- 7 data types: the 6 JSON types, plus function values.
- Superset of JSON.
Curv is a data interchange format for pure functional data.
The 7 Data Types
- null
- Boolean values: true and false
- Numbers: 42, 3.1416
- Lists: [1,2,3] or (1,2,3), 1..10
- Strings: "hello, world"
- Records: {angle: 90*deg, axis: Z_axis}
- Functions: x -> x + 1
Function Call Syntax
Function call is a binary operation: f x
- Argument lists: f (x,y)
- Argument records: rotate {angle: a, axis: v}
- Curried functions: f x y
Pipeline Syntax
- Pipelines: colour red (rotate (45*deg) (cube 10))
becomes cube 10 >> rotate (45*deg) >> colour red
- Infixes: union(cube, cylinder {h: 5, d: .5})
becomes cube `union` cylinder {h: 5, d: .5}
dodecahedron
>> colour red
`union` icosahedron
|
|
Blocks
An expression is a block with local variables:
- let definitions in expression
- expression where definitions
let
diam = 1;
len = 4;
in
union(candy, stick)
where
candy = sphere diam >> colour red;
stick = cylinder {h: len, d: diam/8} >> move(0,0,-len/2);
Libraries
Contents of "lollipop.curv":
{
lollipop(diam, len) =
union (
sphere(diam) >> colour red,
cylinder{h:len, d:diam/8} >> move(0,0,-len/2)
);
}
To use the library elsewhere:
lollipop(1,4)
where
include file "lollipop.curv";
The Shape Library
- written entirely in Curv
- shapes are records
- 2D and 3D primitive shapes
- boolean (set theoretic) operations
- transformations: affine, non-affine, 2D->3D, repetition
- distance field ops: offset, shell, morph, blend
- colour
Primitive Shapes
2D:
- circle, ellipse, stroke
- square, rect, regular_polygon, convex_polygon, half_plane
3D:
- sphere, ellipsoid, cylinder, cone, torus, capsule
- tetrahedron, cube, octahedron, dodecahedron, icosahedron
- box, prism, pyramid, half_space
Additive/Subtractive Operations
- Boolean: complement, union, intersection, difference
- offset, shell, morph, blend
Colour
- A colour field maps every point in space onto a colour.
- Every shape has a colour field.
- Standard support for constructing colour gradients.
- Colour field transformations.
- Colour blending (in morph, blend, union)
Shape Representations
| Explicit Modelling |
Implicit Modelling |
| Directly generate boundary points |
Answer questions
about particular points |
parametric equation (unit circle):
(x,y) = (cos t, sin t)
|
implicit equation (unit circle):
x^2 + y^2 - 1 = 0
|
| Boundary Representations |
Volumetric Representations |
| parametric splines |
simple vs Signed Distance Fields |
| triangle mesh |
discrete (voxels) vs continuous
(Function Representation) |
Benefits of SDF/F-Rep
Curv 0.0 uses Signed Distance Fields with Function Representation.
- Exact representation of many shapes (curves, fractals)
- Infinitely large & infinitely detailed objects
- Large # of operations available (bend, twist, blend, etc)
- Fast boolean operations
- F-Rep for colour: gradients, quasi-photographic imagery
- Can describe 3D-printable objects not describable using STL or OpenSCAD.
More efficient 3D printing.
How SDF/F-Rep Works
A signed distance field maps each point in space
onto the minimum distance from that point to the boundary of the shape.
An SDF is zero for points on the boundary of the shape, negative for points
inside the shape, and positive for points outside of the shape.
The circle primitive is defined like this:
circle r = make_shape {
dist(x,y,z,t) = sqrt(x^2 + y^2) - r;
bbox = [[-r,-r,0], [r,r,0]]; // axis aligned bounding box
is_2d = true;
};
Future Work
- Release 0.0 is coming soon: documentation, STL export
- text, animation, fractals, noise, splines, sweep, Voronoi, Conway polyhedron operators, ...
- Reference external libraries via URL
- Import images, STL
- Geometry engine: compiler, discrete SDFs, ...
- Export colour models for 3D printing
- GUI, tweak model parameters using slider
Live Demo


Class SurfaceOfRevolution.HyperbolaHelp
Inheritance
System.Object
SurfaceOfRevolution.HyperbolaHelp
Inherited Members
System.Object.Equals(System.Object)
System.Object.Equals(System.Object, System.Object)
System.Object.GetHashCode()
System.Object.GetType()
System.Object.MemberwiseClone()
System.Object.ReferenceEquals(System.Object, System.Object)
System.Object.ToString()
Assembly: CADability.dll
Syntax
public class HyperbolaHelp : GeneralCurve2D, ICurve2D, IQuadTreeInsertable, I2DIntersectable
Constructors
|
Improve this Doc
View Source
HyperbolaHelp(GeoPoint, GeoVector, Double, Double)
Declaration
public HyperbolaHelp(GeoPoint sp, GeoVector dir, double ymin, double ymax)
Parameters
| Type |
Name |
Description |
| GeoPoint |
sp |
|
| GeoVector |
dir |
|
| System.Double |
ymin |
|
| System.Double |
ymax |
|
Fields
|
Improve this Doc
View Source
a
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
b
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
tmax
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
tmin
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
ymax
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
ymin
Declaration
Field Value
| Type |
Description |
| System.Double |
|
|
Improve this Doc
View Source
yoffset
Declaration
Field Value
| Type |
Description |
| System.Double |
|
Methods
|
Improve this Doc
View Source
Clone()
Declaration
public override ICurve2D Clone()
Returns
Overrides
|
Improve this Doc
View Source
Copy(ICurve2D)
Declaration
public override void Copy(ICurve2D toCopyFrom)
Parameters
| Type |
Name |
Description |
| ICurve2D |
toCopyFrom |
|
Overrides
|
Improve this Doc
View Source
DirectionAt(Double)
Declaration
public override GeoVector2D DirectionAt(double Position)
Parameters
| Type |
Name |
Description |
| System.Double |
Position |
|
Returns
Overrides
|
Improve this Doc
View Source
PointAt(Double)
Declaration
public override GeoPoint2D PointAt(double Position)
Parameters
| Type |
Name |
Description |
| System.Double |
Position |
|
Returns
Overrides
|
Improve this Doc
View Source
PositionOf(GeoPoint2D)
Declaration
public override double PositionOf(GeoPoint2D Position)
Parameters
Returns
| Type |
Description |
| System.Double |
|
Overrides
|
Improve this Doc
View Source
Split(Double)
Declaration
public override ICurve2D[] Split(double Position)
Parameters
| Type |
Name |
Description |
| System.Double |
Position |
|
Returns
Overrides
Implements


I Wanna Hold Your Hand
I Wanna Hold Your Hand is a movie starring Nancy Allen, Bobby Di Cicco, and Marc McClure. In 1964, six teenagers from New Jersey run off to see The Beatles perform on Toast of the Town (1948) in the hope of meeting their idols....


In order to take part in the DD track, you need to be a registered participant of TREC. The TREC Call for Participation, at
http://trec.nist.gov/pubs/call2016.html, includes instructions on how to register. You must register before May 1, 2016 in order to participate.
The datasets and relevance judgments will be made generally available to non-participants after the TREC 2016 cycle, in February 2017. So register to participate if you want early access.
The TREC DD track provides interesting and understudied domains of documents. In 2016, we will have two domains: Ebola and Polar. All the datasets are formatted using the Common Crawl Architecture schema from the DARPA MEMEX project, and stored as sequences of CBOR objects. See the
Datasets page for more details.
Within each domain, there will be 25-50 topics that represent user search needs. In the Ebola domain, these have been developed by the NIST assessors, whereas in the Polar domain, the topics were developed by Annie Burgess and Chris Mattman at USC. A topic (which is like a query) contains a few words. It is the main search target for one complete run of dynamic search. Each topic contains multiple subtopics, each of which addresses one aspect of the topic. The NIST assessors have tried (very hard to) produce a complete set of subtopics for each topic, and so we will treat them as the complete set and use them in the interactions and evaluation.
An example topic from the 2015 Illicit Goods domain topic set may be found
here. It is about "paying for amazon book reviews" and contains 2 subtopics.
The topics will be made available from the
Tracks page in the TREC Active Participants area. You cannot access this page without registering for TREC. If you lose your active participants password, you will need to contact
<EMAIL_ADDRESS>The topics file contains not only the queries but in fact the full ground truth data: subtopics, relevant documents, and highlighted passages.
DO NOT READ THE FILE. The file should be used only as input to the jig, and your system receives the truth data via the jig. If you examine the topics file, your run
may not be labeled automatic but rather is a manual run.
When your "run" starts, your system will communicate with the jig via a simple API. Your system indicates that it is ready for a new query, and the jig will give you a query along with its domain label. Your system can use that query to search the domain collection and return up to five documents to the jig. The jig will reply with relevance information for any of those retrieved documents that have been judged.
Your systems will receive an initial query for each topic, where the query is two to four words and additionally indicates the domain by a number 1, 2, 3 or 4. In response to that query, systems may return up to five documents to the user. The jig (acting as a simulated user) will respond by indicating which of the retrieved documents are relevant to their interests in the topic, and to which subtopic the document is relevant to. Additionally, the simulated user will identify passages from the relevant documents and assign the passages to the subtopics with a graded relevance rating. The system may then return another five documents for more feedback. Systems should stop until they believe they have covered all the user's subtopics sufficiently.
The subtopics are not known to your system in advance; systems must discover the subtopics from the user's responses.
The jig only gives relevance information when it exists. If the jig gives no information about a document your system retrieved, it does not mean that the document is not relevant, it means that the user hasn't examined it. Your system should assume this partial relevance situation,
NOT the traditional TREC interpretation that unjudged documents are not relevant.
The following picture illustrates the task:
The system's interactions with the user can be simulated by a jig that the track coordinators provide. This jig runs on Linux, Mac OS, and Windows. You will need the
topics with ground truth to make the jig work, and your system may only interact with the ground truth through the jig that we provide.
The jig package will be released on the Github soon. We will provide the jig program, as well as instrucions on how to set up and run the jig with an example oracle system, and how to write your system to connect with the jig.
The primary measures will be Cube Test and µ-ERR. Scoring scripts are included as part of the jig. We will also likely report other diagnostic measures such as basic precision and recall.
The Cube Test is a search effectiveness measurement that measures the speed of gaining relevant information (could be documents or passages) in a dynamic search process. It measures the amount of relevant information a search system could gather for the entire search process with multiple runs of retrieval. A higher Cube Test score means a better DD system, which ranks relevant information (documents and/or psaasages) for a complex
search topic as much as possible and as early as possible.
Reference: Jiyun Luo, Christopher Wing, Hui Yang, Marti Hearst. The Water Filling Model and The Cube Test: Multi-Dimensional Evaluation for Professional Search. CIKM 2013.
http://cs-sys-1.uis.georgetown.edu/~xd47/InfoSense/publication/cikm2013.pdf
In TREC, a "run" is the output of a search system over all topics. In the DD track, the runs are the output of the harness jig. Participating groups typically submit more than one run corresponding to different parameter settings or algorithmic choices. The maximum number of runs allowed for DD-2016 is
five from each team.
We use a line-oriented format similar to the classic TREC submission format:
topic_id docno ranking_score on_topic subtopic_rels
where 'on_topic' is 1 or 0 if the document is relevant to any subtopic, and the subtopic_rels indicate graded relevance for the document for all relevant subtopics. For instance:
topic_id docno ranking_score on_topic subtopic_rels
DD15-1<PHONE_NUMBER>-d6783cba6ad386f4444dcc2679637e0b 883.000000 1 DD15-1.1:3|DD15-1.4:2|DD15-1.4:2|DD15-1.4:2|DD15-1.4:2|DD15-1.4:2|DD15-1.2:2|DD15-1.2:2
DD15-1<PHONE_NUMBER>-f67659162ce908cc510881a6b6eabc8b 564.000000 1 DD15-1.1:3
DD15-1<PHONE_NUMBER>-f9c69177db43b0f810ce03c822576c5c 177.000000 1 DD15-1.1:3
DD15-1<PHONE_NUMBER>-e8c92486dc3462e4a352c4fd41d3a723 66.000000 0
DD15-1<PHONE_NUMBER>-d9ad76f0947e2acd79cba3acd5f449f7 25.000000 1 DD15-1.3:2|DD15-1.1:2
Participants are expected to submit at least one run by the deadline.
Runs may be fully automatic, or manual. Manual indicates intervention by a person at any stage of the retrieval. We welcome unusual approaches to the task including human-in-the-loop searching, as this helps us set upper performance bounds.


Your next upgrades should be ??? at ??? more Nullifium, and ??? at ??? more Nullifium.
Currently the only mods this will recommend upgrading are Trimp Attack, Crit Chance, Crit Damage, Plaguebringer, Void Map Drop Chance, Gamma Burst, Fluffy Exp, Miner Efficiency, and every core mod. (also Trimp Health/Prismatic in U2) If you have other useful mods on your heirlooms (such as Explorer Efficiency or Fragment Drop Rate), you'll have to upgrade them based on feel, as they're very difficult to weigh.
Additionally, this will not recommend replacing mods with stronger ones, nor adding mods in empty slots, nor equipping a better heirloom from your carried ones, nor saving spirestones for additional floors. But you probably shouldn't spend spirestones until you have a quite a few floors, or have a replacement core so you can recycle your current to afford the next floor.
To the right of the inputs, you'll see your inventory of carried heirlooms. To weigh mods using one of these heirlooms rather than your currently equipped heirloom, click on the one you'd like to weigh. To go back to your equipped heirloom, click on your currently selected heirloom to unselect it. You can also hover over the heirlooms in your inventory to view them.
VM weight, XP weight, and HP weight are multipliers to the value of the Void Map Drop Chance, Fluffy Exp, and Trimp Health/Breed Speed mods respectively. So if your next VMDC upgrade were to increase your value by 0.5%, the default weight of 12 will multiply it by 12 so it will be calculated as if it were to increase your value by 6%. The default weights (12/11.25) are used to provide a good balance between damage and helium/exp gain.
Weapon levels is the average number of weapon levels (not prestiges) you have on each weapon by the end of your run.
Daily crit chance bonus is the % bonus to crit chance you'll have from your daily. Please note that unless you're making a shield for a specific daily, you should leave this at 0.


Orginally autofocus set focus to the last element with that attribute. Now it is set to the first with the attribute present, which makes more sense.


--- title: sgrna_designer keywords: fastai sidebar: home_sidebar summary: "Python library to design sgRNAs for CRISPR tiling screens" description: "Python library to design sgRNAs for CRISPR tiling screens" nb_path: "index.ipynb" ---
The primary function of this package is design_sgrna_tiling_library
, in which you can input a list of
ensembl transcript IDs, specify a region of interest (e.g. three_prime_UTR) and get all sgRNAs
tiling those transcript regions.
pip install git+https://github.com/gpp-rnd/sgrna_designer.git#egg=sgrna_designer
In this example we'll design sgRNAs tiling the 3' UTR of PDL1 (CD274) and BRAF
Note: You must also have pandas installed to run this tutorial
from sgrna_designer.design import design_sgrna_tiling_library
target_transcripts = ['ENST00000381577', 'ENST00000644969'] # [PDL1, BRAF]
Note the design function is agnostic to CRISPR enzyme and pam preferences, so you must specifiy the following parameters in a design run:
sgrna_designs = design_sgrna_tiling_library(target_transcripts, region_parent='UTR',
region='three_prime_UTR', expand_3prime=30,
expand_5prime=30, context_len=30, pam_start=-6,
pam_len=3, sgrna_start=4, sgrna_len=20,
pams=['AGG', 'CGG', 'TGG', 'GGG'],
sg_positions=[4, 8], flag_seqs=['TTTT', 'CGTCTC', 'GAGACG'],
flag_seqs_start=['TCTC', 'AGACG'], flag_seqs_end=['GAGAC'])
sgrna_designs


| extract.lme.cov {mgcv} | R Documentation |
This is a service routine for gamm
. Extracts
the estimated covariance matrix of the data from an lme
object, allowing the
user control about which levels of random effects to include in this
calculation. extract.lme.cov
forms the full matrix explicitly:
extract.lme.cov2
tries to be more economical than this.
extract.lme.cov(b,data,start.level=1) extract.lme.cov2(b,data,start.level=1)
b |
A fitted model object returned by a call to |
.
data |
The data frame/ model frame that was supplied to
|
start.level |
The level of nesting at which to start including random effects in the calculation. This is used to allow smooth terms to be estimated as random effects, but treated like fixed effects for variance calculations. |
The random effects, correlation structure and variance structure used for a linear mixed model combine to imply a covariance matrix for the response data being modelled. These routines extracts that covariance matrix. The process is slightly complicated, because different components of the fitted model object are stored in different orders (see function code for details!).
The extract.lme.cov
calculation is not optimally efficient, since it forms the full matrix,
which may in fact be sparse. extract.lme.cov2
is more efficient. If the
covariance matrix is diagonal, then only the leading diagonal is returned; if
it can be written as a block diagonal matrix (under some permutation of the
original data) then a list of matrices defining the non-zero blocks is
returned along with an index indicating which row of the original data each
row/column of the block diagonal matrix relates to. The block sizes are defined by
the coarsest level of grouping in the random effect structure.
gamm
uses extract.lme.cov2
.
extract.lme.cov
does not currently deal with the situation in which the
grouping factors for a correlation structure are finer than those for the
random effects. extract.lme.cov2
does deal with this situation.
For extract.lme.cov
an estimated covariance matrix.
For extract.lme.cov2
a list containing the estimated covariance matrix
and an indexing array. The covariance matrix is stored as the elements on the
leading diagonal, a list of the matrices defining a block diagonal matrix, or
a full matrix if the previous two options are not possible.
Simon N. Wood<EMAIL_ADDRESS>For lme
see:
Pinheiro J.C. and Bates, D.M. (2000) Mixed effects Models in S and S-PLUS. Springer
For details of how GAMMs are set up here for estimation using lme
see:
Wood, S.N. (2006) Low rank scale invariant tensor product smooths for Generalized Additive Mixed Models. Biometrics 62(4):1025-1036
or
Wood S.N. (2017) Generalized Additive Models: An Introduction with R (2nd edition). Chapman and Hall/CRC Press.
http://www.maths.bris.ac.uk/~sw15190/
## see also ?formXtViX for use of extract.lme.cov2 require(mgcv) library(nlme) data(Rail) b <- lme(travel~1,Rail,~1|Rail) extract.lme.cov(b,Rail)


Home
Lesson
Evaluation
Reports
Skills
Student
Groups
Catalog Skills
Language Arts Skills
Click to add a skill to your list
LA Skill
Math Skills
Click to add a skill to your list
MTh Skill
MTh Skill
Your Skills List
Click to remove a skill from your list
MTh Skill
Custom Skills
Skill
New Skill


An analysis of how company insiders trade stocks
INTRODUCTION
INSIDERS: who are they?
An insider is a person who possesses access to material and non-public information about a corporation. This makes a company's directors and high-level executive’s insiders.
While insiders only owns a small percentage of the overall equity market (see chart to the right), they remain an unique group given that the information they possess cannot be accessed with other investors.
DATA
Because of the information they have access to, insiders are required by the SEC to file prior to buying and selling stocks of which they are an insider. Also, it is required by law that insiders can only trade when they do not possess "material non-public" information. But is that truly the case?
We are using these required filings (Form 4) to do our analysis. While the data can be found on SEC website, we are using ready-cleaned data from WRDS and with supplemental data from Bloomberg.
The data includes:
List of companies (hover over to see details)
OWNERSHIP OVERVIEW: Ownership varies across board
Interesting Observations:
Play with it yourself: What is the average CEO ownership in financial companies?
TRANSACTIONS: More selling than buying
Interesting Observations:
Play with it yourself: How much shares did utilities executives buy in 3Q18 (as % of market cap)?
PROFITABILITY: Not all transactions are equally profitable
Interesting Observations:
Play with it yourself: What was the 6M profit for shares bought by industrial executives in 3Q17?
PROFITABILITY: A timelapse
Observations:
Play with it yourself! The chart below show individual transactions color coded by sector.


| Developer Spotlight |
Neelakanth Nadgir, known as neel on the jxta.org aliases, started working on Project JXTA in early 2001 and is currently the owner of two projects: JNGI and JAL. He originally started with the JXTA project while using JXTA on a distributed computing project. JXTA is the natural fit for performing distributed computing over the Internet. The JAL (JXTA abstraction project) aims to simplify JXTA development. It is in active development, and several JXTA projects have benefited by it. Neel has presented JNGI and Project JXTA at multiple conferences & demonstrated it at JavaONE, SunNetwork conference, GRID 2002, and the HPC (High Performance Computing) Consortium. He evangalizes Project JXTA technology to a lot of people he meets at these conferences. He also contributes articles to the Solaris Developer Connection. He works in the Sun Microsystems Market Development Engineering organization helping companies and developers adopt Sun technologies. He is based in San Jose, California. Neel's vision for Project JXTA is uniting people, anytime, anywhere, on any toy, with JXTA. You can reach Neel at<EMAIL_ADDRESS>|


{% extends 'helpers/layout.html' %} {% block title %} Dashboard {% endblock %} {% block statusbar %} {% endblock %} {% block extrahead %} {% endblock %} {% block body %}
Hello {{ g.user.name() }} ({{ g.user.id }}), you are in "{{ g.course.name }}" ({{g.course.id}}). Welcome to your dashboard!
See an overview of the entire textbook, including later chapters!.
{% for textbook in textbooks %} Read {{ textbook.name }} {% endfor %}Need a place to quickly run some BlockPy code and experiment? Get a reusable scratchpad!
BlockPy ScratchpadBelow are all the previously submitted assignments that we have found for you in this course.
{% include "helpers/submission_student_table.html" %} {% endblock %}


About Me
Gochujang squid disrupt, prism selfies snackwave flannel four dollar toast YOLO sustainable mumblecore. Sartorial wolf lyft, yuccie edison bulb literally tofu organic post-ironic roof party selfies meditation drinking vinegar whatever. Paleo yuccie actually, try-hard godard dreamcatcher single-origin coffee readymade mlkshk everyday carry. Taiyaki iceland art party squid pour-over blog enamel pin keytar. Swag tilde ramps cronut viral fingerstache. Cornhole mumblecore semiotics gochujang, lomo lyft vegan lumbersexual raw denim.


You need the Code Completion setting enabled on the Your Account page to use autocomplete.
Follow these steps to use autocomplete:
self.Set
Set
or SimpleMovingAverage.Upda
).If there are class members that match the characters you provided, a list of class members displays.


I am a Responsive Designer & Developer who prefers the challenge to create intricate and
comprehensive designs with a refined aesthetic. While not working, I can be found covered in wood chips handcrafting functional treasures
in my workshop. I believe that the pure art of design appears effortless and gleams with a story to tell. I'd love to share my vision to
help you create something amazing.
I was born and raised in Los Angeles, CA. I remember the lure of our first home computer. I was introduced to tech early
in life watching by my mother's prototype robots learning to take their first steps in our home. Thus, puzzle-solving skills
and critical thinking were heavily encouraged when I was growing up.
Fun fact, in 2000, I learned to care for exotic animals. I hand-raised a pride of lions. It was also when I
met one of the biggest loves of my life, Nellie, an African elephant. It was my honor to include them in wildlife conservation seminars
to educate people about the perils of habitat encroachment and endangered species.