Product Info & Care
Avert from the usual with this pair of black coloured formal shoes by Franco Leone. Experience endless comfort adorning this pair of formal shoes, which is crafted using comfortable pu sole. A nice add-on to your footwear collection, it will go well with your outfit for the day.


Information about the associated dialog can be found here.
Solitaire is a typical symmetric Paper-and-Pencil-encryption-algorithm. It became known after it was featured in Neal Stephenson's novel Cryptonomicon.
The algorithm was designed by Bruce Schneier. Its security is drawn from the inherent randomness of a well-shuffled deck of cards and the fact that each key (a given shuffled deck) is used only once.
The key in this algorithm is a particular sequence of cards in a shuffled deck. Both the sender and the receiver must have the same card order.
The actual Solitaire algorithm describes how to use the key (a shuffled bridge deck with 54 cards) to generate a pseudo random keystream.
Each character in the keystream is added modulo 26 (ADD) to each character of the plaintext or ciphertext. This is very similar to the concept of a one-time pad, although the keystream of this algorithm is not completely random.
The Solitaire cipher is based on the Vernam cipher (in which the plaintext is ADDed with the keystream) and the stream cipher (in which a keystream is generated from an initial value). Randomness can only be guaranteed in the initial deck.
The keystream generation algorithm consists of five steps, of which the first four permute the deck. The first two steps just move the jokers around, and steps 3 and 4 swap sections of the deck. Step 5 locates the value of the next keystream letter, but does not change the order of cards. The interim card orderings are called temporary decks and the last variation is called the final deck.
In normal operation, the initial deck and final deck each contain a permutation of the card values 1 to 54. The keystream contains values from 1 to 52 and has the same length as the plaintext.
Encryption with Solitaire
The precondition for encryption is the existence of a keystream with the same length as the plaintext. It consists of a stream of numbers between 1 and 26.
All non-alphabetic characters are removed from the plaintext, and then it is split in groups of five characters. Each plaintext letter is converted into a number from 1 to 26 (where A = 1, B = 2, C = 3, Z = 26, etc.) and added modulo 26 to the keystream. (The results of a modulo 26 operation will be between 0 and 25, where 0 is then interpreted as 26 and thus equal to Z.) The result of reconverting the number stream into letters is the ciphertext.
Decryption with Solitaire
Because Solitaire is a symmetric cipher, the same key (that is, keystream) is used for both encryption and decryption.
To decrypt, the ciphertext is again split into groups of five letters, just as with encryption. After the letter-stream is converted to a number-stream, the keystream numbers are subtracted modulo 26 from the ciphertext numbers. The resulting number-stream must be converted back into a letter-stream to obtain the plaintext.
Remark:
It is recommended that the receiver keeps a copy of the initial deck, since it will become modified during the generation of a keystream. If he or she makes a mistake and does not have a copy, the procedure cannot be restarted and the plaintext cannot be decrypted.
Initial key generation
The cards are given values depending on the suit: the ace of clubs becomes 1, the 2 of clubs becomes 2, the king of clubs becomes 13, and so on. The diamonds follow the same pattern in the range 14 to 26, hearts from 27 to 39, and spades from 40 to 52. Due to calculation with modulo 26, the generated keystream is a sequence of numbers from 1 to 26.
To initialize the card deck, Schneier describes three alternatives:
1. Shuffle cards:
Use identically shuffled decks. A random key is best. One of the participants can shuffle a random deck and then create an exact copy for the other partner. Since most people are not particularly good shufflers, the deck should be shuffled at least six times. Both parties should also keep a spare deck with the exact same card order in case a mistake is made with the first deck.
2. Bridge suite order:
Use a particular bridge ordering based on a set of bridge hands that can be found in newspapers or bridge books. Agree on a way to take the bridge-hand diagram and convert it into an ordering of the deck. Then agree on a way to put the two jokers into the deck. (A simple solution is to put the A joker after the first card mentioned in the text, and the B joker after the second card mentioned in the text.)
3. Password:
Use a password to order the deck. This method uses the Solitaire algorithm to create an initial deck ordering. Both the sender and receiver share a passphrase. Start with the deck in a fixed order; lowest card to highest card, divided by suit, followed by the A and then the B joker. Perform the normal Solitaire operation, but instead of step 5, cut the deck based on the first character of the password (which is essentially just a repetition of step 4). The top cards must be put just above the bottom card in the deck as before.
The sender and the receiver need to use the same bridge suite order so that both sides can generate the keystream. There are 54! (approx. 2*10^71) different possibilities of how the card deck can be ordered.
Keystream generation
The algorithm functions as follows:
To initialize the deck, hold it face up. Then arrange the cards in the initial configuration that is the key. Then the following five steps are repeated for as many times as the length of the plaintext.
Step 1: Find the A joker. Move it one card down (that is, swap it with the card beneath it). If the joker is at the bottom of the deck, move it just below the top card.
Step 2: Find the B joker. Move it two cards down. If the joker is the bottom card of the deck, move it just below the second card from the top. If the joker is one away from the bottom card, move it just below the top card. (Basically, treat the deck as if it wraps around.)
Step 3: Perform a triple cut by swapping the cards above the first joker with the cards below the second joker. It does not matter which joker is first; it is simply decided by which is nearest to the top of the deck. The jokers are not swapped. If one of the three sections is empty (because the jokers are adjacent to one another or one is on the top or bottom), it should still be moved accordingly.
Step 4: Step 4: Look at the bottom card. The value of the bottom card is called u (which is defined from the range 1 to 53 as defined previously). Count from the top card downwards until that number (u) is reached. Cut after the last card counted, leaving the bottom card where it is.
Step 5: The output card is found as follows. Look at the top card and count that many cards downward. (Count the top card as the first one.) The card after the last one reached is the output card. Do not remove it from the deck. If the card is a joker, this is called a zero round); do not write anything down and start over with step 1. The card's value (between 1 and 52) modulo 26 is the keystream character. If there are not enough keystream letters, start over from step 1.


/* <CoffeeScript> # !TODO: Add deriveFieldsOnSnapshots with @config.deriveFieldsOnSnapshotsConfig calling deriveFieldsOnFacts in OLAPCube # !TODO: Add deriveFieldsOnResults with @config.deriveFieldsOnResultsConfig calling deriveFieldsOnResultsConfig # !TODO: Add drill-down support with uniqueIDField or maybe keepFacts = true # !TODO: Add series by type support OLAPCube = require('./OLAPCube').OLAPCube {utils, Time, Timeline} = require('tztime') class TransitionsCalculator # implements iCalculator </CoffeeScript> */ /** * @class Lumenize.TransitionsCalculator * * Used to accumlate counts and sums about transitions. * * Let's say that you want to create a throughput or velocity chart where each column on the chart represents the * number of work items that cross over from one state into another state in a given month/week/quarter/etc. You would * send a transitions to a temporal data store like Rally's Lookback API specifying both the current values and the * previous values. For instance, the work items crossing from "In Progress" to "Completed" could be found * with this query clause `"_PreviousValues.ScheduleState": {"$lte": "In Progress"}, "ScheduleState": {"$gt": "In Progress"}` * * {TransitionsCalculator, Time} = require('../') * * snapshots = [ * { id: 1, from: '2011-01-03T00:00:00.000Z', PlanEstimate: 10 }, * { id: 1, from: '2011-01-05T00:00:00.000Z', PlanEstimate: 10 }, * { id: 2, from: '2011-01-04T00:00:00.000Z', PlanEstimate: 20 }, * { id: 3, from: '2011-01-10T00:00:00.000Z', PlanEstimate: 30 }, * { id: 4, from: '2011-01-11T00:00:00.000Z', PlanEstimate: 40 }, * { id: 5, from: '2011-01-17T00:00:00.000Z', PlanEstimate: 50 }, * { id: 6, from: '2011-02-07T00:00:00.000Z', PlanEstimate: 60 }, * { id: 7, from: '2011-02-08T00:00:00.000Z', PlanEstimate: 70 }, * ] * * But that's not the entire story. What if something crosses over into "Completed" and beyond but crosses back. It could * do this several times and get counted multiple times. That would be bad. The way we deal with this is to also * look for the list of snapshots that pass backwards across the boundary and subract thier impact on the final calculations. * * One can think of alternative aproaches for avoiding this double counting. You could, for instance, only count the last * transition for each unique work item. The problem with this approach is that the backward moving transition might * occur in a different time period from the forward moving one. A later snapshot could invalidate an earlier calculation * which is bad for incremental calculation and caching. To complicate matters, the field values being summed by the * calculator might have changed between subsequent forward/backward transitions. The chosen algorithm is the only way I know to * preserve the idempotency and cachable incremental calculation properties. * * snapshotsToSubtract = [ * { id: 1, from: '2011-01-04T00:00:00.000Z', PlanEstimate: 10 }, * { id: 7, from: '2011-02-09T00:00:00.000Z', PlanEstimate: 70 }, * ] * * The calculator will keep track of the count of items automatically (think throughput), but if you want to sum up a * particular field (think velocity), you can specify that with the 'fieldsToSum' config property. * * fieldsToSum = ['PlanEstimate'] * * Now let's build our config object. * * config = * asOf: '2011-02-10' # Leave this off if you want it to continuously update to today * granularity: Time.MONTH * tz: 'America/Chicago' * validFromField: 'from' * validToField: 'to' * uniqueIDField: 'id' * fieldsToSum: fieldsToSum * asterixToDateTimePeriod: true # Set to false or leave off if you are going to reformat the timePeriod * * In most cases, you'll want to leave off the `asOf` configuration property so the data can be continuously updated * with new snapshots as they come in. We include it in this example so the output stays stable. If we hadn't, then * the rows would continue to grow to encompass today. * * startOn = '2011-01-02T00:00:00.000Z' * endBefore = '2011-02-27T00:00:00.000Z' * * calculator = new TransitionsCalculator(config) * calculator.addSnapshots(snapshots, startOn, endBefore, snapshotsToSubtract) * * console.log(calculator.getResults()) * # [ { timePeriod: '2011-01', count: 5, PlanEstimate: 150 }, * # { timePeriod: '2011-02*', count: 1, PlanEstimate: 60 } ] * * The asterix on the last row in the results is to indicate that it is a to-date value. As more snapshots come in, this * last row will change. The caching and incremental calcuation capability of this Calculator are designed to take * this into account. * * Now, let's use the same data but aggregate in granularity of weeks. * * config.granularity = Time.WEEK * calculator = new TransitionsCalculator(config) * calculator.addSnapshots(snapshots, startOn, endBefore, snapshotsToSubtract) * * console.log(calculator.getResults()) * # [ { timePeriod: '2010W52', count: 1, PlanEstimate: 10 }, * # { timePeriod: '2011W01', count: 2, PlanEstimate: 50 }, * # { timePeriod: '2011W02', count: 2, PlanEstimate: 90 }, * # { timePeriod: '2011W03', count: 0, PlanEstimate: 0 }, * # { timePeriod: '2011W04', count: 0, PlanEstimate: 0 }, * # { timePeriod: '2011W05', count: 1, PlanEstimate: 60 }, * # { timePeriod: '2011W06*', count: 0, PlanEstimate: 0 } ] * * Remember, you can easily convert weeks to other granularities for display. * * weekStartingLabel = 'week starting ' + new Time('2010W52').inGranularity(Time.DAY).toString() * console.log(weekStartingLabel) * # week starting 2010-12-27 * * If you want to display spinners while the chart is rendering, you can read this calculator's upToDateISOString property and * compare it directly to the getResults() row's timePeriod property using code like this. Yes, this works eventhough * upToDateISOString is an ISOString. * * row = {timePeriod: '2011W07'} * if calculator.upToDateISOString < row.timePeriod * console.log("#{row.timePeriod} not yet calculated.") * # 2011W07 not yet calculated. * * @constructor * @param {Object} config * @cfg {String} tz The timezone for analysis in the form like `America/New_York` * @cfg {String} [validFromField = "_ValidFrom"] * @cfg {String} [validToField = "_ValidTo"] * @cfg {String} [uniqueIDField = "ObjectID"] Not used right now but when drill-down is added it will be * @cfg {String} granularity 'month', 'week', 'quarter', etc. Use Time.MONTH, Time.WEEK, etc. * @cfg {String[]} [fieldsToSum=[]] It will track the count automatically but it can keep a running sum of other fields also * @cfg {Boolean} [asterixToDateTimePeriod=false] If set to true, then the still-in-progress last time period will be asterixed */ /* <CoffeeScript> @cfg {Boolean} [asterixToDateTimePeriod=false] If set to true, then the still-in-progress last time period will be asterixed @config = utils.clone(config) # Assert that the configuration object is self-consistent and required parameters are present unless @config.validFromField? @config.validFromField = "_ValidFrom" unless @config.validToField? @config.validToField = "_ValidTo" unless @config.uniqueIDField? @config.uniqueIDField = "ObjectID" unless @config.fieldsToSum? @config.fieldsToSum = [] unless @config.asterixToDateTimePeriod? @config.asterixToDateTimePeriod = false utils.assert(@config.tz?, "Must provide a timezone to this calculator.") utils.assert(@config.granularity?, "Must provide a granularity to this calculator.") if @config.granularity in [Time.HOUR, Time.MINUTE, Time.SECOND, Time.MILLISECOND] throw new Error("Transitions calculator is not designed to work on granularities finer than 'day'") dimensions = [ {field: 'timePeriod'} ] metrics = [ {field: 'count', f: 'sum'} # We add a count field to each snapshot and use sum so we can also subtract ] for f in @config.fieldsToSum metrics.push({field: f, f: 'sum'}) cubeConfig = {dimensions, metrics} @cube = new OLAPCube(cubeConfig) @upToDateISOString = null @lowestTimePeriod = null if @config.asOf? @maxTimeString = new<EMAIL_ADDRESS><EMAIL_ADDRESS>else @maxTimeString = Time.getISOStringFromJSDate() @virgin = true addSnapshots: (snapshots, startOn, endBefore, snapshotsToSubtract=[]) -> </CoffeeScript> */ /** * @method addSnapshots * @member Lumenize.TransitionsCalculator * Allows you to incrementally add snapshots to this calculator. * @chainable * @param {Object[]} snapshots An array of temporal data model snapshots. * @param {String} startOn A ISOString (e.g. '2012-01-01T12:34:56.789Z') indicating the time start of the period of * interest. On the second through nth call, this should equal the previous endBefore. * @param {String} endBefore A ISOString (e.g. '2012-01-01T12:34:56.789Z') indicating the moment just past the time * period of interest. * @return {TransitionsCalculator} */ /* <CoffeeScript> if @upToDateISOString? utils.assert(@upToDateISOString == startOn, "startOn (#{startOn}) parameter should equal endBefore of previous call (#{@upToDateISOString}) to addSnapshots.") @upToDateISOString = endBefore startOnString = new Time(startOn, @config.granularity, @config.tz).toString() if @lowestTimePeriod? if startOnString < @lowestTimePeriod @lowestTimePeriod = startOnString else @lowestTimePeriod = startOnString filteredSnapshots = @_filterSnapshots(snapshots) @cube.addFacts(filteredSnapshots) filteredSnapshotsToSubstract = @_filterSnapshots(snapshotsToSubtract, -1) @cube.addFacts(filteredSnapshotsToSubstract) @virgin = false return this _filterSnapshots: (snapshots, sign = 1) -> filteredSnapshots = [] for s in snapshots if<EMAIL_ADDRESS><= @maxTimeString if s.count? throw new Error('Snapshots passed into a TransitionsCalculator cannot have a `count` field.') if s.timePeriod? throw new Error('Snapshots passed into a TransitionsCalculator cannot have a `timePeriod` field.') fs = utils.clone(s) fs.count = sign * 1 fs.timePeriod = new<EMAIL_ADDRESS>@config.granularity, @config.tz).toString() for f in @config.fieldsToSum fs[f] = sign * s[f] filteredSnapshots.push(fs) return filteredSnapshots getResults: () -> </CoffeeScript> */ /** * @method getResults * @member Lumenize.TransitionsCalculator * Returns the current state of the calculator * @return {Object[]} Returns an Array of Maps like `{timePeriod: '2012-12', count: 10, otherField: 34}` */ /* <CoffeeScript> if @virgin return [] out = [] @highestTimePeriod = new Time(@maxTimeString, @config.granularity, @config.tz).toString() config = startOn: @lowestTimePeriod endBefore: @highestTimePeriod granularity: @config.granularity timeLine = new Timeline(config) timePeriods = (t.toString() for t in timeLine.getAllRaw()) timePeriods.push(@highestTimePeriod) for tp in timePeriods filter = {} filter['timePeriod'] = tp cell = @cube.getCell(filter) outRow = {} outRow.timePeriod = tp if cell? outRow.count = cell.count_sum for f in @config.fieldsToSum outRow[f] = cell[f + '_sum'] else outRow.count = 0 for f in @config.fieldsToSum outRow[f] = 0 out.push(outRow) if @config.asterixToDateTimePeriod out[out.length - 1].timePeriod += '*' return out getStateForSaving: (meta) -> </CoffeeScript> */ /** * @method getStateForSaving * @member Lumenize.TransitionsCalculator * Enables saving the state of this calculator. See TimeInStateCalculator documentation for a detailed example. * @param {Object} [meta] An optional parameter that will be added to the serialized output and added to the meta field * within the deserialized calculator. * @return {Object} Returns an Ojbect representing the state of the calculator. This Object is suitable for saving to * to an object store. Use the static method `newFromSavedState()` with this Object as the parameter to reconstitute * the calculator. */ /* <CoffeeScript> out = config: @config cubeSavedState: @cube.getStateForSaving() upToDateISOString: @upToDateISOString maxTimeString: @maxTimeString lowestTimePeriod: @lowestTimePeriod virgin: @virgin if meta? out.meta = meta return out @newFromSavedState: (p) -> </CoffeeScript> */ /** * @method newFromSavedState * @member Lumenize.TransitionsCalculator * Deserializes a previously saved calculator and returns a new calculator. See TimeInStateCalculator for a detailed example. * @static * @param {String/Object} p A String or Object from a previously saved state * @return {TransitionsCalculator} */ /* <CoffeeScript> if utils.type(p) is 'string' p = JSON.parse(p) calculator = new TransitionsCalculator(p.config) calculator.cube = OLAPCube.newFromSavedState(p.cubeSavedState) calculator.upToDateISOString = p.upToDateISOString calculator.maxTimeString = p.maxTimeString calculator.lowestTimePeriod = p.lowestTimePeriod calculator.virgin = p.virgin if p.meta? calculator.meta = p.meta return calculator exports.TransitionsCalculator = TransitionsCalculator </CoffeeScript> */


URL for the client's home page, which will be displayed to the user in the consent page
URL that points to a logo image, will be displayed to the user in the consent page
URL that points to the Terms of Service for this client, will be displayed to the user in the consent page
URL that points to the Policy statement for this client, will be displayed to the user in the consent page


Culver City, California
Lawrence and Martha Joseph Residence and Apartments
Known as the "Hobbit Houses," these storybook homes look like they're straight out of the Shire.
by AnnaIFHidden in downtown Culver City, surrounded by high-rise apartments and restaurants aplenty, are the “Hobbit Houses,” officially titled the Lawrence and Martha Joseph Residence and Apartments.
In 1946, former Walt Disney Studios artist Lawrence Joseph purchased a single-family home. Over the course of 20 years, he added two more buildings and covered it all in fairy-tale elements. Major construction was completed in 1970, but Joseph tinkered with the cottages until his death in 1991.
His wife Martha has maintained the property and kept her husband’s designs alive. The cottages are now a historical landmark and cannot be dramatically updated and renovated like much of the surrounding area has been in recent years.
This whimsical three-building complex includes multiple residences and maritime decor. While the inside is not open to the public for viewing, individual units are often available to rent or sublet.
Stroll by for a clear view of the buildings and turtle pond—though they’re often quite still while sunning themselves on the rocks, they’re real turtles! One of the resident’s friendly cats may even greet you on the sidewalk as the storybook architecture and curved walls transport you to another world.
Visit California with Atlas Obscura Trips
Desert Canvas: Art of Joshua Tree and the Mojave
Join us as we venture deep into the High Desert, glimpsing massive sculptures, revitalizing domes, and fluorescent painted mountains along the way.
Learn More »
Community Discussion
-
No Comments Yet
Start the discussion. forum Visit our forums.


I'm senior attending UC Riverside studying Computer Science. One day, as technology advances I want to be a part of the process.


| buffer - A locked graphics buffer handle |
|
Returns the pixel format of a locked graphics buffer.
The return value can be one of the following: 1 - 16 bit RGB format with 5 bits red, 6 bits green and 5 bits blue. 2 - 16 bit RGB format with 5 bits red, 5 bits green and 5 bits blue. The high bit is unused. 3 - 24 bit RGB format. 4 - 32 bit RGB format. The high byte is unused. See also: LockedPitch, LockedPixels, LockBuffer, UnlockBuffer. |


This is a cross post of the blog post written here:https://snyk.io/blog/demystifying-http-request-smuggling/. Often at my role as a Security Analyst within Snyk, I study trends within the dependency ecosystem which can result in finding interesting vulnerabilities. Recently I looked at HTTP Request Smuggling which resulted in the following disclosures.
- netius HTTP Request Smuggling
- reel HTTP Request Smuggling
- meinheld HTTP Request Smuggling
- goliath HTTP Request Smuggling
- agoo HTTP Request Smuggling
For verifying the above libraries/packages/servers, i found the following tools very useful:
Demystifying HTTP request smuggling
HTTP request smuggling is an interesting vulnerability type that has gained popularity over the last year. This vulnerability could allow an attacker to leverage specific features of the HTTP/1.1 protocol in order to bypass security protections, conduct phishing attacks, as well as obtain sensitive information from requests other than their own.
It should also be noted that request smuggling has received widespread community attention through numerous high-paying bug bounty reports in the last few months, and Snyk observed that 18 HTTP request smuggling related to dependencies have been published in 2020 so far.
This vulnerability was first discussed by Watchfire in their 2005 whitepaper entitled “HTTP Request Smuggling”. This work was later expanded upon by researcher Regis Leroy and further discussed by James Kettle from Portswigger security during BlackHat USA 2019 which gained further media attention.
This blog post aims to demystify the vulnerability and provide remediation details for open source project maintainers looking to patch HTTP request smuggling within their projects.
Background
With new attacks and vulnerabilities gaining popularity and media traction, open source libraries are often targeted by attackers to be exploited in the wild. It can often take weeks or years for these vulnerabilities to be remediated properly within these libraries due to a lack of remediation knowledge. In order to make the open source community secure, the Snyk Security Team often conducts research into vulnerabilities, such as HTTP request smuggling, to discover vulnerabilities within open source dependencies and provide actionable remediation advice to maintainers.
One such task was undertaken by Snyk to identify the impact of HTTP request smuggling within the open source dependency ecosystem which resulted in discovering numerous vulnerabilities. More information regarding the discovered vulnerabilities can be found here.
Snyk found that there are not enough public sources that provide proper guidance into remediating HTTP request smuggling. Furthermore, it was noted that it took maintainers multiple releases to properly address and remediate this vulnerability. With this blog post, we aim to close that gap and help provide detailed remediation advice to any maintainer looking for guidance on this issue.
HTTP request smuggling vulnerability explained
In order to understand HTTP Request Smuggling, the following areas must first be understood:
Keep-Alive and pipelining
The concept of keep-alive and pipelining was initially published in RFC 2616.
The Keep-Alive header is a hop-by-hop header that provides information about a persistent connection. In web servers, Keep-Alive can be specified within the “Connection” header which allows a web server to keep a TCP socket/connection open. By using this header, multiple requests and responses can use a single connection which can reduce overhead and improve performance for a web server. This feature is supported by all browsers and servers today.
Pipelining is another feature that was introduced in RFC 2616. This allows a web server to process requests asynchronously—as a first-in-first-out stream rather than processing each request individually, allowing it to send a request without waiting for a previous response to arrive.
Content-Length and Transfer-Encoding
HTTP requests can have a message body. The presence of a message body in a request is signaled by a Content-Length or Transfer-Encoding header field. These headers are used for message framing, telling a server where a message ends and another begins.
The Content-Length, specified in RFC 7230, section 3.3.2, is an HTTP header that indicates the size of the entity-body of the request. This is commonly seen in HTTP POST requests which have a body of data. It should be noted that GET requests typically shouldn’t contain the Content-Length header since they have no body.
Transfer-Encoding, also specified in RFC 7230, was created to allow the sending of binary data over HTTP. Transfer-Encoding has numerous directives, this blog will focus on the chunked directive.
The chunked directive allows data to be sent in a series of chunks along with the length of these chunks specified in hexadecimal format, followed by carriage return and a line feed. The end of a chunked directive is stated by 0 and an empty sequence. An example of a chunked request can be seen below.
1
2
3
4
5
6
7
8
9
10
POST / HTTP/1.1
Host: snyk.io
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked
7 (length of chunks)
foo=bar (series of chunks)
0 (0 to terminate request followed by \r\n)
(\r\n)
Request smuggling
A modern web server stack will often contain multiple web servers along with load balancers and WSGI servers. A basic diagram to visualize this can be seen as:
HTTP request smuggling vulnerabilities arise when the frontend and the backend interpret the boundary of an HTTP request differently causing desynchronization between them. This is due to numerous frontend and backend libraries deviating from RFC specifications when dealing with both the Content-Length and the Transfer-Encoding header. HTTP request bodies can be framed according to these two headers and deviations from the specification occur. As a result, part of a request gets appended or smuggled, to the next one which allows the response of the smuggled request to be provided to another user.
This vulnerability can be exploited to conduct phishing attacks, cache poisoning, Cross-Site Scripting (XSS), and more. More information regarding exploiting this vulnerability was published by James Kettle last year, during BlackHAT USA 2019, titled “HTTP Desync Attacks: Request Smuggling Reborn”. This blog will focus on the two most common request smuggling techniques:
- CL:CL: Double Content-Length attack technique
- CL:TE: Content-Length Transfer-Encoding attack technique
CL:CL: Double Content-Length attack technique
According to RFC 7230, section 3.3.3#4, “If a message is received without Transfer-Encoding and with either multiple Content-Length header fields having differing field-values or a single Content-Length header field having an invalid value, then the message framing is invalid and the recipient MUST treat it as an unrecoverable error”
However, most middleware and web servers currently will loosely handle GET requests with a body. Furthermore, RFC 7231, section4.3#4.3.1 states “A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request”. This indicates this is a behavior most servers and proxies might support. TIn some cases, this can result in request smuggling attacks. This blog will explore one variation of this attack.
1
2
3
4
5
6
7
GET / HTTP/1.1
Content-Length: 43
Content-Length: 0
Host: snyk.io
GET /reqsmuggle HTTP/1.1
Host: snyk.io
When provided with two Content-Length headers, if implementation differences occur between a frontend and a backend on which Content-Length header to prioritize, smuggling attacks can occur.
In the above HTTP request, a request with two Content-Length headers is sent to a target that has a proxy or a load balancer as a frontend. The proxy will respect and prioritize the first Content-Length and see the smuggled request as part of the request body, even though a GET request shouldn’t have a request body, and two Content-Length headers are provided. When this is processed by the backend, the first Content-Length header is ignored and the second Content-Length header is prioritized. Since the second Content-Length was set to zero, the backend will expect no request body and the /reqsmuggle request is treated as another pipelined request. As such, the response of this smuggled request could be received by another user.
1
2
3
4
5
6
HTTP/1.1 200 OK
Content-Length: 11
hello worldHTTP/1.1 404 Not Found
Connection: Close
Content-Length: 0
CL:TE: Content-Length Transfer-Encoding attack technique
This popular technique discovered by James Kettle of PortSwigger labs involves placing a Content-Length header and a Transfer-Encoding header in a single HTTP request and manipulating it in a way where a frontend proxy and backend server will prioritize these headers and process the smuggled request differently. An example request which demonstrates this vulnerability can be as follows.
1
2
3
4
5
6
7
8
9
10
11
12
POST /login HTTP/1.1
Host: snyk.io
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Transfer-Encoding: chunked
16
login=xxx&password=xxx
0
GET /404 HTTP/1.1
X-Foo: bar
When this request gets processed by a frontend proxy, it will respect the Content-Length header and prioritize this over the Transfer-Encoding header. However, the backend server will prioritize the Transfer-Encoding header. As such, the backend will process the request and will end at the character 0. As a result, the 404 GET request gets treated as a separate pipelined request.
This issue occurs because the frontend prioritizes the Content-Length over Transfer-Encoding header. According to RFC 7230 Section 3.3.3#3, if a message with both Content-Length and Transfer-Encoding is accepted, the Transfer-Encoding header overrides the Content-Length. This is not followed by the frontend.
In cases where the frontend might prioritize the Transfer-Encoding header, it might be possible to bypass this limitation by inserting a malformed transfer encoding header instead of a valid one. Some examples of this can be seen below:
1
2
3
Transfer-Encoding : chunked
tRANSFER-ENCODING: chunked
Transfer-Encoding: chunk
Numerous HTTP libraries tolerate different variations of the Transfer-Encoding header and will normalize them to improve client experience. As such, by understanding what variations of the Transfer-Encoding header is normalized by the backend server, it might be possible to smuggle a malformed Transfer-Encoding header through the frontend and conduct a CL:TE smuggling attack.
The examples above just demonstrate the vulnerability. In a real attack scenario, a smuggled request can be crafted to conduct phishing attacks, or steal data from a victim’s request and send that to an attacker-controlled server.
Scope and misconceptions
During this research, Snyk identified numerous cases where the obvious complexity of the multiple attack vectors led to misconceptions about HTTP request smuggling being reported to open source maintainers by researchers and maintainers, not always understanding if the criteria of remediation are in the scope of their maintained library or if it should be dealt with a dependency they are using as part of their library.
Some of the challenges which required further clarification are as follows:
-
(1.) Proxies/Load Balancers and other mediums, that can be categorized as frontend, are most affected by this vulnerability. However, a successful request smuggling attack requires the exploitation of both a vulnerable frontend and a backend.
-
(2.) The responsibility of remediation falls onto a backend maintainer as much as a frontend maintainer. One can argue that normalizing malformed headers should be acceptable behavior from a backend and make it more tolerant to user faults, and that the real problem is proxies which forward these requests without normalizing them first. But due to the vast ecosystem of dependencies and numerous libraries fitting the criteria of a backend and frontend, it is ideal for both parties to try and remediate this issue.
-
(3.) Middlewares, web servers that support reverse proxy capabilities, WSGI/High-Performance servers are considered to fit the backend criteria, not a web server that just supports the processing of malformed requests but doesn’t support pipelining.
-
(4.) Security reports are often disclosed to maintainers as HTTP request smuggling issues due to servers responding to multiple requests sent and this being visible as two separate responses. It should be noted that many servers support Keep-Alive and pipelining—this by itself does not make an HTTP request smuggling vulnerability. This is the case in CVE-2020-12440 reported for NGINX.
Remediation
HTTP request smuggling issues occur due to deviations from the current HTTP specifications and multiple libraries not following RFC7230. Furthermore, remediation of this vulnerability can be tricky depending on whether you are a frontend or backend project maintainer. As such, Snyk has researched the remediation implemented by open source projects currently and categorized it as follows. To simplify, all remediation points are covered along with reasoning to which smuggling attack type this will remediate against. In an ideal scenario, all of the points mentioned below should be used to provide a Defense-in-Depth approach solution.
Prioritize Transfer-Encoding over Content-Length
Remediation: This remediation will prevent CL:TE and TE:CL attacks
Scope: Frontend, Backend
Details: When a request with both a Transfer-Encoding: chunked header and Content-length is received, the transfer-encoding header should be prioritized over Content-Length. This is referenced in RFC 7230 Section 3.3.3#3.
Disallow requests with both Content-length and Transfer encoding and double Content-Length headers
Remediation: This remediation will prevent CL:CL, CL:TE and TE:CL attacks
Scope: Backend, Frontend, Backend, Upstream libraries
Details: This can be seen as a better alternative to “Prioritize Transfer-Encoding over Content-Length” solution. Runtime platforms such as Node.js have used this solution to remediate against request smuggling where any requests with both headers are returned with an HTTP 400 response.
Snyk believes this technique to be an ideal fix to prevent smuggling issues. However, considerations should be taken on how the fix is applied; especially if the fix is applied to a low-level HTTP library or an upstream engine numerous packages, such as a frontend, depend upon.
When remediation HTTP request smuggling issues, RFC 7230 #3.3.3 should be followed. Section 3.3.3#3 in RFC 7230 states:
“If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.”
However, this is different from what is stated within RFC 2616 4.4#3:
“If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.”
It should be noted that RFC 2616 4.4#3 is obsolete and has been replaced by RFC 7230. RFC 7230 should be taken into consideration when implementing a fix. As such, when processing HTTP requests with both a Content-Length and Transfer encoding header, the correct behavior here is that the frontend should strip out the Content-length header before forwarding the request to a downstream backend, not return an HTTP 400 response header. The same should be done to requests with multiple Content-Length headers as stated in RFC 7230#3.3.2.
As mentioned in RFC 7230 Section 3.3.2, if an HTTP request is received with multiple Content-Length headers with different length values, this can be remediated with an HTTP 400 response, or the duplicated field-values should be replaced with a single valid Content-Length field. Snyk recommends that low-level HTTP libraries opt to replace multiple headers with a single valid header.
Disallow malformed Transfer-Encoding headers and correct Processing of Multiple TE values
Remediation: This remediation will prevent TE:TE attacks.
Scope: Frontend, Backend
Details: If both a frontend and backend prioritizes the Transfer-Encoding header, it could allow smuggling attacks where an attacker inserts two Transfer-Encoding headers, one which would be ignored by the frontend and is processed by the backend and vice versa. As such, the following type of header variations should be rejected.
| TE header variation | Details |
|---|---|
| Transfer-Encoding: chunked | Spaces before the “chunked” value are removed. |
| Transfer-Encoding : chunked | The header contains extra spaces. This is in violation of RFC 7230. |
| Transfer-Encoding: chunked | Trailing characters before the header. |
| Transfer-Encoding: chunk | The value “chunk” is provided which gets. Normalized by the server and is treated as chunked encoding. |
| Transfer-Encoding: chunked | Multiple spaces before the “chunked” value”. |
| Transfer-Encoding: “chunked” | The header value is provided inside double quotes which get normalized. Single quotes should also be taken into consideration. |
| Transfer-Encoding: chunked | CRLF characters are provided before the “chunked” value. |
| Transfer-Encoding: xchunked | The invalid character “x” will be removed by the backend server. Considerations should also be taken into account for unicode values provided before “chunked”. Other examples include “ch-nked”. |
However, it should be noted that it’s still possible for attackers to find a malformed header variation of “chunked” encoding that is not documented above. As such, this alone should not be taken into account for remediation. A better approach would be to disallow requests with both Content-Length and Transfer-Encoding, along with disallowing malformed headers.
Lastly, It should also be noted that if the “chunked” value is specified with other Transfer-Encoding values such as “gzip” or “deflate”, it shouldn’t be overlooked and Transfer-Encoding should be prioritized over Content-Length. An example of this vulnerability occurring can be seen in CVE-2019-16786. If an HTTP request is sent with the following Transfer-Encoding values, the “chunked” value should be correctly identified and prioritized:
1
Transfer-Encoding: gzip, chunked
Within a Transfer-Encoding header, several values can be listed separated by a comma. However, there might be cases where a frontend might only identify the “gzip” value and as such will prioritize the Content-Length header, and the backend might process this as a chunked request resulting in a CL:TE attack. Snyk recommends, whenever multiple values are specified that they are checked correctly and, if “chunked” is specified, then Transfer-Encoding be prioritized. Furthermore, if multiple transfer encoding headers are specified, the “chunked” value should only be present as the last value after other transfer encoding values are specified. This is stated in RFC 7230 Section 3.3.1.
Wrapping up
To conclude, HTTP request smuggling can be a confusing vulnerability to understand and patch against. This blog hopes to help maintainers write efficient patches and secure their open source projects.
It is also worth noting that this blog post only covers two techniques of HTTP request smuggling and does not provide detailed information regarding different exploitation scenarios. The following article from Security researcher ZeddYu has covered HTTP request smuggling extensively and has provided in-depth details regarding each attack smuggling vector: Zeddy Yu:Help you understand HTTP Smuggling in one article.


[1]
the hotel and a ride in the city will cost you no more than 6 euro .
[2]
hotel has its own private car park which from memory was about 10 euro and about 10 euro a day .


This site demonstrates key functionality of Azure Search. For more information email the search services team or follow our blog.
Search real estate listings and display results in Bing maps


To reproduce this issue, follow these steps: 1) Make sure Snap Links Plus (SLP) is configured to display the number of links selected. 2) Double-click on word "issue" above and press Ctrl-C so clipboard content is known for subsequent comparison. 3) Position pointer on "A". 4) Initiate selection (e.g., Ctrl & Alt + Left Click) 5) Move pointer to "B". 6) Move pointer to "C". 7) Move pointer to "D". 8) SLP should show 4 links selected. 9) Complete selection - release mouse button and keys. 10) Paste clipboard. Should be the word "issue", instead of the links that were selected.


Determinate progress-bar
<mat-progress-bar mode="determinate">
is a horizontal progress-bar for
indicating progress and activity.
Indeterminate progress-bar
<mat-progress-bar mode="indeterminate">
is a horizontal progress-bar for
indicating progress and activity.
Buffer progress-bar
<mat-progress-bar mode="buffer">
is a horizontal progress-bar for
indicating progress and activity.
Query progress-bar
<mat-progress-bar mode="query">
is a horizontal progress-bar for
indicating progress and activity.
Colored progress-bar
<mat-progress-bar mode="determinate">
is a horizontal progress-bar for
indicating progress and activity.
Progress bar configuration
Primary
Accent
Warn
Determinate
Indeterminate
Buffer
Query
Result


fun start(frequency: Float): Unit
Starts the animation
frequency - Float The animation frequency
frequency


The C++ language interface for MPI includes the predefined error handler MPI::ERRORS_THROW_EXCEPTIONS for use with the Set_errhandler() member functions. MPI::ERRORS_THROW_EXCEPTIONS can only be set or retrieved by C++ functions. If a non-C++ program causes an error that invokes the MPI::ERRORS_THROW_EXCEPTIONS error handler, the exception will pass up the calling stack until C++ code can catch it. If there is no C++ code to catch it, the behavior is undefined. In a multi-threaded environment or if a non-blocking MPI call throws an exception while making progress in the background, the behavior is implementation dependent.
The error handler MPI::ERRORS_THROW_EXCEPTIONS causes an MPI::Exception to be thrown for any MPI result code other than MPI::SUCCESS. The public interface to MPI::Exception class is defined as follows:
namespace MPI { class Exception { public: Exception(int error_code); int Get_error_code() const; int Get_error_class() const; const char *Get_error_string() const; }; };
Advice
to implementors.
The exception will be thrown within the body of MPI::ERRORS_THROW_EXCEPTIONS. It is expected that control will be returned to the user when the exception is thrown. Some MPI functions specify certain return information in their parameters in the case of an error and MPI_ERRORS_RETURN is specified. The same type of return information must be provided when exceptions are thrown.
For example, MPI_WAITALL puts an error code for each request in the corresponding entry in the status array and returns MPI_ERR_IN_STATUS. When using MPI::ERRORS_THROW_EXCEPTIONS, it is expected that the error codes in the status array will be set appropriately before the exception is thrown.
( End of advice to implementors.)


How to convert existing CDT workspaces
You only need to convert your workspace if CDT is still used to build your projects and the Project.meta files do not exist yet.
Only one developer in a team has to convert the workspace only once!
Conversion means, that Project.meta files are generated and filled with the informationen from the .project and .cproject files. bake does not read the .project and .cproject files, only the Project.meta files.
The converter is an export wizard, which can be found under "File->Export" or in the context menu of the Project Explorer:
Please note the following things:
- The conversion is not a 1:1 conversion. That means, that the tool can only be 99% perfect. There might by some small issues, which have to be adapted manually. You can find it out by simply trying to build your project with bake.
- It is possible to specify a ruby script in the wizard window, which can do these manual adaptions. This can make sense, if you want to convert the workspace several times before completely switching to bake.
- To convert only a subset of projects instead of the whole workspace, select the appropriate projects in the Project Explorer before starting the export wizard. Ensure that the checkbox shown above is marked.
- If you are satisfied with the results, replace the .cproject and .project files in your repository.
| Steps to do with .cproject and .project files |
| delete the files |
| remove the projects from your workspace in Eclipse (but do not delete the contents from your disk) |
| import the projects again via the bake import wizard to generate wrapper files for Eclipse |
| commit the change to your source control system |
Do not commit these .project and .cproject files anymore. Instead, commit the changes in Project.meta files.
You still need .cproject and .project files for working under Eclipse, that's why you have to import the projects again via the bake import wizard.


Thanks for coming and helping out Bus Mall
Please select the 25 items you would be most likely to purchase from us. Thanks.
Begin Questionaire


Describe your plugin here.
{
"name": "PythonServer",
"type": "native-python",
"version": "0.1.0",
"api_version": "0.1.2",
"description": "[TODO: describe this plugin with one sentence.]",
"tags": [],
"ui": "",
"inputs": null,
"outputs": null,
"flags": [],
"icon": "extension",
"env": "",
"requirements": [],
"dependencies": ["gywgithub/ImJoy-Demo-Plugins:ResultWindow",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20I.imjoy.html",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20II.imjoy.html",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20III.imjoy.html",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20IV.imjoy.html",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20V.imjoy.html",
"https://github.com/gywgithub/ImJoy-Demo-Plugins/blob/master/examples/Function%20VI.imjoy.html"]
}


LEADERSHIP
Ella Malkin, P.E.,
President
Ella Malkin is an expert licensed engineer with 20 years of
experience in design, project management and field supervision.
She is personally involved in every project to ensure quality and
innovation. Her expertise includes mechanical, electrical, plumbing
and fire protection for renovation projects, landmark buildings, and
new, out-of-the ground building construction. Ella has extensive
experience in commercial, residential, corporate, food service,
education, medical and technology facilities.
Many of her projects are for repeat clients who have worked with
her for over 15 years due to her attentiveness and dedication to
each project and client, as well as comprehensive knowledge in
selecting high-quality systems, providing energy-efficient solutions,
and keeping projects on budget. She provides strategic phasing
solutions to keep buildings operational during renovatio
Artem Zolotarev, P.E., LEED AP
President
Artem Zolotarev has 12+ years of professional experience in MEP
engineering and design for commercial, residential and hotel high
rise buildings as well as sports and entertainment complexes. At
AVCON Artem’s responsibilities include project management and
quality control. His technical expertise include electrical power
systems, lighting control, and fire protection and life safety
systems. Although his primary concentration is on electrical
engineering, Artem takes an active role in all aspects of MEP
design.
Artem holds a Master’s degree in Electrical Engineering from
Polytechnic University. He is a licensed Professional Engineer in the
states of New York and New Jersey. Artem is also a US Green
Building Council LEED Accredited Professional.


ws is a simple to use, blazing fast, and thoroughly tested WebSocket client and server implementation.
Passes the quite extensive Autobahn test suite: server, client.
Note: This module does not work in the browser. The client in the docs is a
reference to a back end with the role of a client in the WebSocket
communication. Browser clients must use the native
WebSocket
object. To make the same code work seamlessly on Node.js and the browser, you
can use one of the many wrappers available on npm, like
isomorphic-ws.
protocolVersion: 8
)protocolVersion: 13
)npm install ws
There are 2 optional modules that can be installed along side with the ws module. These modules are binary addons which improve certain operations. Prebuilt binaries are available for the most popular platforms so you don't necessarily need to have a C++ compiler installed on your machine.
npm install --save-optional bufferutil
: Allows to efficiently perform
operations such as masking and unmasking the data payload of the WebSocket
frames.npm install --save-optional utf-8-validate
: Allows to efficiently check if a
message contains valid UTF-8 as required by the spec.See /doc/ws.md
for Node.js-like docs for the ws classes.
ws supports the permessage-deflate extension which enables the client and server to negotiate a compression algorithm and its parameters, and then selectively apply it to the data payloads of each WebSocket message.
The extension is disabled by default on the server and enabled by default on the client. It adds a significant overhead in terms of performance and memory consumption so we suggest to enable it only if it is really needed.
Note that Node.js has a variety of issues with high-performance compression, where increased concurrency, especially on Linux, can lead to catastrophic memory fragmentation and slow performance. If you intend to use permessage-deflate in production, it is worthwhile to set up a test representative of your workload and ensure Node.js/zlib will handle it with acceptable performance and memory usage.
Tuning of permessage-deflate can be done via the options defined below. You can
also use zlibDeflateOptions
and zlibInflateOptions
, which is passed directly
into the creation of raw deflate/inflate streams.
See the docs for more options.
const WebSocket = require('ws');
const wss = new WebSocket.Server({
port: 8080,
perMessageDeflate: {
zlibDeflateOptions: {
// See zlib defaults.
chunkSize: 1024,
memLevel: 7,
level: 3
},
zlibInflateOptions: {
chunkSize: 10 * 1024
},
// Other options settable:
clientNoContextTakeover: true, // Defaults to negotiated value.
serverNoContextTakeover: true, // Defaults to negotiated value.
serverMaxWindowBits: 10, // Defaults to negotiated value.
// Below options specified as default values.
concurrencyLimit: 10, // Limits zlib concurrency for perf.
threshold: 1024 // Size (in bytes) below which messages
// should not be compressed.
}
});
The client will only use the extension if it is supported and enabled on the
server. To always disable the extension on the client set the
perMessageDeflate
option to false
.
const WebSocket = require('ws');
const ws = new WebSocket('ws://www.host.com/path', {
perMessageDeflate: false
});
const WebSocket = require('ws');
const ws = new WebSocket('ws://www.host.com/path');
ws.on('open', function open() {
ws.send('something');
});
ws.on('message', function incoming(data) {
console.log(data);
});
const WebSocket = require('ws');
const ws = new WebSocket('ws://www.host.com/path');
ws.on('open', function open() {
const array = new Float32Array(5);
for (var i = 0; i < array.length; ++i) {
array[i] = i / 2;
}
ws.send(array);
});
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws) {
ws.on('message', function incoming(message) {
console.log('received: %s', message);
});
ws.send('something');
});
const fs = require('fs');
const https = require('https');
const WebSocket = require('ws');
const server = new https.createServer({
cert: fs.readFileSync('/path/to/cert.pem'),
key: fs.readFileSync('/path/to/key.pem')
});
const wss = new WebSocket.Server({ server });
wss.on('connection', function connection(ws) {
ws.on('message', function incoming(message) {
console.log('received: %s', message);
});
ws.send('something');
});
server.listen(8080);
const http = require('http');
const WebSocket = require('ws');
const server = http.createServer();
const wss1 = new WebSocket.Server({ noServer: true });
const wss2 = new WebSocket.Server({ noServer: true });
wss1.on('connection', function connection(ws) {
// ...
});
wss2.on('connection', function connection(ws) {
// ...
});
server.on('upgrade', function upgrade(request, socket, head) {
const pathname = url.parse(request.url).pathname;
if (pathname === '/foo') {
wss1.handleUpgrade(request, socket, head, function done(ws) {
wss1.emit('connection', ws, request);
});
} else if (pathname === '/bar') {
wss2.handleUpgrade(request, socket, head, function done(ws) {
wss2.emit('connection', ws, request);
});
} else {
socket.destroy();
}
});
server.listen(8080);
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
// Broadcast to all.
wss.broadcast = function broadcast(data) {
wss.clients.forEach(function each(client) {
if (client.readyState === WebSocket.OPEN) {
client.send(data);
}
});
};
wss.on('connection', function connection(ws) {
ws.on('message', function incoming(data) {
// Broadcast to everyone else.
wss.clients.forEach(function each(client) {
if (client !== ws && client.readyState === WebSocket.OPEN) {
client.send(data);
}
});
});
});
const WebSocket = require('ws');
const ws = new WebSocket('wss://echo.websocket.org/', {
origin: 'https://websocket.org'
});
ws.on('open', function open() {
console.log('connected');
ws.send(Date.now());
});
ws.on('close', function close() {
console.log('disconnected');
});
ws.on('message', function incoming(data) {
console.log(`Roundtrip time: ${Date.now() - data} ms`);
setTimeout(function timeout() {
ws.send(Date.now());
}, 500);
});
For a full example with a browser client communicating with a ws server, see the examples folder.
Otherwise, see the test cases.
// If the WebSocket is closed before the following send is attempted
ws.send('something');
// Errors (both immediate and async write errors) can be detected in an optional
// callback. The callback is also the only way of being notified that data has
// actually been sent.
ws.send('something', function ack(error) {
// If error is not defined, the send has been completed, otherwise the error
// object will indicate what failed.
});
// Immediate errors can also be handled with `try...catch`, but **note** that
// since sends are inherently asynchronous, socket write failures will *not* be
// captured when this technique is used.
try {
ws.send('something');
} catch (e) {
/* handle error */
}
The remote IP address can be obtained from the raw socket.
const WebSocket = require('ws');
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws, req) {
const ip = req.connection.remoteAddress;
});
When the server runs behind a proxy like NGINX, the de-facto standard is to use
the X-Forwarded-For
header.
wss.on('connection', function connection(ws, req) {
const ip = req.headers['x-forwarded-for'].split(/\s*,\s*/)[0];
});
Sometimes the link between the server and the client can be interrupted in a way that keeps both the server and the client unaware of the broken state of the connection (e.g. when pulling the cord).
In these cases ping messages can be used as a means to verify that the remote endpoint is still responsive.
const WebSocket = require('ws');
function noop() {}
function heartbeat() {
this.isAlive = true;
}
const wss = new WebSocket.Server({ port: 8080 });
wss.on('connection', function connection(ws) {
ws.isAlive = true;
ws.on('pong', heartbeat);
});
const interval = setInterval(function ping() {
wss.clients.forEach(function each(ws) {
if (ws.isAlive === false) return ws.terminate();
ws.isAlive = false;
ws.ping(noop);
});
}, 30000);
Pong messages are automatically sent in response to ping messages as required by the spec.
Just like the server example above your clients might as well lose connection without knowing it. You might want to add a ping listener on your clients to prevent that. A simple implementation would be:
const WebSocket = require('ws');
function heartbeat() {
clearTimeout(this.pingTimeout);
// Use `WebSocket#terminate()` and not `WebSocket#close()`. Delay should be
// equal to the interval at which your server sends out pings plus a
// conservative assumption of the latency.
this.pingTimeout = setTimeout(() => {
this.terminate();
}, 30000 + 1000);
}
const client = new WebSocket('wss://echo.websocket.org/');
client.on('open', heartbeat);
client.on('ping', heartbeat);
client.on('close', function clear() {
clearTimeout(this.pingTimeout);
});
Use a custom http.Agent
implementation like https-proxy-agent or
socks-proxy-agent.
We're using the GitHub releases for changelog entries.


xTimerPendFunctionCallFromISR()
[Timer API]
timers.h
BaseType_t xTimerPendFunctionCallFromISR(
PendedFunction_t xFunctionToPend,
void *pvParameter1,
uint32_t ulParameter2,
BaseType_t *pxHigherPriorityTaskWoken );
Used from application interrupt service
routines to defer the execution of a function to
the RTOS daemon task (the timer service task,
hence this function is implemented in timers.c
and is prefixed with 'Timer').
Ideally an interrupt service routine (ISR) is
kept as short as possible, but sometimes an ISR
either has a lot of processing to do, or needs to
perform processing that is not deterministic. In
these cases xTimerPendFunctionCallFromISR() can
be used to defer processing of a function to the
RTOS daemon task.
A mechanism is provided that allows the
interrupt to return directly to the task that
will subsequently execute the pended function.
This allows the callback function to execute
contiguously in time with the interrupt - just as
if the callback had executed in the interrupt
itself.
Functions that can be deferred to the RTOS
daemon task must have the following prototype:
void vPendableFunction( void *
pvParameter1, uint32_t ulParameter2 );
The pvParameter1 and ulParameter2 are provided for use by the
application code.
INCLUDE_xTimerPendFunctionCall() and
configUSE_TIMERS must both be set to 1 for
xTimerPendFunctionCallFromISR() to be available.
- Parameters:
-
| xFunctionToPend |
The function to
execute from the timer service/ daemon
task. The function must conform to the
PendedFunction_t prototype as shown
above. |
| pvParameter1 |
The value of the
callback function's first parameter.
The parameter has a void * type to
allow it to be used to pass any type.
For example, integer types can be cast
to a void *, or the void * can be used
to point to a structure. |
| ulParameter2 |
The value of the
callback function's second
parameter. |
| pxHigherPriorityTaskWoken |
As mentioned
above, calling
xTimerPendFunctionCallFromISR() will
result in a message being sent to the
RTOS timer daemon task. If the priority
of the daemon task (which is set using
configTIMER_TASK_PRIORITY in
FreeRTOSConfig.h) is higher than the
priority of the currently running task
(the task the interrupt interrupted)
then *pxHigherPriorityTaskWoken will be
set to pdTRUE within
xTimerPendFunctionCallFromISR(),
indicating that a context switch should
be requested before the interrupt
exits. For that reason
*pxHigherPriorityTaskWoken must be
initialised to pdFALSE. See the example
code below. |
- Returns:
- pdPASS is returned if the message was
successfully sent to the RTOS timer daemon
task, otherwise pdFALSE is returned.
Example usage:
/* The callback function that will execute in the context of the daemon task.
Note callback functions must all use this same prototype. */
void vProcessInterface( void *pvParameter1, uint32_t ulParameter2 )
{
BaseType_t xInterfaceToService;
/* The interface that requires servicing is passed in the second
parameter. The first parameter is not used in this case. */
xInterfaceToService = ( BaseType_t ) ulParameter2;
/* ...Perform the processing here... */
}
/* An ISR that receives data packets from multiple interfaces */
void vAnISR( void )
{
BaseType_t xInterfaceToService, xHigherPriorityTaskWoken;
/* Query the hardware to determine which interface needs processing. */
xInterfaceToService = prvCheckInterfaces();
/* The actual processing is to be deferred to a task. Request the
vProcessInterface() callback function is executed, passing in the
number of the interface that needs processing. The interface to
service is passed in the second parameter. The first parameter is
not used in this case. */
xHigherPriorityTaskWoken = pdFALSE;
xTimerPendFunctionCallFromISR( vProcessInterface,
NULL,
( uint32_t ) xInterfaceToService,
&xHigherPriorityTaskWoken );
/* If xHigherPriorityTaskWoken is now set to pdTRUE then a context
switch should be requested. The macro used is port specific and will
be either portYIELD_FROM_ISR() or portEND_SWITCHING_ISR() - refer to
the documentation page for the port being used. */
portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}
Copyright (C) 2004-2010 Richard Barry. Copyright
(C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html
content and documentation included in the
FreeRTOSTM
distribution or available on this site are the
exclusive property of Real Time Engineers Ltd..
See the files license.txt (included in the
distribution) and this copyright notice for more information.
FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers
Ltd.
|


{{stringInterpolation}} | {{numberInterpolation}}
Property Binding
is this styled
javascript event - styled
style color
Custom property binding


Check to make sure the environment variables for the Microsoft Visual C++
6.0 compiler is available. The variables are set from a batch file
vcvars32.bat provided with the Microsoft installation.
How do I customize a desktop icon for STM?
First, create a desktop icon for Express. This can be done
in two ways:
Locate the Express.exe (usually in
C:\Express\bin\pc) file and drag the file
to desktop.
Or use the pop-up menu for the application
(right mouse click) and select Create
Shortcut.
Then using the icon pop-up menu (select the Rename
option), rename the icon to STM.
Then, using the icon pop-up menu, select the Properties
option.
Then, selet the Shortcut tab on the properties menu, and
set the Start in: field to be the XPstm directory path.


Custom Counting Sequences
Count by:
Count to:
Go!
Create a list of the numbers in your custom counting up sequence


Generating a sphere from 500 points projected at a random angle at a distance 100 from the origin —
source


public class SetupIntent implements StripeIntent
A class SetupIntent
guides you through the process of setting up a customer's payment credentials for
future payments.
See the API Reference for SetupIntents for more information.
class SetupIntent
,
API Reference for SetupIntents@Nullable public com.stripe.android.model.StripeIntent.NextActionType getNextActionType()
public boolean requiresAction()
public boolean requiresConfirmation()
@Nullable public java.lang.String getId()
Unique identifier for the object.
@Nullable public com.stripe.android.model.SetupIntent.CancellationReason getCancellationReason()
Reason for cancellation of this
class SetupIntent
public long getCreated()
Time at which the object was created.
Measured in seconds since the Unix epoch.
@Nullable public java.lang.String getClientSecret()
The client secret of this SetupIntent. Used for client-side retrieval using a publishable key.
The client secret can be used to complete payment setup from your frontend. It should not be stored, logged, embedded in URLs, or exposed to anyone other than the customer. Make sure that you have TLS enabled on any page that includes the client secret.
@Nullable public java.lang.String getDescription()
An arbitrary string attached to the object.
Often useful for displaying to users.
public boolean isLiveMode()
Has the value
true
if the object exists in live mode or the valuefalse
if the object exists in test mode.
@Nullable public PaymentMethod getPaymentMethod()
The expanded
class PaymentMethod
represented by paymentMethodId.
class PaymentMethod
@Nullable public java.lang.String getPaymentMethodId()
ID of the payment method used with this
class SetupIntent
@NotNull public java.util.List<java.lang.String> getPaymentMethodTypes()
The list of payment method types
(e.g. card) that this class SetupIntent
is allowed to set up.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.Status getStatus()
of this class SetupIntent
.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.Usage getUsage()
Indicates how the payment method is intended to be used in the future.
Use StripeIntent.Usage.OnSession if you intend to only reuse the payment method when the customer is in your checkout flow. Use StripeIntent.Usage.OffSession if your customer may or may not be in your checkout flow. If not provided, this value defaults to StripeIntent.Usage.OffSession.
@Nullable public com.stripe.android.model.SetupIntent.Error getLastSetupError()
The error encountered in the previous
class SetupIntent
confirmation.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.NextActionData getNextActionData()
@Nullable public java.lang.String component1()
Unique identifier for the object.
@Nullable public com.stripe.android.model.SetupIntent.CancellationReason component2()
Reason for cancellation of this
class SetupIntent
public long component3()
Time at which the object was created.
Measured in seconds since the Unix epoch.
@Nullable public java.lang.String component4()
The client secret of this SetupIntent. Used for client-side retrieval using a publishable key.
The client secret can be used to complete payment setup from your frontend. It should not be stored, logged, embedded in URLs, or exposed to anyone other than the customer. Make sure that you have TLS enabled on any page that includes the client secret.
@Nullable public java.lang.String component5()
An arbitrary string attached to the object.
Often useful for displaying to users.
public boolean component6()
Has the value
true
if the object exists in live mode or the valuefalse
if the object exists in test mode.
@Nullable public PaymentMethod component7()
The expanded
class PaymentMethod
represented by paymentMethodId.
class PaymentMethod
@Nullable public java.lang.String component8()
ID of the payment method used with this
class SetupIntent
@NotNull public java.util.List<java.lang.String> component9()
The list of payment method types
(e.g. card) that this class SetupIntent
is allowed to set up.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.Status component10()
of this class SetupIntent
.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.Usage component11()
Indicates how the payment method is intended to be used in the future.
Use StripeIntent.Usage.OnSession if you intend to only reuse the payment method when the customer is in your checkout flow. Use StripeIntent.Usage.OffSession if your customer may or may not be in your checkout flow. If not provided, this value defaults to StripeIntent.Usage.OffSession.
@Nullable public com.stripe.android.model.SetupIntent.Error component12()
The error encountered in the previous
class SetupIntent
confirmation.
class SetupIntent
@Nullable public com.stripe.android.model.StripeIntent.NextActionData component13()
@NotNull public SetupIntent copy(@Nullable java.lang.String id, @Nullable com.stripe.android.model.SetupIntent.CancellationReason cancellationReason, long created, @Nullable java.lang.String clientSecret, @Nullable java.lang.String description, boolean isLiveMode, @Nullable PaymentMethod paymentMethod, @Nullable java.lang.String paymentMethodId, @NotNull java.util.List<java.lang.String> paymentMethodTypes, @Nullable com.stripe.android.model.StripeIntent.Status status, @Nullable com.stripe.android.model.StripeIntent.Usage usage, @Nullable com.stripe.android.model.SetupIntent.Error lastSetupError, @Nullable com.stripe.android.model.StripeIntent.NextActionData nextActionData)
A class SetupIntent
guides you through the process of setting up a customer's payment credentials for
future payments.
See the API Reference for SetupIntents for more information.
class SetupIntent
,
API Reference for SetupIntents@NotNull public java.lang.String toString()
A class SetupIntent
guides you through the process of setting up a customer's payment credentials for
future payments.
See the API Reference for SetupIntents for more information.
class SetupIntent
,
API Reference for SetupIntentspublic int hashCode()
A class SetupIntent
guides you through the process of setting up a customer's payment credentials for
future payments.
See the API Reference for SetupIntents for more information.
class SetupIntent
,
API Reference for SetupIntentspublic boolean equals(@Nullable java.lang.Object p)
A class SetupIntent
guides you through the process of setting up a customer's payment credentials for
future payments.
See the API Reference for SetupIntents for more information.
class SetupIntent
,
API Reference for SetupIntents@JvmStatic @Nullable public static SetupIntent fromJson(@Nullable org.json.JSONObject jsonObject)


The Chronicles of Riddick
The Chronicles of Riddick is a movie starring Vin Diesel, Judi Dench, and Colm Feore. The wanted criminal Riddick arrives on a planet called Helion Prime, and finds himself up against an invading empire called the Necromongers, an...


|
ARK2D
1.0
Game development framework for Windows, Mac OS X and Android.
|
Create this class in your main method. It is the main entry point for the library. More...
#include <GameContainer.h>
Public Member Functions | |
| GameContainer (Game &game, int width, int height, int bpp, bool fullscreen) | |
| void | setTitle (const std::string title) |
| bool | isVerbose () |
| void | setVerbose (bool v) |
| bool | isFullscreen () |
| void | setFullscreen (bool fs) |
| bool | isTouchMode () |
| void | setTouchMode (bool tm) |
| void | setSize (int width, int height) |
| bool | isResizable () |
| void | setResizable (bool fs) |
| void | setScaleToWindow (bool b) |
| void | setScaleLock (bool b) |
| unsigned int | getFPS () |
| void | setIcon (const std::string &path) |
| void | start () |
| void | setCursorVisible (bool b) |
| void | setClearColor (const Color &color) |
| const Color & | getClearColor () |
| GameTimer * | getTimer () |
| const ARK::Geometry::Rectangle< int > & | getWindowRectangle () const |
| const Game & | getGame () const |
| const Input & | getInput () const |
| Renderer * | getRenderer () const |
| unsigned int | getWidth () const |
| unsigned int | getHeight () const |
| unsigned int | getDynamicWidth () const |
| unsigned int | getDynamicHeight () const |
| unsigned int | getScreenWidth () const |
| unsigned int | getScreenHeight () const |
| float | getScale () const |
| float | getScaleX () const |
| float | getScaleY () const |
| void | setScaleX (float f) |
| void | setScaleY (float f) |
| float | getTranslateX () const |
| float | getTranslateY () const |
| void | setTranslateX (float f) |
| void | setTranslateY (float f) |
| vector< Gamepad * > * | getGamepads () |
| string | getResourcePath () const |
| int | getResizeBehaviour () |
| void | setResizeBehaviour (int b) |
| void | setWillLoadDefaultFont (bool b) |
| unsigned int | getOrientation () |
| unsigned int | getScreenOrientation () |
| unsigned int | getPreviousScreenOrientation () |
| void | setOrientationInverted (bool b) |
| bool | isOrientationInverted () |
| bool | is2in1Enabled () |
| void | saveScreenshot (string filename) |
| bool | isShowingFPS () |
| void | setShowingFPS (bool b) |
| void | resizeBehaviour (int width, int height) |
| void | close () const |
| virtual | ~GameContainer () |
| void | enable2D () |
| void | disable2D () |
| void | swapBuffers () |
| int | getGlobalMouseX () const |
| int | getGlobalMouseY () const |
| GameContainerPlatform * | getPlatformSpecific () |
Public Attributes | |
| unsigned int | m_originalWidth |
| unsigned int | m_originalHeight |
| unsigned int | m_width |
| unsigned int | m_height |
| bool | m_bRunning |
| GameContainerPlatform | m_platformSpecific |
Static Public Attributes | |
| static const unsigned int | ORIENTATION_PORTRAIT = 0 |
| static const unsigned int | ORIENTATION_LANDSCAPE = 1 |
| static const unsigned int | ORIENTATION_DUMMY = 2 |
| static const int | RESIZE_BEHAVIOUR_SCALE = 0 |
| static const int | RESIZE_BEHAVIOUR_NOSCALE = 1 |
Friends | |
| class | ARK::Core::GameContainerPlatform |
| class | ARK::Graphics::Renderer |
| class | Log |
| class | ARK::Core::Game |
Create this class in your main method. It is the main entry point for the library.
The main container for a game that holds references to context-aware input, the game itself and controls the game loop with frame limiting, etc.
Definition at line 78 of file GameContainer.h.
| ARK::Core::GameContainer::GameContainer | ( | Game & | game, |
| int | width, | ||
| int | height, | ||
| int | bpp, | ||
| bool | fullscreen | ||
| ) |
Definition at line 18 of file GameContainerAndroid.cpp.
|
virtual |
Definition at line 388 of file GameContainer.cpp.
| void ARK::Core::GameContainer::close | ( | ) | const |
Definition at line 141 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::disable2D | ( | ) |
Definition at line 166 of file GameContainer.cpp.
| void ARK::Core::GameContainer::enable2D | ( | ) |
Definition at line 113 of file GameContainer.cpp.
| const Color & ARK::Core::GameContainer::getClearColor | ( | ) |
Definition at line 225 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getDynamicHeight | ( | ) | const |
Definition at line 72 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getDynamicWidth | ( | ) | const |
Definition at line 68 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getFPS | ( | ) |
Definition at line 58 of file GameContainer.cpp.
| const Game & ARK::Core::GameContainer::getGame | ( | ) | const |
Definition at line 49 of file GameContainer.cpp.
| vector< Gamepad * > * ARK::Core::GameContainer::getGamepads | ( | ) |
Definition at line 217 of file GameContainer.cpp.
| int ARK::Core::GameContainer::getGlobalMouseX | ( | ) | const |
Definition at line 124 of file GameContainerAndroid.cpp.
| int ARK::Core::GameContainer::getGlobalMouseY | ( | ) | const |
Definition at line 127 of file GameContainerAndroid.cpp.
| unsigned int ARK::Core::GameContainer::getHeight | ( | ) | const |
Definition at line 65 of file GameContainer.cpp.
| const Input & ARK::Core::GameContainer::getInput | ( | ) | const |
Definition at line 52 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getOrientation | ( | ) |
Definition at line 330 of file GameContainer.cpp.
|
inline |
Definition at line 265 of file GameContainer.h.
| unsigned int ARK::Core::GameContainer::getPreviousScreenOrientation | ( | ) |
Definition at line 352 of file GameContainer.cpp.
| Renderer * ARK::Core::GameContainer::getRenderer | ( | ) | const |
Definition at line 55 of file GameContainer.cpp.
| int ARK::Core::GameContainer::getResizeBehaviour | ( | ) |
Definition at line 250 of file GameContainer.cpp.
| string ARK::Core::GameContainer::getResourcePath | ( | ) | const |
Definition at line 246 of file GameContainer.cpp.
| float ARK::Core::GameContainer::getScale | ( | ) | const |
Definition at line 91 of file GameContainer.cpp.
| float ARK::Core::GameContainer::getScaleX | ( | ) | const |
Definition at line 94 of file GameContainer.cpp.
| float ARK::Core::GameContainer::getScaleY | ( | ) | const |
Definition at line 97 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getScreenHeight | ( | ) | const |
Definition at line 87 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getScreenOrientation | ( | ) |
Definition at line 342 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getScreenWidth | ( | ) | const |
Definition at line 84 of file GameContainer.cpp.
| GameTimer * ARK::Core::GameContainer::getTimer | ( | ) |
Definition at line 229 of file GameContainer.cpp.
| float ARK::Core::GameContainer::getTranslateX | ( | ) | const |
Definition at line 101 of file GameContainer.cpp.
| float ARK::Core::GameContainer::getTranslateY | ( | ) | const |
Definition at line 104 of file GameContainer.cpp.
| unsigned int ARK::Core::GameContainer::getWidth | ( | ) | const |
Definition at line 62 of file GameContainer.cpp.
| const ARK::Geometry::Rectangle<int>& ARK::Core::GameContainer::getWindowRectangle | ( | ) | const |
| bool ARK::Core::GameContainer::is2in1Enabled | ( | ) |
Definition at line 367 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isFullscreen | ( | ) |
Definition at line 42 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isOrientationInverted | ( | ) |
Definition at line 364 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isResizable | ( | ) |
Definition at line 236 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isShowingFPS | ( | ) |
Definition at line 200 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isTouchMode | ( | ) |
Definition at line 371 of file GameContainer.cpp.
| bool ARK::Core::GameContainer::isVerbose | ( | ) |
Definition at line 35 of file GameContainer.cpp.
| void ARK::Core::GameContainer::resizeBehaviour | ( | int | width, |
| int | height | ||
| ) |
Definition at line 261 of file GameContainer.cpp.
| void ARK::Core::GameContainer::saveScreenshot | ( | string | filename | ) |
Definition at line 378 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setClearColor | ( | const Color & | color | ) |
Definition at line 221 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setCursorVisible | ( | bool | b | ) |
Definition at line 133 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::setFullscreen | ( | bool | fs | ) |
Definition at line 120 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::setIcon | ( | const std::string & | path | ) |
Definition at line 130 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::setOrientationInverted | ( | bool | b | ) |
Definition at line 356 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setResizable | ( | bool | fs | ) |
Definition at line 233 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setResizeBehaviour | ( | int | b | ) |
Definition at line 253 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setScaleLock | ( | bool | b | ) |
Definition at line 242 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setScaleToWindow | ( | bool | b | ) |
Definition at line 239 of file GameContainer.cpp.
|
inline |
Definition at line 136 of file GameContainer.h.
|
inline |
Definition at line 137 of file GameContainer.h.
| void ARK::Core::GameContainer::setShowingFPS | ( | bool | b | ) |
Definition at line 203 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setSize | ( | int | width, |
| int | height | ||
| ) |
Definition at line 91 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::setTitle | ( | const std::string | title | ) |
Definition at line 108 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setTouchMode | ( | bool | tm | ) |
Definition at line 374 of file GameContainer.cpp.
|
inline |
Definition at line 140 of file GameContainer.h.
|
inline |
Definition at line 141 of file GameContainer.h.
| void ARK::Core::GameContainer::setVerbose | ( | bool | v | ) |
Definition at line 38 of file GameContainer.cpp.
| void ARK::Core::GameContainer::setWillLoadDefaultFont | ( | bool | b | ) |
Definition at line 257 of file GameContainer.cpp.
| void ARK::Core::GameContainer::start | ( | ) |
Definition at line 137 of file GameContainerAndroid.cpp.
| void ARK::Core::GameContainer::swapBuffers | ( | ) |
|
friend |
Definition at line 82 of file GameContainer.h.
|
friend |
Definition at line 79 of file GameContainer.h.
|
friend |
Definition at line 80 of file GameContainer.h.
|
friend |
Definition at line 81 of file GameContainer.h.
| bool ARK::Core::GameContainer::m_bRunning |
Definition at line 254 of file GameContainer.h.
| unsigned int ARK::Core::GameContainer::m_height |
Definition at line 229 of file GameContainer.h.
| unsigned int ARK::Core::GameContainer::m_originalHeight |
Definition at line 226 of file GameContainer.h.
| unsigned int ARK::Core::GameContainer::m_originalWidth |
Definition at line 225 of file GameContainer.h.
| GameContainerPlatform ARK::Core::GameContainer::m_platformSpecific |
Definition at line 264 of file GameContainer.h.
| unsigned int ARK::Core::GameContainer::m_width |
Definition at line 228 of file GameContainer.h.
|
static |
Definition at line 154 of file GameContainer.h.
|
static |
Definition at line 153 of file GameContainer.h.
|
static |
Definition at line 152 of file GameContainer.h.
|
static |
Definition at line 267 of file GameContainer.h.
|
static |
Definition at line 266 of file GameContainer.h.


Always code as if the person who ends up maintaining your code will be a violent psychopath who knows where you live. -- [source]


| DOSE: |
240 mg |
oral |
DXM |
(liquid) |
I have been experimenting with DXM for about 3 months now, and have been using somewhere around 460 mg each time I have used it. I have been noticing that I keep craving it, and I don't really know if it's an addiction or not, because my life seems to be going normal while I am doing it, and also when I'm not.
In a moment of weakness, at about 11:00 PM, I braved the cold and trekked all the way to the convienience store to get something to get me high, Anything. I felt I needed it. So I bought a bottle of Robitussin Honey Cough, which was 4 oz. and 10 mg per 5 mL. I got back home, freezing, and drank down the bottle with a Monster energy drink.
I later realized that this was significantly less than I was used to taking, but I assumed it would be enough to get me through. I started feeling a slight buzz after a half an hour, quicker than usual, but not as strong. This feeling continued, slowly getting stronger, but not by much, and I noticed that other than feeling slightly 'altered' nothing else was up.
It was a bit disappointing, but also a bit of an eye-opener. I have become tolerant of lower doses now, and soon enough it will happen to my usual doses too. I'm thinking about taking a break from it, but that's easy to say when I am not craving a high. I know that tomorrow night I will be like 'man I need my dex' and perhaps go back to the store and buy more dex. But for now I consider myself taking a break.
I love dexing. It's a very peaceful experience, even at this low dose which I've become mostly tolerant to, it was nice.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


Click below to see the HTML version of this email.
http://link.cvs.com/r/XT5L403/VD2TA/XJUTY7/0G7JZA2/RXQOA/K9/t?a=XT5L403&b=0JUBN&c=NRA95NY&d=NWESAG&e=1&f=4898c1b09666923b1fee
****************************************************
CVS/pharmacy®
****************************************************
$15 OFF + FREE shipping.*
Check out this offer and more >
http://link.cvs.com/r/XT5L403/VD2TA/XJUTY7/0G7JZA2/KAWL6/K9/t?a=XT5L403&b=0JUBN&c=NRA95NY&d=NWESAG&e=1&f=4898c1b09666923b1fee
****************************************************
Add<EMAIL_ADDRESS>to your address book to continue receiving our emails.
****************************************************
*Offer available online only. Take $15 off your order of $60 or more. Expires 1/30/13 at 11:59 PM ET. To receive the $15 off $60 discount, enter coupon code SAVE15 at Checkout. Savings are not transferable. No cash back. To receive free standard shipping on your order, you must have $45 or more of products in your cart after all discounts are applied and enter coupon code SHIPFREE at Checkout.
Tax charged on precoupon price where required. Tax and shipping charges are not applicable towards your order total. Excludes prescriptions and gift cards. Offer not valid for orders placed on CVSphoto.com or CVS/pharmacy Optical. There may be an additional shipping and handling surcharge associated with particular items in your order. You will be notified of any such charges during Checkout if they apply to items in your order.
You are receiving this email because you indicated you wanted to be informed of the latest news and specials from CVS/pharmacy online. If you prefer not to receive future emails, please unsubscribe below. Please note that if you are opted in for other CVS/pharmacy email communications, you will continue to receive them unless you opt-out specifically for those.
http://link.cvs.com/u/XT5L403/VD2TA/XJUTY7/0G7JZA2/9Z/aHVibGVlcGg2MDZAdHVtYmxyLmNvbQ==/
© Copyright 2013 CVS.com
http://link.cvs.com/r/XT5L403/VD2TA/XJUTY7/0G7JZA2/O5YG2/K9/t?a=EM_Win_012813
One CVS Drive, Woonsocket, RI 02895
[[XT5L403-0JUBN-VD2TA-XJUTY7-0G7JZA2-M-M2-20130128-345510b22431e11]]


The Prince of Egypt (1998)
A Film Review by Mark O'Hara Visit Online Film Critics Society at http://www.ofcs.org
Important stories have a way of getting themselves retold. As part of the greatest story ever told, the story of Moses is done up with amazing technical skill and a good amount of interest in DreamWorks' 'The Prince of Egypt.'
 But he does not float serenely through the bulrushes; instead the infant is nearly ruined by crocodiles, hippopotami, and several boats. Finally he is rescued by the Queen (voice of Helen Mirren). So much for background, as the action jumps twenty or so years to show an unrealistic but hilarious chariot race between the two sons of Pharoah - Rameses (Ralph Fiennes) and the adopted Moses (Val Kilmer). There is a bond between the brothers that gives the very story mythic overtones, as we know the bond must eventually be shattered.
The meat of the story covers Moses' transformation from prince to Hebrew prophet. In one scene Moses runs upon his real sister, Miriam (Sandra Bullock), and brother, Aaron (Jeff Goldblum). Of course he rejects any notion of being related to these lowly slaves. The movie does a nice job of portraying the subtle reckonings of memory: Moses somehow recovers familiarity with Miriam's song, the one his mother sang to him in his infancy. But this is only the first in a series of revelations. After Moses irrevocably severs his connections with the Egyptian court, he takes to living with desert people, serving the priest of Midian, Jethro (Danny Glover). Moses and Jethro's daughter Tzipporah (Michelle Pfeiffer) marry, and after a time Moses (as a pre-Christ figure) gives up his private life as a shepherd and fulfills God's will.
'The Prince of Egypt' would not benefit from comparison to Cecil B. De Mille's classic 'The Ten Commandments.' 'Commandments' has the length and expanse of an epic - three hours of human struggle with no songs or animated whimsicality to lighten the subject matter. Yes, it is dated by the time in which it was made, but 'dated' does not mean 'bad.' The scope of the narrative in De Mille's movie is breath-taking and, besides, Charlton Heston's voice has it all over Val Kilmer's. 'Prince' probably benefits from it shortness, considering its main audience is children. The most remarkable miraculous events are touched upon - the infestations of frogs and locusts, pestilence, and a scary sequence - the origin of Passover, in which the first-born of Egypt (except those whose lintels are marked with the blood of the lamb) die with the most forlorn of exhalations. This animated feature does fair justice to these serious events.
The most striking, I think, is the Red Sea parting. This was my favorite scene, and my son's. It has been broadcast far that DreamWorks spent countless human hours depicting the attempt of Moses and the Jews to leave Egypt, only to be blocked by the sea. Rameses' legions are bearing down upon them, creating an almost perfect dramatic moment. Executive producer Jeffrey Katzenberg and his entire staff have accomplished a magnificent task, a five-plus minute sequence of terror and wonder that is as fascinating to watch as any moments filmed. What an idea - to show the ocean life as the fleeing people stumble under the vast curtains of parted water!
Other strong parts of the production include music and original storytelling. My wife and daughter - both very able musicians - liked the songs. Ten-year-old Kristin claims to have almost cried during "Deliver Us" and "All I Ever Wanted." I was struck by the layered texture of the song during which Hotep and Huy (voices of Martin Short and Steve Martin) are trying to upstage Moses and his 'trick' with his staff. We hear the names of Egyptian gods, voices chanting in the background, over top of which Short and Martin sing the main lyrics. (The lyrics themselves - "You're playing with the big boys now" - are not as strong as those in other songs, though.) Another fabulous sequence was a dream in which Moses continues to realize his Hebrew heritage. Although the sequence is not sung, it is dramatized through animated hieroglyphic-like figures. Moses as pictograph flees from legions of soldiers. Then in a stunning epiphany, Moses awakens and runs to the actual wall on which this verse from the book of Exodus is recorded (1:22): "Pharaoh then commanded all his subjects, 'Throw into the river every boy that is born to the Hebrews, but you may let all the girls live'." All his adoptive father can utter in explanation is, "They were only slaves."
The animation style is original and well-drawn. Many of the characters seem attenuated, rather Barbie-like in shape, but this is in keeping with the Egyptian imagery of the pictographs -dogs and gods of graceful slimness. Pharoah is done with kingly splendor, like the sphinxes and other likenesses modeled after him. Patrick Stewart lends an appropriately regal voice to this character. Most of the other actors perform admirably in their voice roles. They are, if nothing else, transparently efficient. Ones that draw positive attention to themselves include Stewart, Jeff Goldblum (you can see his cerebral fussiness in Aaron's mannerisms, too), Ralph Fiennes, and, in a tiny role, Danny Glover.
In all, 'The Prince of Egypt' is not to be missed. Forgo other holiday films for this one, regardless of your age. It is destined to be included in the canon of filmed Biblical literature and, besides, it's a lot of fun.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This web page presents my hobby projects from GitHub. I am using it also to gather and present some interesting links and resources related to those projects.
uPyBot with HuskyLens AI Camera
uPyBot Micro Python Robot
Wall-e Inspired Robot
BBK Web Page


As a Computer Science student you can browse this website to look for a suitable thesis or internship.
Deadlines for registration and submission can be found on the appropriate Blackboard pages.
All available theses and internships are on the Projects page.
Guidelines are in the
official documents below.
In order to be covered by the University of Antwerp insurance, it is mandatory to register your internship according
to the proper procedure.
Start the registration through
SisA (Request Mobility/Internship)
Please make sure to finalise the registration procedure (including the upload of all mandatory documents)
at the latest 2 weeks before the actual start of your internship.
The mandatory documents are generated through this application process.
If your registration is not finalised before the actual start of your traineeship, your insurance will not be
valid and you are NOT allowed to start the internship.


--- layout: post title: 'PGDay 2012: e sono 6!' date: '2012-09-02T19:30:00.000+02:00' author: Luca Ferrari tags: - pgday - postgresql modified_time: '2012-09-03T08:21:32.168+02:00' blogger_id: tag:blogger.com,1999:blog-1836481905487384887.post-8877136364344349406 blogger_orig_url: http://fluca1978.blogspot.com/2012/09/pgday-2012-e-sono-6.html permalink: /:year/:month/:day/:title.html ---


Living in Emacs
1 Package Manager
Dependencies: Cask, pallet.
Third party libraries are managed by Cask and pallet. Every morning I open up
the terminal and enter the emacs.d
directory, type cask update
will update
and byte-compile the packages listed in a file named Cask
. When you install
packages inside Emacs, pallet
makes sure that Cask
is updated accordingly.
2 Separate Editing from Viewing
View mode is a minor mode for viewing text but not editing it.
When View mode is enabled, commands that do not change the buffer contents are available as usual.  Most other commands beep and tell the user that the buffer is read-only.
Via view-mode
, we can separate editing mode from viewing mode in Emacs,
similar to editing/command mode separation in Vim. The main purpose is to avoid
accidental modification of the buffer when we only want to do non-modifying
operations, e.g., view, search, navigate, copy, etc. The major advantage over
evil-mode
is that view-mode
is lightweight, builtin and non-obstructive.
3 Bibliography Manager
Dependencies: helm, helm-bibtex, org-ref, PDF-tools, deft.
My configuration provide the following functionalities:
- Viewing PDF inside Emacs.
- Fuzzy-search bibtex entries by authors name, title, year and keywords.
- Associate PDF file, note file with a bibtex entry, and jump among them. Specifically, C-c r p opens the PDF file, C-c r n opens the note file and C-c r c jumps to the bibtex entry. For example, when you are viewing the PDF in Emacs, C-c r n opens the note file (create one if necessary), C-c r c jumps to the bibtex entry for this PDF file.
- Fuzzy-search notes.
- Quick insert citations to org files, which can be exported to TeX, PDF or HTML with appropriate reference list.
- Cleanup/format bibtex entries, auto construct keys for bibtex entries.
4 Editing Enhancement
4.1 Builtin Packages
whitespace
- automatically cleans up trailing spaces, empty lines at the beginning of files and etc.
4.2 MELPA Packages
writeroom-mode
- the buffer content is shown in the center, especially
useful when you have a wide screen. This is not compatible with
linum-mode
, which I never use. volatile-highlights
- highlights the change region. For example, when you redo or paste some texts to current buffer, the newly inserted texts are highlighted.
multiple-cursors
- edit multiple lines all at ones.
rainbow-delimiters
- change parenthesis colors according to the nested depth. Especially useful when debugging source codes with unbalanced parenthesis.
smartparens
- close the parenthesis or any custom pairs in a smart way.


Thus far are the words of Jeremiah.