Just a few reasons (there are many more!)
(scroll down for details)
Questions and ideas will pop into your head at the most random times. At your desk; walking down the street; in an elevator; at the gym. Make sure to always write those ideas down the moment you have them. I do this using GMail. I have a GMail filter setup that automatically tags and archives emails with a particular Subject line. So, when I have one of those random ideas, I immediately open the closest GMail client (desktop or mobile) and shoot myself an email. Then, the next time I sit down to do some R&D, I have a catalog of ideas from which to choose.
Blogging is hard work. It takes time and dedication. Keeping with it will be much easier if you're doing it for yourself. Meaning, don't chase the next "hot topic" unless it really interests you. If you can do that, you end up creating a anthology of content that you, yourself, want to consume. When that happens, I guarantee that you'll find yourself referring back to your own writing as a sort of personalized documentation. Plus, when you're really excited about a topic, writing one post is more likely to lead to new ideas and new avenues of exploration as you find yourself falling down the rabbit hole of desire.
Sometimes, it's hard to get over the fear that you might be covering a topic that someone else has already covered. Who cares! What does that have to do with anything?! You're blogging for yourself.  When you write about a topic, it will be unique even if the general topic is common.
I can't tell you how many times I've been about to publish a post when I go to double-check something and then discover that half of what I've written is wrong. Sure, this is frustrating; but, it makes me a little wiser every time. Now, rather than attempting to draw theoretical conclusions, I try my best to test every assertion that I've made. And, if I can't test it - or I don't have time to test it - I'll replace the assertion with a written caveat as to where I believe I have gaps in my understand. I'm certainly a fan of the statement, "As such, please take the following paragraph with a grain of salt."
I write about everything. Every little hurdle. Every little mistake. Every little error that was hard to debug. If it tripped me up, confused me, or wasted my time, I think it's worth documenting. This does a service to anyone that might try to Google for the same thing. And, sometimes embarrassingly, I am that person - Googling for the solution to a problem that I already solved 8 months ago. Talk about paying it forward to your future self! Small topics also have the benefit of keeping the mental machinery working. A body in motion tends to stay in motion. So, if a bunch of small posts can keep up your momentum, I find that to be better than long periods of not writing.
(scroll down for details)
Before writing anything, I try to sit down and think through all the different aspects of my blog post. For starters, who am I writing this post for? Are they other developers? Users of my product? Fans of a TV show? What’s their background, what do they know? Knowing who you’re writing for frames the entire article - for me, it makes it easier to understand and define the scope of what you’re attempting to write. Once you know who you’re writing this for, think about what story you’re telling them. What is it that you want them to take away from this post? What’s the key message? Are you trying to convince them of something? Are you sharing something that you did?
My process of writing typically begins with post-it notes. I’ll start with all the key points I want to make, including some of the answers I came up with to the questions in the previous section. Once I’ve got all those post-its I start grouping them and moving them around to create different sections. What I like about this method is that it allows me to be a bit more flexible in how I tell the story - it’s easier to move post-its around and come up with the structure that works best without being bogged down in paragraphs and paragraphs of text.
It’s rare I’ll write something that I’m completely happy with in one go. Typically I’ll have an initial draft and go through it completely again - cutting parts, moving paragraphs around and turning it into a better story. Just like with refactoring code, you need to keep in mind that it’s all about making the end product better. Sometimes I’ll have written a sentence or paragraph that I completely love, but I know I need to cut, cause it just doesn’t work.
The main thing I’ve had to accept is that whatever I do none of my posts will ever be ‘perfect’. It’s sometimes super tricky to hit that publish button on something that you feel could be better, yet at the same you can’t keep every single post in a drafted state forever.
Yes!
Time to kickstart your new favourite hobby of tech blogging!
We've started an open source wiki page! Please use it, update it and add your own blogs you created today under the WHFNP category :)


fn() findRepeatsSearch for repeats in a text.
Search for repeats in a text.
| Defined in | <seqan/index.h> |
|---|---|
| Signature |
void findRepeats(repeatString, text, minRepeatLength[, maxPeriod]);
|
Parameters
repeatString
|
A String of Repeat objects. |
|---|---|
text
|
The text to search repeats in. Types: ContainerConcept |
minRepeatLength
|
The minimum length each reported repeat must have. |
maxPeriod
|
Optionally, the maximal period that reported repeats can have. Default: 1 |
Detailed Description
Subsequences of undefined values/Ns will always be reported.
Examples
The following demonstrates finding repeats of period 3.
#include <fstream> #include <seqan/basic.h> #include <seqan/index.h> #include <seqan/seq_io.h> using namespace seqan; int main() { // Get path to file to search for repeats in. std::string path = (std::string)SEQAN_PATH_TO_ROOT() + "/demos/index/ref.fa"; // Load first sequence from file. CharString id; Dna5String seq; SeqFileIn file(path.c_str()); readRecord(id, seq, file); // Find repeats and print them. String<Repeat<unsigned, unsigned> > repeats; findRepeats(repeats, seq, 3); std::cerr << "# of repeats: " << length(repeats) << "\n"; for (unsigned i = 0; i < length(repeats); ++i) std::cerr << "i == " << i << ", beginPosition = " << repeats[i].beginPosition << ", endPosition = " << repeats[i].endPosition << ", period = " << repeats[i].period << "\n"; return 0; }
# of repeats: 15 i == 0, beginPosition = 3, endPosition = 7, period = 1 i == 1, beginPosition = 46, endPosition = 53, period = 1 i == 2, beginPosition = 101, endPosition = 105, period = 1 i == 3, beginPosition = 105, endPosition = 109, period = 1 i == 4, beginPosition = 164, endPosition = 169, period = 1 i == 5, beginPosition = 291, endPosition = 297, period = 1 i == 6, beginPosition = 319, endPosition = 327, period = 1 i == 7, beginPosition = 400, endPosition = 404, period = 1 i == 8, beginPosition = 442, endPosition = 446, period = 1 i == 9, beginPosition = 468, endPosition = 473, period = 1 i == 10, beginPosition = 476, endPosition = 480, period = 1 i == 11, beginPosition = 507, endPosition = 513, period = 1 i == 12, beginPosition = 561, endPosition = 566, period = 1 i == 13, beginPosition = 623, endPosition = 627, period = 1 i == 14, beginPosition = 655, endPosition = 659, period = 1
Data Races
Thread safety unknown!


BetterDiscord
BetterDiscord
Home
Emotes
Plugins
Themes
Emotes
FrankerFaceZ
BetterTTV
All
Search
Command
Emote


---
layout: post
title: ! 'Top Tip: Windows Perl CPAN slows to crawl using network drives'
tags:
- Cygwin
- Perl
status: publish
type: post
published: true
meta:
_edit_last: '451289'
---
I noticed this when using Cygwin Perl, however I suspect the issue exists with any Perl distro on Windows.
The problem occurred when I had set the HOME environment variable to point to a network share. When I ran the CPAN utility it placed all the CPAN files on the network. As a result some modules would not install (I have no idea why) and it ran very very slowly.
The solution I adopted was to to move my home directory to the local PC drive which then made CPAN use the local drive as well. Changing cpan_home
in /usr/lib/perl5/5.10/CPAN/Config.pm
would probably have been simpler, but I was happy to use the local disk for everything.
YMMV


The list view grid component displays a grid for a SKY UX-themed list of data. Internally, the sky-list-view-grid uses the sky-grid component, which contains documentation for sky-grid-column.
To use the list view grid component, you must install SkyListModule as a dependency to your project. For information about SkyListModule, see list overview.
Specifies the name of the view. This property accepts string values.
Specifies the columns to display by default based on the ID or field of the item. This property accepts an array or Observable array of string values.
Indicates whether to enable the multiselect feature to display a column of checkboxes on the left side of the grid. Multiselect also displays an action bar with buttons to select and clear all checkboxes. Multiselect defaults to the id property on the list's data object. This property accepts boolean values.
Specifies how the grid fits to its parent. The valid options are width, which fits the grid to the parent's full width, and scroll, which allows the grid to exceed the parent's width. If the grid does not have enough columns to fill the parent's width, it always stretches to the parent's full width. This property accepts string values.
Specifies the height of the grid. This property accepts number or Observable number values.
Specifies the columns to hide by default based on the ID or field of the item. This property accepts an array or Observable array of string values.
Indicates whether to highlight search text within the grid. This property accepts boolean values.
Specifies the ID of the row to highlight. The ID matches the id property of the data object. Typically, this property is used in conjunction with the flyout component to indicate the currently selected row. This property accepts string values.
Specifies a search function to apply on the view data. This property accepts values of type (data: any, searchText: string) => boolean.
Specifies a unique key for the UI Config Service to retrieve stored settings from a database. The UI Config Service saves configuration settings for users and returns selectedColumnIds to preserve the columns to display and the preferred column order. This property accepts string values. For more information about the UI Config Service, see the sticky settings documentation
Specifies the width of the grid. This property accepts number or Observable number values.
When the multiselect feature is enabled and the selected checkboxes change, the list component's selectedIdsChange event emits a Map string, boolean object to indicate the selected items. This differs from multiselect behavior in the grid component where the multiselectSelectionChange event emits an array of IDs for the selected rows when the selection changes.
Fires when columns change. This includes changes to hide or display columns and changes to the order of columns. The event emits an array of IDs for the displayed columns that reflects the column order.
The sky-list-column-selector-action component provides a column selector modal for a list grid view when placed in a sky-list-toolbar component. For information the toolbar component, see the list toolbar.
SkyListViewGridModule includes this component along with sky-list-view-grid.
Enables the column selector in the list toolbar. The attribute must be set to the instance of the sky-grid-view component using the component's template reference variable.
Specifies a helpKey string. This property dispays the button in the grid header. When users click this button, the helpOpened event broadcasts the helpKey parameter.
Fires when users click the button and broadcasts the helpKey.


{%extends "confreg/confadmin_base.html" %} {%block title%}Conference registration log{%endblock%} {%block layoutblock%}


Mandarin
Determiner
几个 (几个) (jǐgè or jǐge)
- a few; several; some
- 你可不可以推荐几个比较好的学校？
- nǐ kě bǔ kěyǐ tuījiàn jǐgè bǐjiǎo hǎo de xuéxiào?
- Could you recommend a few good schools?
Adverb
几个 (simplified, Pinyin jǐgè or jǐge, traditional 幾個)
- how many
- 宝宝几个月会爬？
- bǎobǎo jǐgè yuè huì pá?
- At how many months can a baby crawl?
Usage notes
- Technically, 几个 jǐgè should only be used with nouns that have 个 gè as a primary measure word. Moreoever, 几个 jǐgè is only used when the answer to "how many?" is expected to be under ten. For amounts that are expected to exceed ten, 多少 duōshǎo is used.


Airdrop is a free distribution of small amounts of a certain virtual currency tokens to its community members either for free or for performing small tasks. We are currently giving away 2 anotes per person and you need Anonutopia wallet for both of them. This is how you can take part in Anote airdrop:
1. Register Anonutopia Wallet
Register a new Anonutopia wallet here.
2. Apply for citizenship in Anonutopia
This is how you get your first free anote.
Click Settings button in your wallet and apply for citizenship in Anonutopia. After you verify your email address, you will receive your free anote.
3. Ask Our Friendly Bot for It
This is the way to get your second free anote.
a) Join Our Telegram Group - Anonutopia
If you don't already have Telegram you can get it here.
Register with the app and then join Anonutopia group: t.me/Anonutopia.
b) Ask AnonsRobot for 1 Free Anote
Copy your wallet address and then use it with our friendly robot to get your free Anote like shown below. Of course, instead of our address ({{ .NodeAddress }}), you should use yours.
4. Share Your Referral Link
Remember to share your referral link on social networks. When ever somebody new registers with your link, you get 20% (0.2 Anote). If they purchase Anote, you also get 20%. You can access your referral link by selecting "Profit" page in your wallet's menu.


FEATURES
You get complete flexibility and control of everything, everywhere you need it, and detailed documentation to guide the way.
GET STARTEDEvery instance of FusionAuth is an isolated deployment with its own servers and database. This ensures that your data is completely isolated from other customers and applications. This means you can run FusionAuth on any server, anywhere in the world. Or let us host it for you.
FusionAuth supports MySQL or PostgreSQL databases. This means you pick the database server that best fits your needs. Most cloud database provides are also supported including Amazon's RDS and Google's Cloud SQL.
FusionAuth uses Elasticsearch to provide advanced user search capabilities. Any Elasticsearch 6.x server will work. This means you can use cloud provided Elasticsearch options or roll your own Elasticsearch cluster.
FusionAuth allows you to create tenants that logically separate Applications, Users, Themes, Emails and more. This is great for white-labelling, multiple environments (dev, stage, prod) on a single deployment, and much more. Read this blog post to learn more about FusionAuth's multi-tenant support.
FusionAuth allows you to create tenants that logically separate Applications, Users, Themes, Emails and more. This is great for white-labelling, multiple environments (dev, stage, prod) on a single deployment, and much more. Read this blog post to learn more about FusionAuth's multi-tenant support.
Every instance of FusionAuth is an isolated deployment with its own servers and database. This ensures that your data is completely isolated from other customers and applications. This means you can run FusionAuth on any server, anywhere in the world. Or let us host it for you.
FusionAuth supports MySQL or PostgreSQL databases. This means you pick the database server that best fits your needs. Most cloud database provides are also supported including Amazon's RDS and Google's Cloud SQL.
Every instance of FusionAuth is an isolated deployment with its own servers and database. This ensures that your data is completely isolated from other customers and applications. This means you can run FusionAuth on any server, anywhere in the world. Or let us host it for you.
FusionAuth supports MySQL or PostgreSQL databases. This means you pick the database server that best fits your needs. Most cloud database provides are also supported including Amazon's RDS and Google's Cloud SQL.


rfc2109
Press here
to go to the top of the rfc 'tree'.
Network Working Group D. Kristol
Request for Comments: 2109 Bell Laboratories, Lucent Technologies
Category: Standards Track L. Montulli
Netscape Communications
February 1997
HTTP State Management Mechanism
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
1. ABSTRACT
This document specifies a way to create a stateful session with HTTP
requests and responses. It describes two new headers, Cookie and
Set-Cookie, which carry state information between participating
origin servers and user agents. The method described here differs
from Netscape's Cookie proposal, but it can interoperate with
HTTP/1.0 user agents that use Netscape's method. (See the HISTORICAL
section.)
2. TERMINOLOGY
The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.0 specification.
Fully-qualified host name (FQHN) means either the fully-qualified
domain name (FQDN) of a host (i.e., a completely specified domain
name ending in a top-level domain such as .com or .uk), or the
numeric Internet Protocol (IP) address of a host. The fully
qualified domain name is preferred; use of numeric IP addresses is
strongly discouraged.
The terms request-host and request-URI refer to the values the client
would send to the server as, respectively, the host (but not port)
and abs_path portions of the absoluteURI (http_URL) of the HTTP
request line. Note that request-host must be a FQHN.
Kristol & Montulli Standards Track [Page 1]
RFC 2109 HTTP State Management Mechanism February 1997
Hosts names can be specified either as an IP address or a FQHN
string. Sometimes we compare one host name with another. Host A's
name domain-matches host B's if
* both host names are IP addresses and their host name strings match
exactly; or
* both host names are FQDN strings and their host name strings match
exactly; or
* A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Note that domain-match is not a commutative operation: a.b.c.com
domain-matches .c.com, but not the reverse.
Because it was used in Netscape's original implementation of state
management, we will use the term cookie to refer to the state
information that passes between an origin server and user agent, and
that gets stored by the user agent.
3. STATE AND SESSIONS
This document describes a way to create stateful sessions with HTTP
requests and responses. Currently, HTTP servers respond to each
client request without relating that request to previous or
subsequent requests; the technique allows clients and servers that
wish to exchange state information to place HTTP requests and
responses within a larger context, which we term a "session". This
context might be used to create, for example, a "shopping cart", in
which user selections can be aggregated before purchase, or a
magazine browsing system, in which a user's previous reading affects
which offerings are presented.
There are, of course, many different potential contexts and thus many
different potential types of session. The designers' paradigm for
sessions created by the exchange of cookies has these key attributes:
1. Each session has a beginning and an end.
2. Each session is relatively short-lived.
3. Either the user agent or the origin server may terminate a
session.
4. The session is implicit in the exchange of state information.
Kristol & Montulli Standards Track [Page 2]
RFC 2109 HTTP State Management Mechanism February 1997
4. OUTLINE
We outline here a way for an origin server to send state information
to the user agent, and for the user agent to return the state
information to the origin server. The goal is to have a minimal
impact on HTTP and user agents. Only origin servers that need to
maintain sessions would suffer any significant impact, and that
impact can largely be confined to Common Gateway Interface (CGI)
programs, unless the server provides more sophisticated state
management support. (See Implementation Considerations, below.)
4.1 Syntax: General
The two state management headers, Set-Cookie and Cookie, have common
syntactic properties involving attribute-value pairs. The following
grammar uses the notation, and tokens DIGIT (decimal digits) and
token (informally, a sequence of non-special, non-white space
characters) from the HTTP/1.1 specification [RFC 2068] to describe
their syntax.
av-pairs = av-pair *(";" av-pair)
av-pair = attr ["=" value] ; optional value
attr = token
value = word
word = token | quoted-string
Attributes (names) (attr) are case-insensitive. White space is
permitted between tokens. Note that while the above syntax
description shows value as optional, most attrs require them.
NOTE: The syntax above allows whitespace between the attribute and
the = sign.
4.2 Origin Server Role
4.2.1 General
The origin server initiates a session, if it so desires. (Note that
"session" here does not refer to a persistent network connection but
to a logical session created from HTTP requests and responses. The
presence or absence of a persistent connection should have no effect
on the use of cookie-derived sessions). To initiate a session, the
origin server returns an extra response header to the client, Set-
Cookie. (The details follow later.)
A user agent returns a Cookie request header (see below) to the
origin server if it chooses to continue a session. The origin server
may ignore it or use it to determine the current state of the
Kristol & Montulli Standards Track [Page 3]
RFC 2109 HTTP State Management Mechanism February 1997
session. It may send back to the client a Set-Cookie response header
with the same or different information, or it may send no Set-Cookie
header at all. The origin server effectively ends a session by
sending the client a Set-Cookie header with Max-Age=0.
Servers may return a Set-Cookie response headers with any response.
User agents should send Cookie request headers, subject to other
rules detailed below, with every request.
An origin server may include multiple Set-Cookie headers in a
response. Note that an intervening gateway could fold multiple such
headers into a single header.
4.2.2 Set-Cookie Syntax
The syntax for the Set-Cookie response header is
set-cookie = "Set-Cookie:" cookies
cookies = 1#cookie
cookie = NAME "=" VALUE *(";" cookie-av)
NAME = attr
VALUE = value
cookie-av = "Comment" "=" value
| "Domain" "=" value
| "Max-Age" "=" value
| "Path" "=" value
| "Secure"
| "Version" "=" 1*DIGIT
Informally, the Set-Cookie response header comprises the token Set-
Cookie:, followed by a comma-separated list of one or more cookies.
Each cookie begins with a NAME=VALUE pair, followed by zero or more
semi-colon-separated attribute-value pairs. The syntax for
attribute-value pairs was shown earlier. The specific attributes and
the semantics of their values follows. The NAME=VALUE attribute-
value pair must come first in each cookie. The others, if present,
can occur in any order. If an attribute appears more than once in a
cookie, the behavior is undefined.
NAME=VALUE
Required. The name of the state information ("cookie") is NAME,
and its value is VALUE. NAMEs that begin with $ are reserved for
other uses and must not be used by applications.
Kristol & Montulli Standards Track [Page 4]
RFC 2109 HTTP State Management Mechanism February 1997
The VALUE is opaque to the user agent and may be anything the
origin server chooses to send, possibly in a server-selected
printable ASCII encoding. "Opaque" implies that the content is of
interest and relevance only to the origin server. The content
may, in fact, be readable by anyone that examines the Set-Cookie
header.
Comment=comment
Optional. Because cookies can contain private information about a
user, the Cookie attribute allows an origin server to document its
intended use of a cookie. The user can inspect the information to
decide whether to initiate or continue a session with this cookie.
Domain=domain
Optional. The Domain attribute specifies the domain for which the
cookie is valid. An explicitly specified domain must always start
with a dot.
Max-Age=delta-seconds
Optional. The Max-Age attribute defines the lifetime of the
cookie, in seconds. The delta-seconds value is a decimal non-
negative integer. After delta-seconds seconds elapse, the client
should discard the cookie. A value of zero means the cookie
should be discarded immediately.
Path=path
Optional. The Path attribute specifies the subset of URLs to
which this cookie applies.
Secure
Optional. The Secure attribute (with no value) directs the user
agent to use only (unspecified) secure means to contact the origin
server whenever it sends back this cookie.
The user agent (possibly under the user's control) may determine
what level of security it considers appropriate for "secure"
cookies. The Secure attribute should be considered security
advice from the server to the user agent, indicating that it is in
the session's interest to protect the cookie contents.
Version=version
Required. The Version attribute, a decimal integer, identifies to
which version of the state management specification the cookie
conforms. For this specification, Version=1 applies.
Kristol & Montulli Standards Track [Page 5]
RFC 2109 HTTP State Management Mechanism February 1997
4.2.3 Controlling Caching
An origin server must be cognizant of the effect of possible caching
of both the returned resource and the Set-Cookie header. Caching
"public" documents is desirable. For example, if the origin server
wants to use a public document such as a "front door" page as a
sentinel to indicate the beginning of a session for which a Set-
Cookie response header must be generated, the page should be stored
in caches "pre-expired" so that the origin server will see further
requests. "Private documents", for example those that contain
information strictly private to a session, should not be cached in
shared caches.
If the cookie is intended for use by a single user, the Set-cookie
header should not be cached. A Set-cookie header that is intended to
be shared by multiple users may be cached.
The origin server should send the following additional HTTP/1.1
response headers, depending on circumstances:
* To suppress caching of the Set-Cookie header: Cache-control: no-
cache="set-cookie".
and one of the following:
* To suppress caching of a private document in shared caches: Cache-
control: private.
* To allow caching of a document and require that it be validated
before returning it to the client: Cache-control: must-revalidate.
* To allow caching of a document, but to require that proxy caches
(not user agent caches) validate it before returning it to the
client: Cache-control: proxy-revalidate.
* To allow caching of a document and request that it be validated
before returning it to the client (by "pre-expiring" it):
Cache-control: max-age=0. Not all caches will revalidate the
document in every case.
HTTP/1.1 servers must send Expires: old-date (where old-date is a
date long in the past) on responses containing Set-Cookie response
headers unless they know for certain (by out of band means) that
there are no downsteam HTTP/1.0 proxies. HTTP/1.1 servers may send
other Cache-Control directives that permit caching by HTTP/1.1
proxies in addition to the Expires: old-date directive; the Cache-
Control directive will override the Expires: old-date for HTTP/1.1
proxies.
Kristol & Montulli Standards Track [Page 6]
RFC 2109 HTTP State Management Mechanism February 1997
4.3 User Agent Role
4.3.1 Interpreting Set-Cookie
The user agent keeps separate track of state information that arrives
via Set-Cookie response headers from each origin server (as
distinguished by name or IP address and port). The user agent
applies these defaults for optional attributes that are missing:
VersionDefaults to "old cookie" behavior as originally specified by
Netscape. See the HISTORICAL section.
Domain Defaults to the request-host. (Note that there is no dot at
the beginning of request-host.)
Max-AgeThe default behavior is to discard the cookie when the user
agent exits.
Path Defaults to the path of the request URL that generated the
Set-Cookie response, up to, but not including, the
right-most /.
Secure If absent, the user agent may send the cookie over an
insecure channel.
4.3.2 Rejecting Cookies
To prevent possible security or privacy violations, a user agent
rejects a cookie (shall not store its information) if any of the
following is true:
* The value for the Path attribute is not a prefix of the request-
URI.
* The value for the Domain attribute contains no embedded dots or
does not start with a dot.
* The value for the request-host does not domain-match the Domain
attribute.
* The request-host is a FQDN (not IP address) and has the form HD,
where D is the value of the Domain attribute, and H is a string
that contains one or more dots.
Examples:
* A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.
Kristol & Montulli Standards Track [Page 7]
RFC 2109 HTTP State Management Mechanism February 1997
* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.
* A Set-Cookie with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.
* A Set-Cookie with Domain=ajax.com will be rejected because the
value for Domain does not begin with a dot.
4.3.3 Cookie Management
If a user agent receives a Set-Cookie response header whose NAME is
the same as a pre-existing cookie, and whose Domain and Path
attribute values exactly (string) match those of a pre-existing
cookie, the new cookie supersedes the old. However, if the Set-
Cookie has a value for Max-Age of zero, the (old and new) cookie is
discarded. Otherwise cookies accumulate until they expire (resources
permitting), at which time they are discarded.
Because user agents have finite space in which to store cookies, they
may also discard older cookies to make space for newer ones, using,
for example, a least-recently-used algorithm, along with constraints
on the maximum number of cookies that each origin server may set.
If a Set-Cookie response header includes a Comment attribute, the
user agent should store that information in a human-readable form
with the cookie and should display the comment text as part of a
cookie inspection user interface.
User agents should allow the user to control cookie destruction. An
infrequently-used cookie may function as a "preferences file" for
network applications, and a user may wish to keep it even if it is
the least-recently-used cookie. One possible implementation would be
an interface that allows the permanent storage of a cookie through a
checkbox (or, conversely, its immediate destruction).
Privacy considerations dictate that the user have considerable
control over cookie management. The PRIVACY section contains more
information.
4.3.4 Sending Cookies to the Origin Server
When it sends a request to an origin server, the user agent sends a
Cookie request header to the origin server if it has cookies that are
applicable to the request, based on
* the request-host;
Kristol & Montulli Standards Track [Page 8]
RFC 2109 HTTP State Management Mechanism February 1997
* the request-URI;
* the cookie's age.
The syntax for the header is:
cookie = "Cookie:" cookie-version
1*((";" | ",") cookie-value)
cookie-value = NAME "=" VALUE [";" path] [";" domain]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
path = "$Path" "=" value
domain = "$Domain" "=" value
The value of the cookie-version attribute must be the value from the
Version attribute, if any, of the corresponding Set-Cookie response
header. Otherwise the value for cookie-version is 0. The value for
the path attribute must be the value from the Path attribute, if any,
of the corresponding Set-Cookie response header. Otherwise the
attribute should be omitted from the Cookie request header. The
value for the domain attribute must be the value from the Domain
attribute, if any, of the corresponding Set-Cookie response header.
Otherwise the attribute should be omitted from the Cookie request
header.
Note that there is no Comment attribute in the Cookie request header
corresponding to the one in the Set-Cookie response header. The user
agent does not return the comment information to the origin server.
The following rules apply to choosing applicable cookie-values from
among all the cookies the user agent has.
Domain Selection
The origin server's fully-qualified host name must domain-match
the Domain attribute of the cookie.
Path Selection
The Path attribute of the cookie must match a prefix of the
request-URI.
Max-Age Selection
Cookies that have expired should have been discarded and thus
are not forwarded to an origin server.
Kristol & Montulli Standards Track [Page 9]
RFC 2109 HTTP State Management Mechanism February 1997
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific. Ordering with respect to other
attributes (e.g., Domain) is unspecified.
Note: For backward compatibility, the separator in the Cookie header
is semi-colon (;) everywhere. A server should also accept comma (,)
as the separator between cookie-values for future compatibility.
4.3.5 Sending Cookies in Unverifiable Transactions
Users must have control over sessions in order to ensure privacy.
(See PRIVACY section below.) To simplify implementation and to
prevent an additional layer of complexity where adequate safeguards
exist, however, this document distinguishes between transactions that
are verifiable and those that are unverifiable. A transaction is
verifiable if the user has the option to review the request-URI prior
to its use in the transaction. A transaction is unverifiable if the
user does not have that option. Unverifiable transactions typically
arise when a user agent automatically requests inlined or embedded
entities or when it resolves redirection (3xx) responses from an
origin server. Typically the origin transaction, the transaction
that the user initiates, is verifiable, and that transaction may
directly or indirectly induce the user agent to make unverifiable
transactions.
When it makes an unverifiable transaction, a user agent must enable a
session only if a cookie with a domain attribute D was sent or
received in its origin transaction, such that the host name in the
Request-URI of the unverifiable transaction domain-matches D.
This restriction prevents a malicious service author from using
unverifiable transactions to induce a user agent to start or continue
a session with a server in a different domain. The starting or
continuation of such sessions could be contrary to the privacy
expectations of the user, and could also be a security problem.
User agents may offer configurable options that allow the user agent,
or any autonomous programs that the user agent executes, to ignore
the above rule, so long as these override options default to "off".
Many current user agents already provide a review option that would
render many links verifiable. For instance, some user agents display
the URL that would be referenced for a particular link when the mouse
pointer is placed over that link. The user can therefore determine
whether to visit that site before causing the browser to do so.
(Though not implemented on current user agents, a similar technique
could be used for a button used to submit a form -- the user agent
Kristol & Montulli Standards Track [Page 10]
RFC 2109 HTTP State Management Mechanism February 1997
could display the action to be taken if the user were to select that
button.) However, even this would not make all links verifiable; for
example, links to automatically loaded images would not normally be
subject to "mouse pointer" verification.
Many user agents also provide the option for a user to view the HTML
source of a document, or to save the source to an external file where
it can be viewed by another application. While such an option does
provide a crude review mechanism, some users might not consider it
acceptable for this purpose.
4.4 How an Origin Server Interprets the Cookie Header
A user agent returns much of the information in the Set-Cookie header
to the origin server when the Path attribute matches that of a new
request. When it receives a Cookie header, the origin server should
treat cookies with NAMEs whose prefix is $ specially, as an attribute
for the adjacent cookie. The value for such a NAME is to be
interpreted as applying to the lexically (left-to-right) most recent
cookie whose name does not have the $ prefix. If there is no
previous cookie, the value applies to the cookie mechanism as a
whole. For example, consider the cookie
Cookie: $Version="1"; Customer="WILE_E_COYOTE";
$Path="/acme"
$Version applies to the cookie mechanism as a whole (and gives the
version number for the cookie mechanism). $Path is an attribute
whose value (/acme) defines the Path attribute that was used when the
Customer cookie was defined in a Set-Cookie response header.
4.5 Caching Proxy Role
One reason for separating state information from both a URL and
document content is to facilitate the scaling that caching permits.
To support cookies, a caching proxy must obey these rules already in
the HTTP specification:
* Honor requests from the cache, if possible, based on cache validity
rules.
* Pass along a Cookie request header in any request that the proxy
must make of another server.
* Return the response to the client. Include any Set-Cookie response
header.
Kristol & Montulli Standards Track [Page 11]
RFC 2109 HTTP State Management Mechanism February 1997
* Cache the received response subject to the control of the usual
headers, such as Expires, Cache-control: no-cache, and Cache-
control: private,
* Cache the Set-Cookie subject to the control of the usual header,
Cache-control: no-cache="set-cookie". (The Set-Cookie header
should usually not be cached.)
Proxies must not introduce Set-Cookie (Cookie) headers of their own
in proxy responses (requests).
5. EXAMPLES
5.1 Example 1
Most detail of request and response headers has been omitted. Assume
the user agent has no stored cookies.
1. User Agent -> Server
POST /acme/login HTTP/1.1
[form data]
User identifies self via a form.
2. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Customer="WILE_E_COYOTE"; Version="1"; Path="/acme"
Cookie reflects user's identity.
3. User Agent -> Server
POST /acme/pickitem HTTP/1.1
Cookie: $Version="1"; Customer="WILE_E_COYOTE"; $Path="/acme"
[form data]
User selects an item for "shopping basket."
4. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
Shopping basket contains an item.
Kristol & Montulli Standards Track [Page 12]
RFC 2109 HTTP State Management Mechanism February 1997
5. User Agent -> Server
POST /acme/shipping HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
[form data]
User selects shipping method from form.
6. Server -> User Agent
HTTP/1.1 200 OK
Set-Cookie: Shipping="FedEx"; Version="1"; Path="/acme"
New cookie reflects shipping method.
7. User Agent -> Server
POST /acme/process HTTP/1.1
Cookie: $Version="1";
Customer="WILE_E_COYOTE"; $Path="/acme";
Part_Number="Rocket_Launcher_0001"; $Path="/acme";
Shipping="FedEx"; $Path="/acme"
[form data]
User chooses to process order.
8. Server -> User Agent
HTTP/1.1 200 OK
Transaction is complete.
The user agent makes a series of requests on the origin server, after
each of which it receives a new cookie. All the cookies have the
same Path attribute and (default) domain. Because the request URLs
all have /acme as a prefix, and that matches the Path attribute, each
request contains all the cookies received so far.
5.2 Example 2
This example illustrates the effect of the Path attribute. All
detail of request and response headers has been omitted. Assume the
user agent has no stored cookies.
Imagine the user agent has received, in response to earlier requests,
the response headers
Kristol & Montulli Standards Track [Page 13]
RFC 2109 HTTP State Management Mechanism February 1997
Set-Cookie: Part_Number="Rocket_Launcher_0001"; Version="1";
Path="/acme"
and
Set-Cookie: Part_Number="Riding_Rocket_0023"; Version="1";
Path="/acme/ammo"
A subsequent request by the user agent to the (same) server for URLs
of the form /acme/ammo/... would include the following request
header:
Cookie: $Version="1";
Part_Number="Riding_Rocket_0023"; $Path="/acme/ammo";
Part_Number="Rocket_Launcher_0001"; $Path="/acme"
Note that the NAME=VALUE pair for the cookie with the more specific
Path attribute, /acme/ammo, comes before the one with the less
specific Path attribute, /acme. Further note that the same cookie
name appears more than once.
A subsequent request by the user agent to the (same) server for a URL
of the form /acme/parts/ would include the following request header:
Cookie: $Version="1"; Part_Number="Rocket_Launcher_0001"; $Path="/acme"
Here, the second cookie's Path attribute /acme/ammo is not a prefix
of the request URL, /acme/parts/, so the cookie does not get
forwarded to the server.
6. IMPLEMENTATION CONSIDERATIONS
Here we speculate on likely or desirable details for an origin server
that implements state management.
6.1 Set-Cookie Content
An origin server's content should probably be divided into disjoint
application areas, some of which require the use of state
information. The application areas can be distinguished by their
request URLs. The Set-Cookie header can incorporate information
about the application areas by setting the Path attribute for each
one.
The session information can obviously be clear or encoded text that
describes state. However, if it grows too large, it can become
unwieldy. Therefore, an implementor might choose for the session
information to be a key to a server-side resource. Of course, using
Kristol & Montulli Standards Track [Page 14]
RFC 2109 HTTP State Management Mechanism February 1997
a database creates some problems that this state management
specification was meant to avoid, namely:
1. keeping real state on the server side;
2. how and when to garbage-collect the database entry, in case the
user agent terminates the session by, for example, exiting.
6.2 Stateless Pages
Caching benefits the scalability of WWW. Therefore it is important
to reduce the number of documents that have state embedded in them
inherently. For example, if a shopping-basket-style application
always displays a user's current basket contents on each page, those
pages cannot be cached, because each user's basket's contents would
be different. On the other hand, if each page contains just a link
that allows the user to "Look at My Shopping Basket", the page can be
cached.
6.3 Implementation Limits
Practical user agent implementations have limits on the number and
size of cookies that they can store. In general, user agents' cookie
support should have no fixed limits. They should strive to store as
many frequently-used cookies as possible. Furthermore, general-use
user agents should provide each of the following minimum capabilities
individually, although not necessarily simultaneously:
* at least 300 cookies
* at least 4096 bytes per cookie (as measured by the size of the
characters that comprise the cookie non-terminal in the syntax
description of the Set-Cookie header)
* at least 20 cookies per unique host or domain name
User agents created for specific purposes or for limited-capacity
devices should provide at least 20 cookies of 4096 bytes, to ensure
that the user can interact with a session-based origin server.
The information in a Set-Cookie response header must be retained in
its entirety. If for some reason there is inadequate space to store
the cookie, it must be discarded, not truncated.
Applications should use as few and as small cookies as possible, and
they should cope gracefully with the loss of a cookie.
Kristol & Montulli Standards Track [Page 15]
RFC 2109 HTTP State Management Mechanism February 1997
6.3.1 Denial of Service Attacks
User agents may choose to set an upper bound on the number of cookies
to be stored from a given host or domain name or on the size of the
cookie information. Otherwise a malicious server could attempt to
flood a user agent with many cookies, or large cookies, on successive
responses, which would force out cookies the user agent had received
from other servers. However, the minima specified above should still
be supported.
7. PRIVACY
7.1 User Agent Control
An origin server could create a Set-Cookie header to track the path
of a user through the server. Users may object to this behavior as
an intrusive accumulation of information, even if their identity is
not evident. (Identity might become evident if a user subsequently
fills out a form that contains identifying information.) This state
management specification therefore requires that a user agent give
the user control over such a possible intrusion, although the
interface through which the user is given this control is left
unspecified. However, the control mechanisms provided shall at least
allow the user
* to completely disable the sending and saving of cookies.
* to determine whether a stateful session is in progress.
* to control the saving of a cookie on the basis of the cookie's
Domain attribute.
Such control could be provided by, for example, mechanisms
* to notify the user when the user agent is about to send a cookie
to the origin server, offering the option not to begin a session.
* to display a visual indication that a stateful session is in
progress.
* to let the user decide which cookies, if any, should be saved
when the user concludes a window or user agent session.
* to let the user examine the contents of a cookie at any time.
A user agent usually begins execution with no remembered state
information. It should be possible to configure a user agent never
to send Cookie headers, in which case it can never sustain state with
Kristol & Montulli Standards Track [Page 16]
RFC 2109 HTTP State Management Mechanism February 1997
an origin server. (The user agent would then behave like one that is
unaware of how to handle Set-Cookie response headers.)
When the user agent terminates execution, it should let the user
discard all state information. Alternatively, the user agent may ask
the user whether state information should be retained; the default
should be "no". If the user chooses to retain state information, it
would be restored the next time the user agent runs.
NOTE: User agents should probably be cautious about using files to
store cookies long-term. If a user runs more than one instance of
the user agent, the cookies could be commingled or otherwise messed
up.
7.2 Protocol Design
The restrictions on the value of the Domain attribute, and the rules
concerning unverifiable transactions, are meant to reduce the ways
that cookies can "leak" to the "wrong" site. The intent is to
restrict cookies to one, or a closely related set of hosts.
Therefore a request-host is limited as to what values it can set for
Domain. We consider it acceptable for hosts host1.foo.com and
host2.foo.com to share cookies, but not a.com and b.com.
Similarly, a server can only set a Path for cookies that are related
to the request-URI.
8. SECURITY CONSIDERATIONS
8.1 Clear Text
The information in the Set-Cookie and Cookie headers is unprotected.
Two consequences are:
1. Any sensitive information that is conveyed in them is exposed
to intruders.
2. A malicious intermediary could alter the headers as they travel
in either direction, with unpredictable results.
These facts imply that information of a personal and/or financial
nature should only be sent over a secure channel. For less sensitive
information, or when the content of the header is a database key, an
origin server should be vigilant to prevent a bad Cookie value from
causing failures.
Kristol & Montulli Standards Track [Page 17]
RFC 2109 HTTP State Management Mechanism February 1997
8.2 Cookie Spoofing
Proper application design can avoid spoofing attacks from related
domains. Consider:
1. User agent makes request to victim.cracker.edu, gets back
cookie session_id="1234" and sets the default domain
victim.cracker.edu.
2. User agent makes request to spoof.cracker.edu, gets back
cookie session-id="1111", with Domain=".cracker.edu".
3. User agent makes request to victim.cracker.edu again, and
passes
Cookie: $Version="1";
session_id="1234";
session_id="1111"; $Domain=".cracker.edu"
The server at victim.cracker.edu should detect that the second
cookie was not one it originated by noticing that the Domain
attribute is not for itself and ignore it.
8.3 Unexpected Cookie Sharing
A user agent should make every attempt to prevent the sharing of
session information between hosts that are in different domains.
Embedded or inlined objects may cause particularly severe privacy
problems if they can be used to share cookies between disparate
hosts. For example, a malicious server could embed cookie
information for host a.com in a URI for a CGI on host b.com. User
agent implementors are strongly encouraged to prevent this sort of
exchange whenever possible.
9. OTHER, SIMILAR, PROPOSALS
Three other proposals have been made to accomplish similar goals.
This specification is an amalgam of Kristol's State-Info proposal and
Netscape's Cookie proposal.
Brian Behlendorf proposed a Session-ID header that would be user-
agent-initiated and could be used by an origin server to track
"clicktrails". It would not carry any origin-server-defined state,
however. Phillip Hallam-Baker has proposed another client-defined
session ID mechanism for similar purposes.
Kristol & Montulli Standards Track [Page 18]
RFC 2109 HTTP State Management Mechanism February 1997
While both session IDs and cookies can provide a way to sustain
stateful sessions, their intended purpose is different, and,
consequently, the privacy requirements for them are different. A
user initiates session IDs to allow servers to track progress through
them, or to distinguish multiple users on a shared machine. Cookies
are server-initiated, so the cookie mechanism described here gives
users control over something that would otherwise take place without
the users' awareness. Furthermore, cookies convey rich, server-
selected information, whereas session IDs comprise user-selected,
simple information.
10. HISTORICAL
10.1 Compatibility With Netscape's Implementation
HTTP/1.0 clients and servers may use Set-Cookie and Cookie headers
that reflect Netscape's original cookie proposal. These notes cover
inter-operation between "old" and "new" cookies.
10.1.1 Extended Cookie Header
This proposal adds attribute-value pairs to the Cookie request header
in a compatible way. An "old" client that receives a "new" cookie
will ignore attributes it does not understand; it returns what it
does understand to the origin server. A "new" client always sends
cookies in the new form.
An "old" server that receives a "new" cookie will see what it thinks
are many cookies with names that begin with a $, and it will ignore
them. (The "old" server expects these cookies to be separated by
semi-colon, not comma.) A "new" server can detect cookies that have
passed through an "old" client, because they lack a $Version
attribute.
10.1.2 Expires and Max-Age
Netscape's original proposal defined an Expires header that took a
date value in a fixed-length variant format in place of Max-Age:
Wdy, DD-Mon-YY HH:MM:SS GMT
Note that the Expires date format contains embedded spaces, and that
"old" cookies did not have quotes around values. Clients that
implement to this specification should be aware of "old" cookies and
Expires.
Kristol & Montulli Standards Track [Page 19]
RFC 2109 HTTP State Management Mechanism February 1997
10.1.3 Punctuation
In Netscape's original proposal, the values in attribute-value pairs
did not accept "-quoted strings. Origin servers should be cautious
about sending values that require quotes unless they know the
receiving user agent understands them (i.e., "new" cookies). A
("new") user agent should only use quotes around values in Cookie
headers when the cookie's version(s) is (are) all compliant with this
specification or later.
In Netscape's original proposal, no whitespace was permitted around
the = that separates attribute-value pairs. Therefore such
whitespace should be used with caution in new implementations.
10.2 Caching and HTTP/1.0
Some caches, such as those conforming to HTTP/1.0, will inevitably
cache the Set-Cookie header, because there was no mechanism to
suppress caching of headers prior to HTTP/1.1. This caching can lead
to security problems. Documents transmitted by an origin server
along with Set-Cookie headers will usually either be uncachable, or
will be "pre-expired". As long as caches obey instructions not to
cache documents (following Expires: <a date in the past> or Pragma:
no-cache (HTTP/1.0), or Cache-control: no-cache (HTTP/1.1))
uncachable documents present no problem. However, pre-expired
documents may be stored in caches. They require validation (a
conditional GET) on each new request, but some cache operators loosen
the rules for their caches, and sometimes serve expired documents
without first validating them. This combination of factors can lead
to cookies meant for one user later being sent to another user. The
Set-Cookie header is stored in the cache, and, although the document
is stale (expired), the cache returns the document in response to
later requests, including cached headers.
11. ACKNOWLEDGEMENTS
This document really represents the collective efforts of the
following people, in addition to the authors: Roy Fielding, Marc
Hedlund, Ted Hardie, Koen Holtman, Shel Kaphan, Rohit Khare.
Kristol & Montulli Standards Track [Page 20]
RFC 2109 HTTP State Management Mechanism February 1997
12. AUTHORS' ADDRESSES
David M. Kristol
Bell Laboratories, Lucent Technologies
600 Mountain Ave. Room 2A-227
Murray Hill, NJ 07974
Phone:<PHONE_NUMBER>
Fax:<PHONE_NUMBER>
EMail<EMAIL_ADDRESS>Lou Montulli
Netscape Communications Corp.
501 E. Middlefield Rd.
Mountain View, CA 94043
Phone:<PHONE_NUMBER>
EMail<EMAIL_ADDRESS>Kristol & Montulli Standards Track [Page 21]


VSL // Dancing In Her Kitchen To Soul
* There are so many food blogs out there, but few are as charming as Vegetarian Ventures
today’s Very Short List:
food 18 Apr 2014
Claire Livia Lassam is a pastry chef, food writer, and photographer based in Vancouver BC. She runs the baking blog Livia Sweets
Subscribe
* I spend at least 20 minutes a day wanting to walk out of my life and into an Aran Goyoaga
* I cannot stop thinking about raising quails for eggs
http://link.nyobserver.com/516ca68465217dc6e1b9a3a61ja5a.bh6/U1BhSeYQk0HXOJ9lD0f02 very short list is a
delightful e-mail that shares
cultural gems from a
different curator every day.
If you have any problems reading this e-mail, click here
http://link.nyobserver.com/516ca68465217dc6e1b9a3a61ja5a.bh6/U1BhSeYQk0HXOJ9lE44b7
Subscribe
Forward
My Account
Unsubscribe
style 16 Apr 2014
Jewelry designer Katie Schloss shares her latest inspirations.
culture 14 Apr 2014
Lauren Cerand offers a look inside some creative worlds.
food 11 Apr 2014
Sebastien Park on foods with a mission.
Editorial Policy
Privacy Policy
Contact Us
Press
Terms + Conditions
very fine print: ©2014
Observer VSL LLC.
321 West 44th Street, 6th Floor
New York, NY 10036 USA
All rights reserved.
Questions?<PHONE_NUMBER>.
This message was intended for<EMAIL_ADDRESS>If you believe this has been sent to you in error, please safely unsubscribe


|
| subroutine | init (this, nDim) |
| |
| subroutine | copy (this, other) |
| |
| subroutine | destroy (this) |
| |
| character(len=200) function | str (this) |
| |
| subroutine | show (this, unit) |
| |
| subroutine | setrange (this, dim, range) |
| |
| subroutine | buildsample (this, sample, targetDist, delta, rMin) |
| | Build a random sample. More...
|
| |
| subroutine | uniform (this, sample, A) |
| | Build a random sample using an uniform distribution. More...
|
| |
| subroutine | uniformellipsoid (this, sample, A) |
| | Build a random sample using an uniform distribution. More...
|
| |
| subroutine | normal (this, sample, stdev, cov, aver) |
| | Build a random sample using an normal distribution. More...
|
| |
| real(8) function | dist (r) |
| | Build a random sample using an uniform distribution. More...
|
| |
Definition at line 30 of file RandomSampler.f90.
| subroutine randomsampler_::buildsample |
( |
class(randomsampler) |
this, |
|
|
real(8), dimension(:,:) |
sample, |
|
|
procedure(prototypefunction) |
targetDist, |
|
|
real(8), optional |
delta, |
|
|
real(8), optional |
rMin |
|
) |
| |
|
private |
Build a random sample.
- Todo:
- Este es el algoritmmo de Metropolis, hay que dar la posibilidad de usar cualquier algoritmo por seleccion, abajo esta es de aceptacion-rechazo aunque esta en C++ hay que modificarlo
Definition at line 178 of file RandomSampler.f90.
| real(8) function randomsampler_::dist |
( |
real(8), dimension(:), intent(in) |
r | ) |
|
|
private |
Build a random sample using an uniform distribution.
- Parameters
-
| [out] | sample | In this array will will store the generated random numbers it should be allocated in advance This is neccesary only for RandomSampler_test() |
Definition at line 548 of file RandomSampler.f90.
| subroutine randomsampler_::init |
( |
class(randomsampler) |
this, |
|
|
integer |
nDim |
|
) |
| |
|
private |
| subroutine randomsampler_::normal |
( |
class(randomsampler) |
this, |
|
|
real(8), dimension(:,:) |
sample, |
|
|
real(8), dimension(:), intent(in), optional |
stdev, |
|
|
real(8), dimension(:,:), intent(in), optional |
cov, |
|
|
real(8), dimension(:), intent(in), optional |
aver |
|
) |
| |
|
private |
Build a random sample using an normal distribution.
- Parameters
-
| [out] | sample | In this array will will store the generated random numbers it should be allocated in advance |
Definition at line 439 of file RandomSampler.f90.
| subroutine, public randomsampler_::randomsampler_test |
( |
| ) |
|
| subroutine randomsampler_::setrange |
( |
class(randomsampler) |
this, |
|
|
integer |
dim, |
|
|
real(8), dimension(2) |
range |
|
) |
| |
|
private |
| subroutine randomsampler_::show |
( |
class(randomsampler) |
this, |
|
|
integer, intent(in), optional |
unit |
|
) |
| |
|
private |
| character(len=200) function randomsampler_::str |
( |
class(randomsampler) |
this | ) |
|
|
private |
| subroutine randomsampler_::uniform |
( |
class(randomsampler) |
this, |
|
|
real(8), dimension(:,:) |
sample, |
|
|
real(8), dimension(:,:), intent(in), optional |
A |
|
) |
| |
|
private |
Build a random sample using an uniform distribution.
- Parameters
-
| [out] | sample | In this array will will store the generated random numbers it should be allocated in advance |
Definition at line 307 of file RandomSampler.f90.
| subroutine randomsampler_::uniformellipsoid |
( |
class(randomsampler) |
this, |
|
|
real(8), dimension(:,:) |
sample, |
|
|
real(8), dimension(:,:), intent(in), optional |
A |
|
) |
| |
|
private |
Build a random sample using an uniform distribution.
- Parameters
-
| [out] | sample | In this array will will store the generated random numbers it should be allocated in advance |
Definition at line 367 of file RandomSampler.f90.
| real(8), dimension(:), allocatable, private randomsampler_::extraparamsdist |
|
private |
The documentation for this module was generated from the following file:


Bonang Matheba explains why she wears a huge rock on her ring finger
Nkosazana Ngwadla
Cape Town - South Africa’s queen of, well, everything, manages to trend no matter what she does.
From her sexy holiday snaps, to the funny phrases she uses on her show (admit it, you’ve also used “moghel” and “Champagne darling” at some point), fans are quick to spread the word. Now, her interview on The Breakfast Club – an American radio show based in New York City and hosted by DJ Envy, Angela Yee and Charlamagne Tha God – have people talking.
Queen B and the show’s hosts discussed several topics, but what caught the attention of local fans was the discussion around marriage and kids. Asked if she was married, Bonang said no, but explained why she wears a huge rock on her ring finger.
Read More: Bonang Matheba set to return to SABC1 in 2020 in new TV project
“It’s called ‘stop nonsense’,” she said, pausing while the hosts laughed. “I swear, in South Africa a wall, a barricade that fences your house, is called a stop nonsense,” she said.
When asked what she does when she wants attention from the right guy, she responded with: “Men actually don’t approach me. They don’t, and it’s okay. But I will eventually have children and get married when I’m done – when I find a nice guy. I think men in general are a tough category, they’re a very tough wall to break down. Men are strange, hey,” she said.
When Charlamagne Tha God jokingly said he used to be a man but turned into a god, Bonang laughed in the most contagious way and said, “Modimo ke o (Here’s a god).”
Queen B’s fans on Twitter were impressed with the way she conducted herself, and with what she said. But more than anything, they were impressed with how she didn’t try to sound American – she kept her South African accent and even made some exclamations the way she does on her reality show, Being Bonang.


DYT
0x740623d2c797b7d8d1ecb98e9b4afcf99ec31e14
(ERC20 E.V.M. Contract)
D.Y.T. : Price (in Ethereum / DYT)
D.Y.T. : Market Capitalization (in Ethereum)
D.Y.T. : Circulating Supply
ℹ
DoYourTip (D.Y.T.) is a deflationary token.
With each on-chain transaction, 2% of the transferred amount gets burned!
You are viewing the
Archived
Edition.
Refetch
Live
Edition
: : : : OR : : : :
View
Archived
versions
19th August, 2020
15th July, 2020


Résume
Experience
Student Assistant
RIT ITS Communications Support
2017 - Present
- Responsible for attending calls and opening service tickets for customers.
- Management of network data activations, modifications, etc.
- Creating, moving, removing cable paths from the switch room
Software Development Intern
IB Systems
Summers 2015, 2016
- Worked collaboratively with my coworkers on several projects such as websites, web apps, databases, etc.
- Attended meetings with the project managers to work on project plans, achieving goals, brainstorming, etc.
- Responsible for updating the company’s website, adding new content and maintain it.
Summer Program Intern
Banco BHD León
Summers 2012, 2013
- Assigned to work on the bank’s technical support department repairing computers.
- Assisted employees with troubleshooting their computers both through calls and in person.
Student Worker
Ben & Jerry's
March 2016 - May 2016
- Attended to customer’s orders, answered their inquiries, and charged them through the cashier.
- Worked in carts outside the store serving customers participating in events such as Imagine RIT, Tora-Con, etc.
Student Worker
Dining Commons
September 2016 - December 2016
- Was assigned to various shifts such as grill server, cashier, dining room, dinner entrée, etc.
- Worked directly with supervisors and managers in order to comply best with customer’s demands.
Skills
Technical
- Programming Languages: C++, C, C#, Java, SQL, Python, HTML5, CSS3, JavaScript
- Frameworks: ASP.NET MVC, Entity Framework, Bootstrap, Django
- Tools: Visual Studio, Jetbrains IDEs, Adobe Creative Suite
Language
- Bilingual; Fluent in Spanish and English; Basic knowledge of French


Release notes
1.43c
- Fixed a crash on OpenGL ES3.0 in iOS
1.43b
- Fixed a bug that multithread rendering crashes an applications
1.41b
- Fixed a bug that 3D model is not shown in Mac
1.41
- Fixed a bug that effects can not be played if .. is included in the file path
- Fixed a bug that rendering became wrong when used with VR
- Fixed a bug that the effect was not released actually when calling Release function
1.40
- Distortion specification is changed.
- Added functions
1.30
- Distortion specification is changed.
- Coordinate system specification is changed.
1.23
- [Windows] Fixed to correctly draw with Unity 5.5β
- [macOS] Supported to OpenGLCore environment
- Increased default number of instances and quads
1.22
- [Android] Fixed problem that not occasionally displayed effects
- Supported to culling mask
1.21
- Supported loading from AssetBundle
- [WebGL] Supported WebGL target build
- Fixed bug that track type effects are not rendered
- Added SetTargetLocation to EffekseerEmitter and EffekseerHandle
- Added paused and shown to EffekseerEmitter
- Added help contents
- Added reference manual
1.20
- Supports distortion effects
- Added StopRoot() to EffekseerEmitter and EffekseerHandle
- Changed to update processing with LateUpdate
- Fixed bug when releasing texture
- [iOS] Changed to output errors when executed in Metal environment
1.10b
- [Windows] Fixed to be able to draw correctly with Deferred Rendering
- [Mac] Fixed to be able to draw correctly with Deferred Rendering
- [Android] Added beta version
- [iOS] Added beta version
1.10a
- [Windows] Fixed crash of x86 build app
1.10
- Change resource files place to Resources/Effekseer
- Change resource loading to Resources.Load()
- Change audio playback to Unity standard Audio
- Change texture loading to use Unity standard Texture2D
1.01
- Support new specification of Native Plugin of Unity 5.2


{% extends "templates/web.html" %} {% block page_content %}
ID: {{ name }}
Welcome, {{ first_name }} to My Library
First Name: {{ first_name }}
Last Name: {{ last_name }}
Email Address: {{ email_address }}
Tel: {{ phone }}


$ bin/pie-factory --help
$ bin/pie-factory -h
$ bin/pie-factory help
usage: pie-factory [options] [commands]
You have inherited a pie factory. Use your powers wisely.
 Valid values for <pie> are apple,
rhubarb, or mud.
OPTIONS
-a, --angrily Curse the target after throwing the pie
-s, --speed Throw the pie this many mph
-h, --help Show this message
$ bin/pie-factory recipe --help
$ bin/pie-factory recipe -h
$ bin/pie-factory recipe
$ bin/pie-factory help recipe
Subcommands for: piefactory recipe
pie-factory recipe list List pie recipes
pie-factory recipe add <recipe> Display a recipe
pie-factory recipe delete <recipe> Add a recipe
pie-factory recipe show <recipe> Delete a recipe
~/code/pie-factory $ tree
.
├── bin
│ └── pie-factory
└── lib
├── PieFactory
│ └── Cmd
│ ├── Bake.pm
│ ├── Eat.pm
│ ├── Help.pm
│ ├── Recipe
│ │ ├── Add.pm
│ │ ├── Delete.pm
│ │ ├── List.pm
│ │ └── Show.pm
│ └── Throw.pm
└── PieFactory.pm
5 directories, 10 files
$ pie-factory throw rhubarb-pie Batman
# inside bin/pie-factory:
use MooX::Commander;
my $commander = MooX::Commander->new(
base_class => 'PieFactory',
class_prefix => 'Cmd', # optional, default value is 'Cmd'
);
$commander->dispatch(argv => \@ARGV);
package PieFactory::Cmd::Throw;
use Moo;
sub go {
my ($self, $pie, $target) = @_;
# print usage and then exit unsuccessfully
$self->usage() unless $pie && $target;
# print "Not a valid value",
# print usage, and exit unsuccessfully
$self->usage("Not a valid value for <pie>")
unless $pie eq 'rhubarb-pie';
$self->throw($pie => $target);
}
# Print usage and exit unsuccessfully.
sub usage {
my ($self, $msg) = @_;
print $shift, "\n" if $msg;
print "usage: pie-factory throw <pie> <target> [options]...";
exit 1;
}
package PieFactory::Cmd::Throw;
use Moo;
with 'MooX::Commander::HasOptions';
sub go {
my ($self, $pie, $target) = @_;
# print usage and then exit unsuccessfully
$self->usage() unless $pie && $target;
# print "Not a valid value",
# print usage, and exit unsuccessfully
$self->usage("Not a valid value for <pie>")
unless $pie eq 'rhubarb-pie';
$self->throw($pie => $target);
}
# Print usage and exit unsuccessfully.
sub usage { "usage: pie-factory throw <pie> <target> [options]..."; }
package PieFactory::Cmd::Throw;
use Moo;
with 'MooX::Commander::HasOptions';
sub go {
my ($self, $pie, $target) = @_;
# print usage and then exit unsuccessfully
$self->usage() unless $pie && $target;
# print "Not a valid value",
# print usage, and exit unsuccessfully
$self->usage("Not a valid value for <pie>")
unless $pie eq 'rhubarb-pie';
$self->curse_loudly() if $self->options->{angrily};
$self->throw($pie => $target, $self->options->{speed});
}
# Print usage and exit unsuccessfully.
sub usage { "usage: pie-factory throw <pie> <target> [options]..." }
# This array is used to configure Getopt::Long
sub _build_options {(
'angrily|a',
'speed|s=i',
)}
package PieFactory::Cmd::Recipes;
use Moo;
with 'MooX::Commander::HasSubcommands';
package PieFactory::Cmd::Recipes;
use Moo;
with 'MooX::Commander::HasSubcommands';
usage { "Subcommands for: piefactory recipes..." }
Create subcommand classes the same way you would build any command class.
package PieFactory::Cmd::Help;
use Moo;
with 'MooX::Commander::IsaHelpCommand';
package PieFactory::Cmd::Help;
use Moo;
with 'MooX::Commander::IsaHelpCommand';
sub usage { "usage: pie-factory [options] [commands]..." }
MooX::Commander->new(...)->dispatch(...)
with 'MooX::Commander::HasOptions'
with 'MooX::Commander::HasSubcommands';
with 'MooX::Commander::IsaHelpCommand';


| Top |
Functions
Description
Multivariate Normal distribution which uses the covariance matrix as input. It should be used with its companion object NcmModelMVND.
Functions
ncm_data_gauss_cov_mvnd_new ()
NcmDataGaussCovMVND *
ncm_data_gauss_cov_mvnd_new (const guint dim
);
Creates a new dim
-dimensional MVND.
ncm_data_gauss_cov_mvnd_new_full ()
NcmDataGaussCovMVND * ncm_data_gauss_cov_mvnd_new_full (const guint dim
,const gdouble sigma_min
,const gdouble sigma_max
,const gdouble cor_level
,const gdouble mean_min
,const gdouble mean_max
,NcmRNG *rng
);
Creates a new dim
-dimensional MVND and generate using rng
a mean
and correlation matrix using the parameters above.
Parameters
dim |
dimension of the MVND |
|
sigma_min |
minimum value of $\sigma_i$ |
|
sigma_max |
maximum value of $\sigma_i$ |
|
cor_level |
correlation level |
|
mean_min |
minimum mean $\mu_i$ |
|
mean_max |
maximum mean $\mu_i$ |
|
rng |
a NcmRNG |
ncm_data_gauss_cov_mvnd_ref ()
NcmDataGaussCovMVND *
ncm_data_gauss_cov_mvnd_ref (NcmDataGaussCovMVND *data_mvnd
);
Increases the reference count of data_mvnd
by one.
ncm_data_gauss_cov_mvnd_free ()
void
ncm_data_gauss_cov_mvnd_free (NcmDataGaussCovMVND *data_mvnd
);
Decreases the reference count of data_mvnd
by one.
ncm_data_gauss_cov_mvnd_clear ()
void
ncm_data_gauss_cov_mvnd_clear (NcmDataGaussCovMVND **data_mvnd
);
If data_mvnd
is different from NULL, decreases the reference count of
data_mvnd
by one and sets data_mvnd
to NULL.
ncm_data_gauss_cov_mvnd_gen_cov_mean ()
void ncm_data_gauss_cov_mvnd_gen_cov_mean (NcmDataGaussCovMVND *data_mvnd
,const gdouble sigma_min
,const gdouble sigma_max
,const gdouble cor_level
,const gdouble mean_min
,const gdouble mean_max
,NcmRNG *rng
);
Generates using rng
the mean and correlation matrix using
the parameters above.
Parameters
data_mvnd |
||
sigma_min |
minimum value of $\sigma_i$ |
|
sigma_max |
maximum value of $\sigma_i$ |
|
cor_level |
correlation level |
|
mean_min |
minimum mean $\mu_i$ |
|
mean_max |
maximum mean $\mu_i$ |
|
rng |
a NcmRNG |
ncm_data_gauss_cov_mvnd_set_cov_mean ()
void ncm_data_gauss_cov_mvnd_set_cov_mean (NcmDataGaussCovMVND *data_mvnd
,NcmVector *mean
,NcmMatrix *cov
);
Sets the mean and covariance of data_mvnd
.
ncm_data_gauss_cov_mvnd_peek_mean ()
NcmVector *
ncm_data_gauss_cov_mvnd_peek_mean (NcmDataGaussCovMVND *data_mvnd
);
Peeks current mean vector.
ncm_data_gauss_cov_mvnd_gen ()
NcmVector * ncm_data_gauss_cov_mvnd_gen (NcmDataGaussCovMVND *data_mvnd
,NcmMSet *mset
,gpointer obj
,NcmDataGaussCovMVNDBound bound
,NcmRNG *rng
,gulong *N
);
Generates one realization of the MVND. If bound
is not NULL,
generates realizations untill bound
returns TRUE.
ncm_data_gauss_cov_mvnd_est_ratio ()
gdouble ncm_data_gauss_cov_mvnd_est_ratio (NcmDataGaussCovMVND *data_mvnd
,NcmMSet *mset
,gpointer obj
,NcmDataGaussCovMVNDBound bound
,gulong *N
,gulong *Nin
,const gdouble reltol
,NcmRNG *rng
);
Estimate the ratio between accepted realizations and total number
of realizations. The variable reltol
controls the relative tolerance
on the ratio estimate. The variables N
and Nin
can be used to inform
previous number of realizations.
ncm_data_gauss_cov_mvnd_log_info ()
void
ncm_data_gauss_cov_mvnd_log_info (NcmDataGaussCovMVND *data_mvnd
);
Logs mean and covariance matrix.
ncm_data_gauss_cov_mvnd_stats_vec ()
NcmStatsVec * ncm_data_gauss_cov_mvnd_stats_vec (NcmDataGaussCovMVND *data_mvnd
,NcmMSet *mset
,const guint n
,const glong maxiter
,NcmVector *lower
,NcmVector *upper
,gboolean save_realizations
,NcmRNG *rng
);
Generates a NcmStatsVec with the statistics of the MVND. If
save_realizations
is TRUE, the realizations are saved in the
NcmStatsVec.


Toggle navigation
+1-678-123-5555
<EMAIL_ADDRESS>Mon-Fri: 9am-6pm
Welcome, {{email}}
Toggle navigation
icket Fix Me
Services
How it works
(current)
About
Contact
Login
Contractor
Jobs In My Region
Admin
Activity
Tenants
Property Managers
Contractors
Tenant
Tickets
Manager
Manage Tickets
Properties
Register
Tenant
Property Manager
Contractor
Logout


The URL from which the authentication assertion can be retrieved.
The challenge posed to the device to solve.
The authentication level for this authentication.
The log identifier for this enrolment.
The service this enrolment session originated from.
The URL for the short-poll status of the authentication, so that a client can query it.
The URL used to notify the app that an authentication has completed.
Should not be directly called. Overridden by PushAuth.getState and WaveAuth.getState.
Generated using TypeDoc
Common base-class for authentications.


This chapter describes two examples that demonstrate how to use resource adapters in Java EE applications and how to implement simple resource adapters. The trading
example shows how to use a simple custom client interface to connect to an EIS from a web application. The resource adapter in this example implements the outbound contract and the custom client interface. The traffic
example shows how to use a message-driven bean (MDB) to process traffic information updates from an EIS. The resource adapter in this example implements the inbound and work management contracts.
The following topics are addressed here:
The trading
example demonstrates how to implement and use a simple outbound resource adapter that submits requests to a legacy EIS using a TCP socket. The example demonstrates the scenario in Figure 53-1 and consists of the following modules:
trading-eis
: A Java SE program that simulates a legacy EIS
trading-rar
: The outbound resource adapter implementation
trading-war
: A web application that uses the resource adapter
trading-ear
: An enterprise archive that contains the resource adapter and the web application
The trading-eis
module is an auxiliary project that resembles a legacy stock trading execution platform. It contains a Java SE program that listens for trading requests in plain text on a TCP socket. The program replies to trading requests with a status value, a confirmation number, and the dollar amounts for the requested shares and fees. For example, a request-response pair would look like this:
>> BUY 1000 ZZZZ MARKET << EXECUTED #1234567 TOTAL 50400.00 FEE 252.00
The trading-rar
module implements the outbound contract of the Java EE Connector Architecture to submit requests and obtain responses from the legacy stock trading execution platform. The trading-rar
module provides and implements a custom client interface for Java EE applications to use. This interface is simpler than the Common Client Interface (CCI).
The trading-war
module is a web application with a JavaServer Faces interface and a managed bean. This application enables clients to submit trades to the EIS using the resource adapter provided by the trading-rar
module. The trading-war
module uses the custom client interface provided by the resource adapter to obtain connections to the EIS.
In most cases, Java EE application developers use outbound resource adapters developed by a third party. Outbound resource adapters either implement the Common Client Interface (CCI) or provide a custom interface for applications to interact with the EIS. Outbound resource adapters provide Java EE applications with the following elements:
Connection factories
Connection handles
Other interfaces and objects specific to the EIS domain
Java EE applications obtain an instance of the connection factory via resource injection and then use the factory object to obtain connection handles to the EIS. The connection handles enable the application to make requests and obtain information from the EIS.
The trading-rar
module provides a custom client interface that consists of the classes listed in Table 53-1.
Table 53-1 Classes and Interfaces in the javaeetutorial.trading.rar.api Package
| API Component | Description |
|---|---|
|
|
Represents a trade order for the EIS |
|
|
Represents a response from the EIS to a trade request |
|
|
Represents a connection handle to the EIS Provides a method for applications to submit trades to the EIS |
|
|
Enables applications to obtain connection handles to the EIS |
|
|
Indicates that a problem occurred processing a trade request |
The ResourceAccessBean
managed bean in the trading-war
module configures a connection factory for the trading-rar
resource adapter by using the @ConnectionFactoryDefinition
annotation as follows:
@Named @SessionScoped @ConnectionFactoryDefinition( name = "java:comp/env/eis/TradeConnectionFactory", interfaceName = "javaeetutorial.trading.rar.api.TradeConnectionFactory", resourceAdapter = "#trading-rar", minPoolSize = 5, transactionSupport = TransactionSupport.TransactionSupportLevel.NoTransaction ) public class ResourceAccessBean implements Serializable { ... }
The name
parameter specifies the JNDI name for the connection factory. This example registers the connection factory in the java:comp
scope. You can use the ConnectionFactoryDefinition
annotation to specify a different scope, such as java:global
, java:app
, or java:module
. The AdministeredObjectDefinition
annotation also enables you to register administered connector objects in the JNDI namespace.
The interfaceName
parameter specifies the interface implemented by the connection factory included in the resource adapter. In this example, this is a custom interface.
The resourceAdapter
parameter specifies the name of the resource adapter that contains the connection factory implementation. The #
prefix in #trading-rar
indicates that trading-rar
is an embedded resource adapter that is bundled in the same EAR as this web application.
|
Note: You can also configure a connection factory for a previously deployed outbound resource adapter using the administration commands from your application server. However, this is a vendor-specific procedure. |
The managed bean obtains a connection factory object using resource injection as follows:
... public class ResourceAccessBean implements Serializable { @Resource(lookup = "java:comp/env/eis/TradeConnectionFactory") private TradeConnectionFactory connectionFactory; ... }
The managed bean uses the connection factory to obtain connection handles as follows:
TradeConnection connection = connectionFactory.getConnection();
The resource adapter returns a connection handle associated with a physical connection to the EIS. Once a connection handle is available, the managed bean submits a trade and obtains the response as follows:
TradeOrder order = new TradeOrder(); order.setNShares(1000); order.setTicker(TradeOrder.Ticker.YYYY); order.setOrderType(TradeOrder.OrderType.BUY); order.setOrderClass(TradeOrder.OrderClass.MARKET); ... try { TradeResponse response = connection.submitOrder(order); ... } catch (TradeProcessingException ex) { ... }
The trading-rar
module implements the outbound contract and a custom client interface for the simple legacy stock trading platform EIS used in this example. The architecture of the outbound resource adapter is shown in Figure 53-2.
Figure 53-2 Architecture of the trading Example
The trading-rar
module implements the interfaces listed in Table 53-2.
Table 53-2 Interfaces Implemented in the trading-rar Module
| Package | Interface | Description |
|---|---|---|
|
|
|
Defines the lifecycle methods of the resource adapter |
|
|
|
Defines a connection factory that the connection manager from the application server uses to obtain physical connections to the EIS |
|
|
|
Defines a physical connection to the EIS that can be managed by the connection manager |
|
|
|
Defines a connection factory that applications use to obtain connection handles |
|
|
|
Defines a connection handle that applications use to interact with the EIS |
When the trading-ear
archive is deployed and a connection pool resource is configured as described in Using the Outbound Resource Adapter, the application server creates TradeConnectionFactory
objects that applications can obtain using resource injection. The TradeConnectionFactory
implementation delegates creating connections to the connection manager provided by the application server.
The connection manager uses the ManagedConnectionFactory
implementation to obtain physical connections to the EIS and maintains a pool of active physical connections. When an application requests a connection handle, the connection manager associates a connection from the pool with a new connection handle that the application can use. Connection pooling improves application performance and simplifies resource adapter development.
For more details, see the code and the comments in the trading-rar
module.
You can use either NetBeans IDE or Maven to build, package, deploy, and run the trading
example.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/connectors
Select the trading
folder.
Click Open Project.
In the Projects tab, expand the trading
node.
Right-click the trading-eis
module and select Open Project.
Right-click the trading-eis
project and select Run.
The messages from the EIS appear in the Output tab:
Trade execution server listening on port 4004.
Right-click the trading-ear
project and select Build.
This command packages the resource adapter and the web application in an EAR file and deploys it to GlassFish Server.
Open the following URL in a web browser:
http://localhost:8080/trading/
The web interface enables you to connect to the EIS and submit trades. The server log shows the requests from the web application and the call sequence that provides connection handles from the resource adapter.
Before undeploying the trading-ear
application, close the trading-eis
application from the status bar.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/connectors/trading/
Enter the following command:
mvn install
This command builds and packages the resource adapter and the web application into an EAR archive and deploys it to GlassFish Server.
In the same terminal window, go to the trading-eis
directory:
cd trading-eis
Enter the following command to run the trade execution platform:
mvn exec:java
The messages from the EIS appear in the terminal window:
Trade execution server listening on port 4004.
Open the following URL in a web browser:
http://localhost:8080/trading/
The web interface enables you to connect to the EIS and submit trades. The server log shows the requests from the web application and the call sequence that provides connection handles from the resource adapter.
Before undeploying the trading-ear
application, press Ctrl+C on the terminal window to close the trading-eis
application.
The traffic
example demonstrates how to implement and use a simple inbound resource adapter that receives data from a legacy EIS using a TCP socket.
The example is in the tut-install/examples/connectors/traffic
directory. See Chapter 2, "Using the Tutorial Examples," for basic information on building and running sample applications.
The example demonstrates the scenario in Figure 53-3 and consists of the following modules:
traffic-eis
: A Java SE program that simulates an EIS
traffic-rar
: The inbound resource adapter implementation
traffic-ejb
: A message-driven bean that is the endpoint for incoming messages
traffic-war
: A web application that displays information from the message-driven bean
traffic-ear
: An enterprise archive that contains the resource adapter, the message-driven bean, and the web application
The traffic-eis
module is an auxiliary project that resembles a legacy traffic information system. It contains a Java SE program that sends traffic status updates for several cities to any subscribed client. The program sends the updates in JSON format over a TCP socket. For example, a traffic update looks like this:
{"report":[ {"city":"City1", "access":"AccessA", "status":"GOOD"}, {"city":"City1", "access":"AccessB", "status":"CONGESTED"}, ... {"city":"City5", "access":"AccessE", "status":"SLOW"} ]}
The traffic-rar
module implements the inbound contract of the Java EE Connector Architecture. This module subscribes to the traffic information system using the TCP port indicated by the configuration provided by the MDB and invokes the methods of the MDB to process traffic information updates.
The traffic-ejb
module contains a message-driven bean that activates the resource adapter with a configuration parameter (the TCP port to subscribe to the traffic information system). The MDB contains a method to process the traffic information updates. This method filters the updates for a particular city and publishes the results to a Java Message Service (JMS) topic.
The traffic-war
module contains a message-driven bean that receives filtered traffic information updates from the JMS topic asynchronously and sends them to the clients using a WebSocket endpoint.
In most cases, Java EE application developers use inbound resource adapters developed by a third party. To use an inbound resource adapter, a Java EE application includes a message-driven bean with the following characteristics.
The MDB implements the business interface defined by the resource adapter.
The MDB specifies configuration parameters to activate the resource adapter.
The business interface defined by the resource adapter is not specified in the Java EE Connector Architecture; it is specific to the EIS.
The MDB in this example is defined as follows:
@MessageDriven( activationConfig = { @ActivationConfigProperty(propertyName = "port", propertyValue = "4008") } ) public class TrafficMdb implements TrafficListener { ... }
The TrafficListener
interface is defined in the API package of the resource adapter. The resource adapter requires the MDB to provide the port
property.
When the MDB is deployed, it activates the traffic-rar
resource adapter, which invokes the methods of the MDB to process traffic information updates. Then the MDB filters the updates for a particular city and publishes the results to a JMS topic.
In this particular example, the TrafficListener
interface is empty. In addition to this interface, the resource adapter provides the TrafficCommand
annotation and uses reflection to discover which methods in the MDB are decorated with this annotation:
@MessageDriven(...) public class TrafficMdb implements TrafficListener { @TrafficCommand(name="report", info="Process report") public void processReport(String jsonReport) { ... } ... }
This approach enables you to adapt the MDB to support new features in the EIS without having to modify the TrafficListener
interface or the resource adapter module.
The traffic-rar
module implements the inbound resource adapter contract from the Java EE Connector Architecture for the simple traffic information system (EIS) used in this example. The architecture of the inbound resource adapter is shown in Figure 53-4.
Figure 53-4 Architecture of the traffic Example
The traffic-rar
module implements the interfaces listed in Table 53-3.
Table 53-3 Interfaces Implemented in the traffic-rar Module
| Package | Interface | Description |
|---|---|---|
|
|
|
Defines the lifecycle methods of the resource adapter. |
|
|
|
Defines the configuration parameters that the MDB provides to activate the inbound resource adapter. |
|
|
|
The traffic service subscriber implements this interface from the work management contract to wait for traffic updates on a separate thread. |
When an MDB activates the inbound resource adapter, the container invokes the endpointActivation
method in the TrafficResourceAdapter
class:
@Connector(...) public class TrafficResourceAdapter implements ResourceAdapter, Serializable { ... @Override public void endpointActivation(MessageEndpointFactory endpointFactory, ActivationSpec spec) throws ResourceException { Class endpointClass = endpointFactory.getEndpointClass(); /* this method is called from a new thread in the example: MessageEndpoint endpoint = endpointFactory.createEndpoint(null); */ } }
The getEndpointClass
method returns the Class
type of the MDB performing the activation, which enables the resource adapter to use reflection to find methods annotated with @TrafficCommand
in the MDB.
The createEndpoint
method returns an instance of the MDB. The resource adapter uses this instance to invoke the methods of the MDB when it receives requests from the EIS.
After obtaining the message endpoint instance (MDB), the resource adapter uses the work management contract to create the traffic service subscriber thread that receives traffic updates from the EIS. The resource adapter obtains the WorkManager
instance from the bootstrap context as follows:
WorkManager workManager; ... @Override public void start(BootstrapContext ctx) ... { workManager = ctx.getWorkManager(); }
The resource adapter schedules the traffic service subscriber thread using the work manager:
tSubscriber = new TrafficServiceSubscriber(tSpec, endpoint); workManager.scheduleWork(tSubscriber);
The TrafficServiceSubscriber
class implements the javax.resource.spi.Work
interface from the work management contract.
The traffic service subscriber thread uses reflection to invoke the methods in the MDB:
private String callMdb(MessageEndpoint mdb, Method command,
String... params) ... {
String resp;
/* this code contains proper exception handling in the sources */
mdb.beforeDelivery(command);
Object ret = command.invoke(mdb, (Object[]) params);
resp = (String) ret;
mdb.afterDelivery();
return resp;
}
For more details, see the code and the comments in the traffic-rar
module.
You can use either NetBeans IDE or Maven to build, package, deploy, and run the traffic
example.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
From the File menu, choose Open Project.
In the Open Project dialog box, navigate to:
tut-install/examples/connectors
Select the traffic
folder.
Click Open Project.
In the Projects tab, expand the traffic
node.
Right-click the traffic-eis
module and select Open Project.
Right-click the traffic-eis
project and select Run.
The messages from the EIS appear on the Output tab:
Traffic EIS accepting connections on port 4008
In the Projects tab, right-click the traffic
project and select Clean and Build.
This command builds and packages the resource adapter, the MDB, and the web application into an EAR archive and deploys it. The server log shows the call sequence that activates the resource adapter and the filtered traffic updates for City1.
Open the following URL in a web browser:
http://localhost:8080/traffic/
The web interface shows filtered traffic updates for City1 every few seconds.
After undeploying the traffic-ear
application, close the traffic-eis
application from the status bar.
Make sure that GlassFish Server has been started (see Starting and Stopping GlassFish Server).
In a terminal window, go to:
tut-install/examples/connectors/traffic/traffic-eis/
Enter the following command in the terminal window:
mvn install
This command builds and packages the traffic EIS.
Enter the following command in the terminal window:
mvn exec:java
The messages from the EIS appear in the terminal window:
Traffic EIS accepting connections on port 4008
Leave this terminal window open.
Open a new terminal window and go to:
tut-install/examples/connectors/traffic/
Enter the following command:
mvn install
This command builds and packages the resource adapter, the MDB, and the web application into an EAR archive and deploys it. The server log shows the call sequence that activates the resource adapter and the filtered traffic updates for City1.
Open the following URL in a web browser:
http://localhost:8080/traffic/
The web interface shows the filtered traffic updates for City1 every few seconds.
After undeploying the traffic-ear
application, press Ctrl+C in the first terminal window to close the traffic-eis
application.


Create an Account!
Your Name
Your Company
Your email
Password
Confirm Password
I Agree with
Term and Conditions
of the service
Submit
Back
Sponsors
Made with Pingendo Free


Everything
Locate files and folders instantly
Screenshots
Hunter’s comment
This is a tiniest yet powerful tool that I cannot live without on a PC. I can’t remember how many times this tool has saved for me everytime I want to find something on my file system but happened to merely remember a fraction of the name while totally forgot the exact location.
When I want to locate something quickly, I use the custom hotkey Shift+Ctrl+F
to summon Everything which it appears on top immediately, I then type whatever I want to search. The whole process normally cost less than 3 seconds.
Everything does one thing only and does it best without any competition: Find everything on your computer and find it immediately!
- Locate all the files or folders so fast the result generated and changed upon every single character you type in the searching column.
- Even able to search file contents with advanced search functions enabled.
- So friendly that it just consumes 14MB of RAM and less than 9MB of disk space(on fresh installed Windows 10)
- No bloatware, malware, or spyware.
- Clean and simple UI.
- Free and without ads.
Link
Contributors
Hunter: @fr3eze
This is posted on Steemhunt - A place where you can dig products and earn STEEM.
View on Steemhunt.com
This page is synchronized from the post: ‘Everything - Locate files and folders instantly’


WITNESS LIST Civil Practices Committee March 14, 2001-2:00P HB 284 For: Williams, John H. (Justice of the Peace, Constable Assn. of Texas) HB 348Committee Substitute (Wise/ CSHB 348) For: Herberg, JR., Clifford C. (Bexar County District Attorney's Office) Ybarbo, Lieutenant Ray (Chief of Police Al Philippus, San Antonio Police Dept.) HB 740 For: Hile, Richard (Texas Trial Lawyers Assn.) Against: Waldrop, Alan (Texans for Lawsuit Reform) On: Griesel, Chris (Rules Attorney, Supreme Court of Texas) HB 781 For: HeBert, Nancy J. (TTLA) Against: Waldrop, Alan (Texans for Lawsuit Reform) HB 792 For: Kollman, Ruth A. (Self) On: Frost, Robert H. (Commission For Lawyer Discipline of State Bar of Texas) HB 1335 Against: Crow, Shellie Hoffman (Self and TASB, Texas Council of School Attorneys) Larson, Dohn (Texas Classroom Teachers Assn.) HB 1823 For: Flores, Brenda Flynn (www.HouSnitch.com) Klein, Barry (Self) HB 2179 On: Reynolds, Carl (Texas Department of Criminal Justice) HB 2301 Against: Caputo, Mr. Cobby A. (Schwartz & Eickelbaum, P.C., Texas Association of School Boards, Council of School Attorneys) HB 2723 For: Blackwell, Tom (Self) Smith, Alan Winston (Self) HJR 71 Against: Caputo, Cobby A. (Schwartz & Eickelbaum, P.C., Texas Association of School Boards, Council of School Attorneys)


Green-Xtreame
$250
Digital Owl
$312
I Can
$280
GB Shirts
$220
Green-Xtreame
$250
Green-Xtreame
$250
Orange
$25
Blue
$30
Black
$35
Red
$33
Orange
$25
Blue
$30
Gift Card#1
$10
Gift Card#2
$30
iTunes Card
$50
Netflix Card
$60
Gifr Card#3
$25
iTunes Cards#2
$15
Bear
$45
Winnie the Pooh
$60
Piggy
$55
Dog
$45
Bear
$45
Winnie the Pooh
$60
Ukraine
$25
Frog
$20
Basket Club
$15
Wreath
$30
Ukraine
$25
Frog
$20
Pencil
$1
Pen#1
$3
Pen#2
$5
Pen#3
$4
Pencil#2
$1
Pen#4
$3
White-Black
$60
White
$55
Blue
$25
Red
$65
White-Black
$60
White
$55
HP
$300
Siemens
$350
BenQ
$330
Asus
$400
HP#2
$300
Siemens#2
$350
Google
$50
Google Play
$50
Yandex
$50
Qiwi
$50
Google
$50
Google Play
$50


We are trying to make it easy for anyone around the world to compare their travel history after a global outbreak of a virus, to see if any possible contact with the virus by tracing the travel history of positively tested patients
we used simple comparison of timestamp and distance calculation of geocordinates.
The main use cases we see are:
- any user can report their case if they feel they might have been in contact with the patients, and the health department can provide them with necessary instructions for self isolation or medical help.
- assessment of location and time based spread of virus , in later stages to know precutions and areas to improve in future outbreaks.
- Tree strucutered transmission database of patients from the index patient onwards.
Steps to Trace Yourself


Device Trust Connector
Is Enabled:
DTC Enabled Levels:
Key Manager Initialized:
Permanent Failure:
Trust Level:
Key Type:
SPKI Hash:
Key Sync:
Consent Was Received:
Can Collect Signals:
Details about user consent could not be retrieved.
Signals:
Copy Signals