Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. There are no required headers for this class of status code. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a
proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)
The client SHOULD continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed. See section 8.2.3 for detailed discussion of the use and handling of this status code.
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
This class of status code indicates that the client's request was successfully received, understood, and accepted.
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field. The response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource might result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.
The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.
The response MUST include the following header fields:
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
- Date
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.
Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of
the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
The different URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
- Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.
The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.
The requested resource resides temporarily under a different URI. Since the redirection MAY be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.
If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.
If the client is sending data, a server implementation using TCP SHOULD be careful to ensure that the client acknowledges receipt of the packet(s) containing the response, before the server closes the input connection. If the client continues sending data to the server after the close, the server's TCP stack will send a reset packet to the client, which may erase the client's unacknowledged input buffers before they can be read and interpreted by the HTTP application.
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
This code is reserved for future use.
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of an incoming response to determine if it is acceptable.
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough
information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that might not be possible and is not required.
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again.
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)
When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content- type.
The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
The server encountered an unexpected condition which prevented it from fulfilling the request.
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the connection.
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.


|
LCDGFX LCD display driver
1.0.3
This library is developed to control SSD1306/SSD1325/SSD1327/SSD1331/SSD1351/IL9163/PCD8554 RGB i2c/spi LED displays
|
#include <display.h>
Public Member Functions | |
| void | putPixel (lcdint_t x, lcdint_t y) __attribute__((noinline)) |
| void | drawVLine (lcdint_t x1, lcdint_t y1, lcdint_t y2) |
| void | drawHLine (lcdint_t x1, lcdint_t y1, lcdint_t x2) |
| void | fillRect (lcdint_t x1, lcdint_t y1, lcdint_t x2, lcdint_t y2) __attribute__((noinline)) |
| void | drawXBitmap (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *bitmap) |
| void | drawBitmap1 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *bitmap) __attribute__((noinline)) |
| Draws monochrome bitmap in color buffer using color, specified via setColor() method Draws monochrome bitmap in color buffer using color, specified via setColor() method. More... | |
| void | drawBitmap4 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *bitmap) __attribute__((noinline)) |
| Draws 4-bit gray-color bitmap in color buffer. Draws 4-bit gray-color bitmap in color buffer. More... | |
| void | drawBitmap8 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *bitmap) |
| Draws 8-bit color bitmap in color buffer. Draws 8-bit color bitmap in color buffer. More... | |
| void | drawBitmap16 (lcdint_t xpos, lcdint_t ypos, lcduint_t w, lcduint_t h, const uint8_t *bitmap) |
| void | drawBuffer1 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *buffer) __attribute__((noinline)) |
| void | drawBuffer1Fast (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *buffer) |
| void | drawBuffer4 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *buffer) __attribute__((noinline)) |
| void | drawBuffer8 (lcdint_t x, lcdint_t y, lcduint_t w, lcduint_t h, const uint8_t *buffer) |
| void | drawBuffer16 (lcdint_t xpos, lcdint_t ypos, lcduint_t w, lcduint_t h, const uint8_t *buffer) __attribute__((noinline)) |
| void | clear () |
| void | fill (uint16_t color) |
| uint8_t | printChar (uint8_t c) |
| size_t | write (uint8_t c) __attribute__((noinline)) |
| void | printFixed (lcdint_t xpos, lcdint_t y, const char *ch, EFontStyle style=STYLE_NORMAL) __attribute__((noinline)) |
| Public Member Functions inherited from NanoDisplayBase< I > | |
| NanoDisplayBase (I &intf) | |
| const NanoPoint | offsetEnd () const |
| const NanoRect | rect () const |
| lcduint_t | width () |
| lcduint_t | height () |
| void | swapDimensions () |
| void | setColor (uint16_t color) |
| void | negativeMode () |
| void | positiveMode () |
| I & | getInterface () |
| void | setFont (NanoFont &font) |
| void | setFontSpacing (uint8_t spacing) |
| NanoFont & | getFont () |
| void | setFixedFont (const uint8_t *progmemFont) |
| void | setFixedFont (const uint8_t *progmemFont, const uint8_t *secondaryFont) |
| void | setFreeFont (const uint8_t *progmemFont, const uint8_t *secondaryFont=nullptr) |
| void | setTextCursor (lcdint_t x, lcdint_t y) |
Static Public Attributes | |
| static const uint8_t | BITS_PER_PIXEL = 1 |
Additional Inherited Members | |
| Protected Attributes inherited from NanoDisplayBase< I > | |
| lcduint_t | m_w = 0 |
| width of NanoCanvas area in pixels | |
| lcduint_t | m_h = 0 |
| height of NanoCanvas area in pixels | |
| lcduint_t | m_p = 0 |
| number of bits, used by width value: 3 equals to 8 pixels width | |
| lcdint_t | m_cursorX = 0 |
| current X cursor position for text output | |
| lcdint_t | m_cursorY = 0 |
| current Y cursor position for text output | |
| uint8_t | m_textMode = 0 |
| Flags for current NanoCanvas mode. | |
| EFontStyle | m_fontStyle |
| currently active font style | |
| uint16_t | m_color = 0xFFFF |
| current color for monochrome operations | |
| NanoFont * | m_font = nullptr |
| currently set font | |
| I & | m_intf |
| communication interface with the display | |
NanoDisplayOps16 is template class for 16-bit operations.
| void NanoDisplayOps16< I >::clear | ( | ) |
Clears canvas
Definition at line 243 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBitmap1 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | bitmap | ||
| ) |
Draws monochrome bitmap in color buffer using color, specified via setColor() method Draws monochrome bitmap in color buffer using color, specified via setColor() method.
| x | - position X in pixels |
| y | - position Y in pixels |
| w | - width in pixels |
| h | - height in pixels |
| bitmap | - monochrome bitmap data, located in flash |
Definition at line 255 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBitmap16 | ( | lcdint_t | xpos, |
| lcdint_t | ypos, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | bitmap | ||
| ) |
Draw 16-bit color bitmap, located in Flash, directly to OLED display GDRAM. Each pixel of the bitmap is expected in 5-6-5 format.
| xpos | start horizontal position in pixels |
| ypos | start vertical position in pixels |
| w | bitmap width in pixels |
| h | bitmap height in pixels |
| bitmap | pointer to Flash data, containing 16-bit color bitmap. |
Definition at line 314 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBitmap4 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | bitmap | ||
| ) |
Draws 4-bit gray-color bitmap in color buffer. Draws 4-bit gray-color bitmap in color buffer.
| x | - position X in pixels |
| y | - position Y in pixels |
| w | - width in pixels |
| h | - height in pixels |
| bitmap | - 4-bit gray-color bitmap data, located in flash |
Definition at line 293 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBitmap8 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | bitmap | ||
| ) |
Draws 8-bit color bitmap in color buffer. Draws 8-bit color bitmap in color buffer.
| x | - position X in pixels |
| y | - position Y in pixels |
| w | - width in pixels |
| h | - height in pixels |
| bitmap | - 8-bit color bitmap data, located in flash |
Definition at line 299 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBuffer1 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | buffer | ||
| ) |
Draws bitmap, located in RAM, on the display Each byte represents 8 vertical pixels.
| x | horizontal position in pixels |
| y | vertical position in pixels |
| w | width of bitmap in pixels |
| h | height of bitmap in pixels (must be divided by 8) |
| buffer | pointer to data, located in SRAM: each byte represents 8 vertical pixels. |
Definition at line 328 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBuffer16 | ( | lcdint_t | xpos, |
| lcdint_t | ypos, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | buffer | ||
| ) |
Draws 16-bit bitmap, located in RAM, on the display Each pixel occupies 2 bytes (5-6-5 format): refer to RGB_COLOR16 to understand RGB scheme, being used.
| xpos | horizontal position in pixels |
| ypos | vertical position in pixels |
| w | width of bitmap in pixels |
| h | height of bitmap in pixels |
| buffer | pointer to data, located in RAM. |
Definition at line 393 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBuffer1Fast | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | buffer | ||
| ) |
Implements the same behavior as drawBuffer1, but much faster. This method has some limitations
| x | horizontal position in pixels |
| y | vertical position in pixels |
| w | width of bitmap in pixels |
| h | height of bitmap in pixels (must be divided by 8) |
| buffer | pointer to data, located in SRAM: each byte represents 8 vertical pixels. |
Definition at line 366 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBuffer4 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | buffer | ||
| ) |
Draws 4-bit bitmap, located in RAM, on the display Each byte represents two pixels in 4-4 format: refer to GRAY_COLOR4 to understand scheme, being used.
| x | horizontal position in pixels |
| y | vertical position in pixels |
| w | width of bitmap in pixels |
| h | height of bitmap in pixels |
| buffer | pointer to data, located in SRAM. |
Definition at line 372 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawBuffer8 | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | buffer | ||
| ) |
Draws 8-bit bitmap, located in RAM, on the display Each byte represents one pixel in 2-2-3 format: refer to RGB_COLOR8 to understand RGB scheme, being used.
| x | horizontal position in pixels |
| y | vertical position in pixels |
| w | width of bitmap in pixels |
| h | height of bitmap in pixels |
| buffer | pointer to data, located in SRAM. |
Definition at line 378 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawHLine | ( | lcdint_t | x1, |
| lcdint_t | y1, | ||
| lcdint_t | x2 | ||
| ) |
Draws horizontal or vertical line
| x1 | - position X |
| y1 | - position Y |
| x2 | - position X |
Definition at line 183 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawVLine | ( | lcdint_t | x1, |
| lcdint_t | y1, | ||
| lcdint_t | y2 | ||
| ) |
Draws horizontal or vertical line
| x1 | - position X |
| y1 | - position Y |
| y2 | - position Y |
Definition at line 196 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::drawXBitmap | ( | lcdint_t | x, |
| lcdint_t | y, | ||
| lcduint_t | w, | ||
| lcduint_t | h, | ||
| const uint8_t * | bitmap | ||
| ) |
Draws bitmap, located in Flash, on the display The bitmap should be in XBMP format
| x | - horizontal position in pixels |
| y | - vertical position in blocks (pixels/8) |
| w | - width of bitmap in pixels |
| h | - height of bitmap in pixels (must be divided by 8) |
| bitmap | - pointer to data, located in Flash: each byte represents 8 vertical pixels. |
Definition at line 249 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::fill | ( | uint16_t | color | ) |
Fill screen content with specified color
| color | color to fill display with |
Definition at line 230 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::fillRect | ( | lcdint_t | x1, |
| lcdint_t | y1, | ||
| lcdint_t | x2, | ||
| lcdint_t | y2 | ||
| ) |
Fills rectangle area
| x1 | - position X |
| y1 | - position Y |
| x2 | - position X |
| y2 | - position Y |
Definition at line 209 of file ssd1306_16bit.inl.
| uint8_t NanoDisplayOps16< I >::printChar | ( | uint8_t | c | ) |
Draws single character to canvas
| c | - character code to print |
Definition at line 407 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::printFixed | ( | lcdint_t | xpos, |
| lcdint_t | y, | ||
| const char * | ch, | ||
| EFontStyle | style = STYLE_NORMAL |
||
| ) |
Print text at specified position to canvas
| xpos | position in pixels |
| y | position in pixels |
| ch | pointer to NULL-terminated string. |
| style | specific font style to use |
Definition at line 461 of file ssd1306_16bit.inl.
| void NanoDisplayOps16< I >::putPixel | ( | lcdint_t | x, |
| lcdint_t | y | ||
| ) |
Draws pixel on specified position
| x | - position X |
| y | - position Y |
Definition at line 174 of file ssd1306_16bit.inl.
| size_t NanoDisplayOps16< I >::write | ( | uint8_t | c | ) |
Writes single character to canvas
| c | - character code to print |
Definition at line 442 of file ssd1306_16bit.inl.
|
static |


DIAG Set 9 - Horizontal contour plots of DJF-JJA differences
| Legates & Willmott 1920-80 | ||
|---|---|---|
| TREFHT * | 2-meter air temperature | plot |
| NCEP Reanalysis 1979-98 | ||
| PREH2O * | Precipitable water | plot |
| PSL * | Sea-level pressure | plot |
| T 850 * | 850 mb temperature | plot |
| TREFHT * | 2-meter air temperature | plot |
| ERA40 Reanalysis 1980-2001 | ||
| PREH2O * | Total precipitable water | plot |
| T 850 * | 850 mb temperature | plot |
| ECMWF Reanalysis 1979-93 | ||
| PREH2O * | Total precipitable water | plot |
| T 850 * | 850 mb temperature | plot |
| JRA25 Reanalysis 1979-04 | ||
| PREH2O * | Total precipitable water | plot |
| T 850 * | 850 mb temperature | plot |
| AIRS IR Sounder 2002-06 | ||
| T 850 * | 850 mb temperature | plot |
| NVAP 1988-1999 | ||
| PREH2O * | Total precipitable water | plot |
| GPCP 1979-2009 | ||
| PRECT * | Precipitation rate | plot |
| CMAP (Xie-Arkin) 1979-98 | ||
| PRECT * | Precipitation rate | plot |
| ERBE Feb1985-Apr1989 | ||
| LWCF * | TOA longwave cloud forcing | plot |
| SWCF * | TOA shortwave cloud forcing | plot |
| CERES-EBAF March 2000-Feb 2010 | ||
| LWCF * | TOA longwave cloud forcing | plot |
| SWCF * | TOA shortwave cloud forcing | plot |
| CERES 2000-2003 | ||
| LWCF * | TOA longwave cloud forcing | plot |
| SWCF * | TOA shortwave cloud forcing | plot |
| ISCCP D2 Jul1983-Sep2001 | ||
| CLDTOT | Total cloud amount | plot |
| CLOUDSAT (Radar+Lidar) Sep2006-Dec2010 | ||
| CLDTOT | Total cloud amount | plot |


Home
About
Products
Blog
Contact
Contact us!
Name:
Email Address:
Message:
Type your message to us here!


Loading
Welcome,
DenverCoder09
Please sign up or log in to continue.
Don't want people to see your password? Upgrade to
Deluxe
for increased security.
Submit


Lest We Forget: Lessons from Three Epidemics
BY SUMIT PANDE
The highly contagious pathogen has already infected over 25 million people across continents, claiming more than 840,000 lives. The Covid-19 pandemic is now being called the worst global crisis since World War II.
The speed of the spread and the concomitant economic meltdown engendered by the novel coronavirus has triggered many a debate. How soon will we have a vaccine for the disease? Do masks mitigate exposure to the virus? When should nations end lockdowns?
The answers to some of these questions are embedded in the trajectory of three major epidemics that have afflicted the human race in the last two centuries.
The Spanish Flu
Spanish Flu left behind empirical evidence on how short-term behavioral changes can save lives in influenza epidemics. A full century later, benefits of wearing masks are contested even in most developing countries.
THE FIRST SIGNS
Six months before the armistice was signed between warring sides to bring down the curtains on World War I in 1918, an ‘unusually fatal’ respiratory disease caught the attention of physicians at a British training camp in Eaples in France.
Nearly half of those showing influenza-like clinical symptoms were succumbing to the infections.
So the Spanish Flu started in France? Some research seem to suggest that.
LESSONS FROM THE SPANISH PANDEMIC
Spanish Flu in India
Lessons from Spanish Flu
Story from US
The Spanish Flu swept through vast swathes of the United States in three waves between 1918 and 1919, claiming more than 650,000 victims.
Major cities and towns in the US sought to implement short-term social behavioural changes to restrict the spread of the disease. Schools and religious places were closed. Some cities restricted mass gathering while others mandated wearing of mask in public places.
A recent study shows San Francisco, St Louis, Milwaukee and Kansas City, which introduced these measures early, reduced transmission rates by up to 30% to 50% and saved millions of lives.
New York City, which is the worst-hit by the current Covid-19 crisis, was quick to adopt preventive measures in 1919. The state rigidly enforced social distancing and staggered business hours.
Lessons from Spanish Flu
In absence of pharma intervention, short-term behavioural changes are key to restrict the spread of a global pandemic. Those who were quick to adapt and adopt could successfully navigate the crisis in 1919. While others had to pay a heavy price for inaction and ineptitude.
THE LOUISIANA PURCHASE
A Distress Sale?
GREAT MIGRATION AND THE AMERICAN DREAM
PROGRESS AND PANDEMIC
With progress came the pandemic.
The burgeoning population turned into a death trap in cities with little or no public health infrastructure. The contagion flourished in high population density neighbourhoods. Up to 50 percent of newcomers died violent deaths from yellow fever, oozing blood from nose and mouth due to multiple internal haemorrhages.
In multiple waves, this contagion would ravage these tropical and sub-tropical plains for the next 100 years, killing about eight percent of the region’s urban population, and as many as 30 percent of recent migrants. In 1853, the year of New Orleans’ worst epidemic, about one-tenth of the city’s population succumbed to the Yellow Fever.
A PERVERSE CAPITALISM
Co-mingled with racism and slavery, the Yellow Fever engendered a perverse form of capitalism in Deep South. This new social order celebrated those who survived the disease and thus acquired long-term immunity from the virus.
Survival from the Yellow fever was a certificate of greater life expectancy. Natural inoculation catapulted a section of white population to the higher echelons of social and economic hierarchy. Banks offered them loans.
Their businesses flourished. “Immunocapital” soon became the most sought-after currency.
PERILS OF IMMUNITY PASSPORTS FOR COVID-19
At this point in the pandemic, there is not enough evidence about the effectiveness of antibody-mediated immunity to guarantee the accuracy of an “immunity passport” or “risk-free certificate.” People who assume that they are immune to a second infection because they have received a positive test result may ignore public health advice. The use of such certificates may therefore increase the risks of continued transmission.
WHO: "Immunity passports" in the context of COVID-19; April 24, 2020
Firstly, there is little empirical evidence to confirm people who get infected are immune to Covid-19. South Korea has reported multiple cases of re-infection.
Studies show up to 20% of the Covid-19 patients have small or weak anti-bodies. There is little research on how long the acquired immunity to the virus may last.
Secondly, most sensitive pathological investigations can give negative false tests. So there is no guarantee that a person who has tested negative has not been exposed to the virus. (RT PCR Tests in China from lower respiratory organs have shown 75% accuracy)
And finally, immunity passport may usher in a system which would reward and promote those who survive the infection. Likewise, a Covid-19 immunity passport may incentivise exposure to the virus putting at risk the poor and the marginalised; and those who have been the worst affected by economic downturn.
From the paper:
NECROPOLIS: YELLOW FEVER, IMMUNITY, AND CAPITALISM IN THE DEEP SOUTH, 1800-1860 , Kathryn Meyer McAllister Olivarius History Wolfson College University of Oxford
Yellow fever proved highly lethal in Gibraltar, Cádiz, and the Caribbean. Arriving on mainland North America as early as 1699, it periodically struck with staggering violence. It killed about 5,000 people in Philadelphia in 1793 (one-tenth of the city’s population; a further 17,000 fled the city), 5,000 more in 1798 in both Boston and New York, and about 1,000 in Baltimore in 1800.
The first yellow fever epidemic on the Gulf Coast occurred in 1796, coinciding with Louisiana’s first successful sugar harvest.
An 1803 census suggests New Orleans inherited by the United States counted a population of 8,050 residents, inclusive of all races and 700 people “not domiciled.”
New Orleans’ population doubled in size in 1809 with the influx of asylum-seekers from St. Domingue to 18,000, and continued to grow, swelling from 46,000 in 1830 to 102,000 in 1840 through European, American, and forced black migration.
In 1860, the city’s population surpassed 168,000, mostly through the addition of tens of thousands of Irish people escaping famine and Germans fleeing the upheaval of 1848.
Mobile, Alabama, a port city about 140 miles to the west of New Orleans, suffered an especially fatal yellow fever season in 1819. As many as 274 people died out of 1,300 inhabitants, amounting to 21 percent of the population.
Historian K. David Patterson estimated that between 1817 and 1905, yellow fever killed 40,171 people in New Orleans – ten times more than the next most-afflicted city, Charleston.
My own estimate (author of the paper) is that yellow fever killed at least 150,000 Orleanians between 1803 and the Civil War, and probably many more.
In 1833, Maria Inskeep stood at her window in New Orleans and counted 10 funeral processions in one hour.
The Charity Hospital, the primary repository for New Orleans’ poor and indigent, admitted at least 122,317 patients during the 1830s and 40s, the majority during the fever months.
As world eagerly awaits a pharmaceutical intervention to contain Covid-19, a vaccine for AIDS remains a work in progress.
Between October, 1980 and May, 1981 Los Angeles School of Medicine reported deaths of five healthy males from a fungal pneumonia. In a paper published in the first week of June, the authors noted that patients were “all homosexuals suggest an association between some aspect of a homosexual lifestyle or disease acquired through sexual contact.”
The same day, another doctor reported a clusters of aggressive cancer cases among “gay men in New York and California”.
In the next six months, United States had 337 cases of an unknown immune deficiency disease. Of these, 131 had died by the end of the year.
The pathogen causing this disease was identified 21 months later as Human Immunodeficiency Virus or HIV.
Unbeknownst to all, the etiologic agent to Acquired Human Immunodeficiency Syndrome had silently spread its tentacles in the US to epidemic proportion. The virus proved to be a silent killer which debilitated immunity firewalls in humans and severely mitigated the ability to fight infections and diseases.
FEARS AND STIGMA
The October 9, 1984 National edition of The New York Times Section C, Page 1 with the headline: AIDS STUDIES HINT SALIVA MAY TRANSMIT INFECTION.
AIDS Hysteria
FROM THE CHICAGO TRIBUNE ( APRIL 2, 1986)
According to a poll published in December by the Los Angeles Times, of the adults surveyed
In 1987, Princess Diana shook hands without wearing gloves with an AIDS patient at London Middlesex Hospital challenging the belief that the disease could be transmitted through contact. (Photo: John Redman/AP)
IN SEARCH OF A VACCINE
UNAIDS Press Statement
GENEVA, 4 February 2020
The United States National Institutes of Health has announced that its HVTN 702 clinical trial of an HIV vaccine has been stopped. While no safety concerns were found during the trial, the independent data and safety monitoring board found that the vaccine was ineffective in preventing HIV transmission.
The trial, conducted at 14 sites across South Africa, followed more than 5400 HIV-negative 18–35-year-olds over 18 months. The participants received six injections during the six-month period, either the vaccine or a placebo. An analysis undertaken after at least 60% of the participants had been in the study for more than 18 months showed that there were 129 HIV infections among the people who had the vaccine, while 123 people who had the placebo became infected.
The 100 million-dollar HVTN 702 was billed as one of the most promising projects to prevent contraction of the disease in a healthy individual.
The trials were part of three potential vaccine development program for AIDS being coordinated by HIV Vaccine Trial Network.
That’s where the world stands 26 years after U.S. Health and Human Services Secretary Margaret Heckler’s 1984 promised “a vaccine ready for testing in about two years.”
WHY HAS AN AIDS VACCINE ELUDED RESEARCHERS?
No one completely recovers from HIV. Which is why, unlike other diseases, it is difficult to find effective immunity response to the disease.
The virus mutates. It has many sub-types. To discover a one-size-fits-all vaccine to fight the infection is an arduous task.
Though there is no known preventive vaccine to check the spread of HIV, a combination of anti-viral drugs are prescribed to reduce viral load in blood and body fluids of the infected patients.
DESIGN : TRIPARNA DEVELOPMENT: SAKET


todo:
none
Deadline
Start Time
Appointment
Date Label
none
red
orange
blue
Color
Check All
Delete checked
add task


After digging in further: Zig is not doing quite what Rust is. It is an updated C, which eliminates some of the worst foot-guns, but fundamentally does not try to eliminate memory-unsafety… which profoundly disappoints me, even if I still wish Zig success.


/* ****************************************************************************** * Copyright (C) 1996-2014, International Business Machines Corporation and * others. All Rights Reserved. ****************************************************************************** */ /** * \file * \brief C++ API: The RuleBasedCollator class implements the Collator abstract base class. */ /** * File tblcoll.h * * Created by: Helena Shih * * Modification History: * * Date Name Description * 2/5/97 aliu Added streamIn and streamOut methods. Added * constructor which reads RuleBasedCollator object from * a binary file. Added writeToFile method which streams * RuleBasedCollator out to a binary file. The streamIn * and streamOut methods use istream and ostream objects * in binary mode. * 2/12/97 aliu Modified to use TableCollationData sub-object to * hold invariant data. * 2/13/97 aliu Moved several methods into this class from Collation. * Added a private RuleBasedCollator(Locale&) constructor, * to be used by Collator::createDefault(). General * clean up. * 2/20/97 helena Added clone, operator==, operator!=, operator=, and copy * constructor and getDynamicClassID. * 3/5/97 aliu Modified constructFromFile() to add parameter * specifying whether or not binary loading is to be * attempted. This is required for dynamic rule loading. * 05/07/97 helena Added memory allocation error detection. * 6/17/97 helena Added IDENTICAL strength for compare, changed getRules to * use MergeCollation::getPattern. * 6/20/97 helena Java class name change. * 8/18/97 helena Added internal API documentation. * 09/03/97 helena Added createCollationKeyValues(). * 02/10/98 damiba Added compare with "length" parameter * 08/05/98 erm Synched with 1.2 version of RuleBasedCollator.java * 04/23/99 stephen Removed EDecompositionMode, merged with * Normalizer::EMode * 06/14/99 stephen Removed kResourceBundleSuffix * 11/02/99 helena Collator performance enhancements. Eliminates the * UnicodeString construction and special case for NO_OP. * 11/23/99 srl More performance enhancements. Updates to NormalizerIterator * internal state management. * 12/15/99 aliu Update to support Thai collation. Move NormalizerIterator * to implementation file. * 01/29/01 synwee Modified into a C++ wrapper which calls C API * (ucol.h) * 2012-2014 markus Rewritten in C++ again. */ #ifndef TBLCOLL_H #define TBLCOLL_H #include "unicode/utypes.h" #if !UCONFIG_NO_COLLATION #include "unicode/coll.h" #include "unicode/locid.h" #include "unicode/uiter.h" #include "unicode/ucol.h" U_NAMESPACE_BEGIN struct CollationCacheEntry; struct CollationData; struct CollationSettings; struct CollationTailoring; /** * @stable ICU 2.0 */ class StringSearch; /** * @stable ICU 2.0 */ class CollationElementIterator; class CollationKey; class SortKeyByteSink; class UnicodeSet; class UnicodeString; class UVector64; /** * The RuleBasedCollator class provides the implementation of * Collator, using data-driven tables. The user can create a customized * table-based collation. *
* For more information about the collation service see * the User Guide. *
* Collation service provides correct sorting orders for most locales supported in ICU. * If specific data for a locale is not available, the orders eventually falls back * to the CLDR root sort order. *
* Sort ordering may be customized by providing your own set of rules. For more on * this subject see the * Collation Customization section of the User Guide. *
* Note, RuleBasedCollator is not to be subclassed. * @see Collator */ class U_I18N_API RuleBasedCollator : public Collator { public: /** * RuleBasedCollator constructor. This takes the table rules and builds a * collation table out of them. Please see RuleBasedCollator class * description for more details on the collation rule syntax. * @param rules the collation rules to build the collation table from. * @param status reporting a success or an error. * @stable ICU 2.0 */ RuleBasedCollator(const UnicodeString& rules, UErrorCode& status); /** * RuleBasedCollator constructor. This takes the table rules and builds a * collation table out of them. Please see RuleBasedCollator class * description for more details on the collation rule syntax. * @param rules the collation rules to build the collation table from. * @param collationStrength strength for comparison * @param status reporting a success or an error. * @stable ICU 2.0 */ RuleBasedCollator(const UnicodeString& rules, ECollationStrength collationStrength, UErrorCode& status); /** * RuleBasedCollator constructor. This takes the table rules and builds a * collation table out of them. Please see RuleBasedCollator class * description for more details on the collation rule syntax. * @param rules the collation rules to build the collation table from. * @param decompositionMode the normalisation mode * @param status reporting a success or an error. * @stable ICU 2.0 */ RuleBasedCollator(const UnicodeString& rules, UColAttributeValue decompositionMode, UErrorCode& status); /** * RuleBasedCollator constructor. This takes the table rules and builds a * collation table out of them. Please see RuleBasedCollator class * description for more details on the collation rule syntax. * @param rules the collation rules to build the collation table from. * @param collationStrength strength for comparison * @param decompositionMode the normalisation mode * @param status reporting a success or an error. * @stable ICU 2.0 */ RuleBasedCollator(const UnicodeString& rules, ECollationStrength collationStrength, UColAttributeValue decompositionMode, UErrorCode& status); #ifndef U_HIDE_INTERNAL_API /** * TODO: document & propose as public API * @internal */ RuleBasedCollator(const UnicodeString &rules, UParseError &parseError, UnicodeString &reason, UErrorCode &errorCode); #endif /* U_HIDE_INTERNAL_API */ /** * Copy constructor. * @param other the RuleBasedCollator object to be copied * @stable ICU 2.0 */ RuleBasedCollator(const RuleBasedCollator& other); /** Opens a collator from a collator binary image created using * cloneBinary. Binary image used in instantiation of the * collator remains owned by the user and should stay around for * the lifetime of the collator. The API also takes a base collator * which must be the root collator. * @param bin binary image owned by the user and required through the * lifetime of the collator * @param length size of the image. If negative, the API will try to * figure out the length of the image * @param base Base collator, for lookup of untailored characters. * Must be the root collator, must not be NULL. * The base is required to be present through the lifetime of the collator. * @param status for catching errors * @return newly created collator * @see cloneBinary * @stable ICU 3.4 */ RuleBasedCollator(const uint8_t *bin, int32_t length, const RuleBasedCollator *base, UErrorCode &status); /** * Destructor. * @stable ICU 2.0 */ virtual ~RuleBasedCollator(); /** * Assignment operator. * @param other other RuleBasedCollator object to copy from. * @stable ICU 2.0 */ RuleBasedCollator& operator=(const RuleBasedCollator& other); /** * Returns true if argument is the same as this object. * @param other Collator object to be compared. * @return true if arguments is the same as this object. * @stable ICU 2.0 */ virtual UBool operator==(const Collator& other) const; /** * Makes a copy of this object. * @return a copy of this object, owned by the caller * @stable ICU 2.0 */ virtual Collator* clone(void) const; /** * Creates a collation element iterator for the source string. The caller of * this method is responsible for the memory management of the return * pointer. * @param source the string over which the CollationElementIterator will * iterate. * @return the collation element iterator of the source string using this as * the based Collator. * @stable ICU 2.2 */ virtual CollationElementIterator* createCollationElementIterator( const UnicodeString& source) const; /** * Creates a collation element iterator for the source. The caller of this * method is responsible for the memory management of the returned pointer. * @param source the CharacterIterator which produces the characters over * which the CollationElementItgerator will iterate. * @return the collation element iterator of the source using this as the * based Collator. * @stable ICU 2.2 */ virtual CollationElementIterator* createCollationElementIterator( const CharacterIterator& source) const; // Make deprecated versions of Collator::compare() visible. using Collator::compare; /** * The comparison function compares the character data stored in two * different strings. Returns information about whether a string is less * than, greater than or equal to another string. * @param source the source string to be compared with. * @param target the string that is to be compared with the source string. * @param status possible error code * @return Returns an enum value. UCOL_GREATER if source is greater * than target; UCOL_EQUAL if source is equal to target; UCOL_LESS if source is less * than target * @stable ICU 2.6 **/ virtual UCollationResult compare(const UnicodeString& source, const UnicodeString& target, UErrorCode &status) const; /** * Does the same thing as compare but limits the comparison to a specified * length * @param source the source string to be compared with. * @param target the string that is to be compared with the source string. * @param length the length the comparison is limited to * @param status possible error code * @return Returns an enum value. UCOL_GREATER if source (up to the specified * length) is greater than target; UCOL_EQUAL if source (up to specified * length) is equal to target; UCOL_LESS if source (up to the specified * length) is less than target. * @stable ICU 2.6 */ virtual UCollationResult compare(const UnicodeString& source, const UnicodeString& target, int32_t length, UErrorCode &status) const; /** * The comparison function compares the character data stored in two * different string arrays. Returns information about whether a string array * is less than, greater than or equal to another string array. * @param source the source string array to be compared with. * @param sourceLength the length of the source string array. If this value * is equal to -1, the string array is null-terminated. * @param target the string that is to be compared with the source string. * @param targetLength the length of the target string array. If this value * is equal to -1, the string array is null-terminated. * @param status possible error code * @return Returns an enum value. UCOL_GREATER if source is greater * than target; UCOL_EQUAL if source is equal to target; UCOL_LESS if source is less * than target * @stable ICU 2.6 */ virtual UCollationResult compare(const UChar* source, int32_t sourceLength, const UChar* target, int32_t targetLength, UErrorCode &status) const; /** * Compares two strings using the Collator. * Returns whether the first one compares less than/equal to/greater than * the second one. * This version takes UCharIterator input. * @param sIter the first ("source") string iterator * @param tIter the second ("target") string iterator * @param status ICU status * @return UCOL_LESS, UCOL_EQUAL or UCOL_GREATER * @stable ICU 4.2 */ virtual UCollationResult compare(UCharIterator &sIter, UCharIterator &tIter, UErrorCode &status) const; /** * Compares two UTF-8 strings using the Collator. * Returns whether the first one compares less than/equal to/greater than * the second one. * This version takes UTF-8 input. * Note that a StringPiece can be implicitly constructed * from a std::string or a NUL-terminated const char * string. * @param source the first UTF-8 string * @param target the second UTF-8 string * @param status ICU status * @return UCOL_LESS, UCOL_EQUAL or UCOL_GREATER * @stable ICU 51 */ virtual UCollationResult compareUTF8(const StringPiece &source, const StringPiece &target, UErrorCode &status) const; /** * Transforms the string into a series of characters * that can be compared with CollationKey.compare(). * * Note that sort keys are often less efficient than simply doing comparison. * For more details, see the ICU User Guide. * * @param source the source string. * @param key the transformed key of the source string. * @param status the error code status. * @return the transformed key. * @see CollationKey * @stable ICU 2.0 */ virtual CollationKey& getCollationKey(const UnicodeString& source, CollationKey& key, UErrorCode& status) const; /** * Transforms a specified region of the string into a series of characters * that can be compared with CollationKey.compare. * * Note that sort keys are often less efficient than simply doing comparison. * For more details, see the ICU User Guide. * * @param source the source string. * @param sourceLength the length of the source string. * @param key the transformed key of the source string. * @param status the error code status. * @return the transformed key. * @see CollationKey * @stable ICU 2.0 */ virtual CollationKey& getCollationKey(const UChar *source, int32_t sourceLength, CollationKey& key, UErrorCode& status) const; /** * Generates the hash code for the rule-based collation object. * @return the hash code. * @stable ICU 2.0 */ virtual int32_t hashCode() const; /** * Gets the locale of the Collator * @param type can be either requested, valid or actual locale. For more * information see the definition of ULocDataLocaleType in * uloc.h * @param status the error code status. * @return locale where the collation data lives. If the collator * was instantiated from rules, locale is empty. * @deprecated ICU 2.8 likely to change in ICU 3.0, based on feedback */ virtual Locale getLocale(ULocDataLocaleType type, UErrorCode& status) const; /** * Gets the tailoring rules for this collator. * @return the collation tailoring from which this collator was created * @stable ICU 2.0 */ const UnicodeString& getRules() const; /** * Gets the version information for a Collator. * @param info the version # information, the result will be filled in * @stable ICU 2.0 */ virtual void getVersion(UVersionInfo info) const; #ifndef U_HIDE_DEPRECATED_API /** * Returns the maximum length of any expansion sequences that end with the * specified comparison order. * * This is specific to the kind of collation element values and sequences * returned by the CollationElementIterator. * Call CollationElementIterator::getMaxExpansion() instead. * * @param order a collation order returned by CollationElementIterator::previous * or CollationElementIterator::next. * @return maximum size of the expansion sequences ending with the collation * element, or 1 if the collation element does not occur at the end of * any expansion sequence * @see CollationElementIterator#getMaxExpansion * @deprecated ICU 51 Use CollationElementIterator::getMaxExpansion() instead. */ int32_t getMaxExpansion(int32_t order) const; #endif /* U_HIDE_DEPRECATED_API */ /** * Returns a unique class ID POLYMORPHICALLY. Pure virtual override. This * method is to implement a simple version of RTTI, since not all C++ * compilers support genuine RTTI. Polymorphic operator==() and clone() * methods call this method. * @return The class ID for this object. All objects of a given class have * the same class ID. Objects of other classes have different class * IDs. * @stable ICU 2.0 */ virtual UClassID getDynamicClassID(void) const; /** * Returns the class ID for this class. This is useful only for comparing to * a return value from getDynamicClassID(). For example: *
* Base* polymorphic_pointer = createPolymorphicObject(); * if (polymorphic_pointer->getDynamicClassID() == * Derived::getStaticClassID()) ... ** @return The class ID for all objects of this class. * @stable ICU 2.0 */ static UClassID U_EXPORT2 getStaticClassID(void); #ifndef U_HIDE_DEPRECATED_API /** * Do not use this method: The caller and the ICU library might use different heaps. * Use cloneBinary() instead which writes to caller-provided memory. * * Returns a binary format of this collator. * @param length Returns the length of the data, in bytes * @param status the error code status. * @return memory, owned by the caller, of size 'length' bytes. * @deprecated ICU 52. Use cloneBinary() instead. */ uint8_t *cloneRuleData(int32_t &length, UErrorCode &status) const; #endif /* U_HIDE_DEPRECATED_API */ /** Creates a binary image of a collator. This binary image can be stored and * later used to instantiate a collator using ucol_openBinary. * This API supports preflighting. * @param buffer a fill-in buffer to receive the binary image * @param capacity capacity of the destination buffer * @param status for catching errors * @return size of the image * @see ucol_openBinary * @stable ICU 3.4 */ int32_t cloneBinary(uint8_t *buffer, int32_t capacity, UErrorCode &status) const; /** * Returns current rules. Delta defines whether full rules are returned or * just the tailoring. * * getRules(void) should normally be used instead. * See http://userguide.icu-project.org/collation/customization#TOC-Building-on-Existing-Locales * @param delta one of UCOL_TAILORING_ONLY, UCOL_FULL_RULES. * @param buffer UnicodeString to store the result rules * @stable ICU 2.2 * @see UCOL_FULL_RULES */ void getRules(UColRuleOption delta, UnicodeString &buffer) const; /** * Universal attribute setter * @param attr attribute type * @param value attribute value * @param status to indicate whether the operation went on smoothly or there were errors * @stable ICU 2.2 */ virtual void setAttribute(UColAttribute attr, UColAttributeValue value, UErrorCode &status); /** * Universal attribute getter. * @param attr attribute type * @param status to indicate whether the operation went on smoothly or there were errors * @return attribute value * @stable ICU 2.2 */ virtual UColAttributeValue getAttribute(UColAttribute attr, UErrorCode &status) const; /** * Sets the variable top to the top of the specified reordering group. * The variable top determines the highest-sorting character * which is affected by UCOL_ALTERNATE_HANDLING. * If that attribute is set to UCOL_NON_IGNORABLE, then the variable top has no effect. * @param group one of UCOL_REORDER_CODE_SPACE, UCOL_REORDER_CODE_PUNCTUATION, * UCOL_REORDER_CODE_SYMBOL, UCOL_REORDER_CODE_CURRENCY; * or UCOL_REORDER_CODE_DEFAULT to restore the default max variable group * @param errorCode Standard ICU error code. Its input value must * pass the U_SUCCESS() test, or else the function returns * immediately. Check for U_FAILURE() on output or use with * function chaining. (See User Guide for details.) * @return *this * @see getMaxVariable * @draft ICU 53 */ virtual Collator &setMaxVariable(UColReorderCode group, UErrorCode &errorCode); /** * Returns the maximum reordering group whose characters are affected by UCOL_ALTERNATE_HANDLING. * @return the maximum variable reordering group. * @see setMaxVariable * @draft ICU 53 */ virtual UColReorderCode getMaxVariable() const; /** * Sets the variable top to the primary weight of the specified string. * * Beginning with ICU 53, the variable top is pinned to * the top of one of the supported reordering groups, * and it must not be beyond the last of those groups. * See setMaxVariable(). * @param varTop one or more (if contraction) UChars to which the variable top should be set * @param len length of variable top string. If -1 it is considered to be zero terminated. * @param status error code. If error code is set, the return value is undefined. Errors set by this function are:


Pageviews
Week Metrics
Top Accessed Content
| Page | Type | Student Visits | Pageviews |
|---|
Communication Access
| Title | Type | Unique Students | Pageviews | Posts |
|---|
Top Course Visitors
| Firstname | Surname | Role | Pageviews |
|---|
Assessment Access
| Title | Type | Unique Students | Attempts | Average Student Score |
|---|


| Class | Description |
|---|---|
| ElementBinaryFunction<V,R> | |
| ElementBinaryOperation<V> |
A binary operations on tensors which can be decoupled into simple operations on an element of one tensor on the
corresponding element on the second tensor (same position).
|
| ElementUnaryOperation<V> |
Operates on one tensor and produces a new tensor of the same shape by applying a unary operation on each value of the
tensor.
|
| FunctionTensorCreationOperation<V> |
Uses the given function from a position to the tensor to create the values of the tensor.
|
| InnerTensorOperation<V> |
Represents a binary operation on tensorics, respecting the equivalent of Einstein Summation Convention in tensorics
representation.
|
| OngoingMapOut<V> |
Provides methods to describe how to produce a map out of a tensor.
|
| PositionFunctions | |
| SingleValueTensorCreationOperation<V> |
Uses one value and a given shape to create a tensor, which has the same values at all positions.
|
| TensorInternals |
Utility methods for tensors which are not exposed to the public API
|
| TensorReduction<C,E,R> |
The operation which describes the reduction of a tensor in one direction.
|


Simcon: Simultanious Connections to Website or Single page
Close additional instances and check with Refresh connections if it counts down again


drought flash droughts China risk moisture soil simulations Fig. increase events population changes climate data {border-style future CMIP percentile px;} #ffffff;} warming (Supplementary precipitation exposure models used based mean new surface temperature Change global model results southern (e.g., USA change different ensemble forcings historical (Fig. Clim. Res. conditions definition frequency human land projection using LSM Supplementary United anthropogenic end heat onset rapid severity China, China. Sci. States century concurrent driven duration extreme growing increasing intensification px; seasonal time uncertainty {font-family Climate Flash Nat. Nature RCP. Science Yuan attribution days font-size method middle period provided trend Geophys. LSMs Table available decline double; especially estimated event greenhouse higher impact influence scenarios seasons upward variability (–) ./nclimate ./s--- Am. Attribution Bull. Lett. Meteor. Moreover, National Soc. University Wang Wood [], average bars bias border-color border-width carried conventional decrease details). drive durations high important information northern observations observed occur regions scenario socioeconomic solid; study trends {font-style {font-weight ± % (i.e., (see ./BAMS-D--. ./JD Acad. Anthropogenic CMIP/ALL/LSM CRUNCEPv Commons Creative Daily Foundation Future GHG LSMs, Lettenmaier Meteorological Model Natl Proc. Research air analysis annual anomaly b). baseline bold calculated community corrected corresponding courier; cycle daily deficit definition, distribution droughts, dry early em; event. explicitly extremes factor factors frequency, included increased initial larger meteorological monthly natural number pentad percentile, previous provide pt;} rate recovery remains risk. role scaling short-term signal significant similar simulated simulations. statistics suggests threshold years


This little demo just a quick overview what is the lib capable of. For more details, please visit the documentation.


{extends file=$conf->root_path|cat:"/templates/user.html"} {block name=content}
${$pizza->price*0.7}
${$pizza->price}
${$pizza->price*1.4}
${$drink->price*0.7}
${$drink->price}
${$drink->price*1.3}
${$fastFood->price*0.7}
${$fastFood->price}
${$fastFood->price*1.3}


Banka
Please provide the correct information and
click the "Create Account" button.
NB: Required fields begin with
State
Lagos
Branch
15 Adeniyi Jones
Id Type
International Passport
Id number
Expiry date


§302A-1110 Educational districts not applicable. The educational districts established by section 4-1 shall not be applicable to, nor alter, the school districts established for administrative purposes by the department. [L 1996, c 89, pt of §2; am L 2011, c 5, §16]


 See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright © Michael Gundlach<EMAIL_ADDRESS>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2011 Jerry Sievert
https://github.com/borgar/dateutil
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2011 Eli Grey
https://github.com/eligrey/FileSaver.js/
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2013 Jorik Tangelder (Eight Media)
https://github.com/EightMedia/hammer.js
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2007 – 2009 The jabsorb team
Copyright © 2005 Michael Clark, Metaparadigm Pte Ltd
Copyright © 2003 – 2004 Jan-Klaas Kollhof
https://code.google.com/archive/p/jabsorb/
This code is based on original code from the json-rpc-java library which was originally based on Jan-Klaas' JavaScript o lait library (jsolait).
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright © 2005 – 2014 jQuery Foundation, Inc
http://jquery.com/
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2013 Tim Down
http://log4javascript.org/
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.
Copyright © 2013 The Polymer Authors
https://github.com/jquery/PEP
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

Copyright © 2010 – 2011 The Dojo Foundation
http://requirejs.org/
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2009 – 2010 Emily Stark, Mike Hamburg, Dan Boneh
https://github.com/bitwiseshiftleft/sjcl
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

Copyright © 2010 Mario Klingemann
http://www.quasimondo.com/StackBlurForCanvas/StackBlurDemo.html
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2009 – 2014 Jeremy Ashkenas, DocumentCloud and Investigative Reporters & Editors
http://underscorejs.org/
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright © 2014–2016 GitHub, Inc.
https://github.github.io/fetch/
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.


dtplite(1) dtplite(1) ________________________________________________________________________________ NAME dtplite - Lightweight DocTools Markup Processor SYNOPSIS dtplite -o output ?options? format inputfile dtplite validate inputfile dtplite -o output ?options? format inputdirectory dtplite -merge -o output ?options? format inputdirectory _________________________________________________________________ DESCRIPTION The application described by this document, dtplite, is the successor to the extremely simple mpexpand. Influenced in its functionality by the dtp doctools processor it is much more powerful than mpexpand, yet still as easy to use; definitely easier than dtp with its myriad of subcommands and options. dtplite is based upon the package doctools, like the other two proces‐ sors. USE CASES dtplite was written with the following three use cases in mind. [1] Validation of a single document, i.e. checking that it was written in valid doctools format. This mode can also be used to get a pre‐ liminary version of the formatted output for a single document, for display in a browser, nroff, etc., allowing proofreading of the formatting. [2] Generation of the formatted documentation for a single package, i.e. all the manpages, plus a table of contents and an index of keywords. [3] An extension of the previous mode of operation, a method for the easy generation of one documentation tree for several packages, and especially of a unified table of contents and keyword index. Beyond the above we also want to make use of the customization features provided by the HTML formatter. It is not the only format the application should be able to generate, but we anticipiate it to be the most commonly used, and it is one of the few which do provide customization hooks. We allow the caller to specify a header string, footer string, a stylesheet, and data for a bar of navigation links at the top of the gen‐ erated document. While all can be set as long as the formatting engine provides an appropriate engine parameter (See section OPTIONS) the last two have internal processing which make them specific to HTML. COMMAND LINE dtplite -o output ?options? format inputfile This is the form for use case [1]. The options will be explained later, in section OPTIONS. path output (in) This argument specifies where to write the generated docu‐ ment. It can be the path to a file or directory, or -. The last value causes the application to write the generated documented to stdout. If the output does not exist then [file dirname $output] has to exist and must be a writable directory. The gener‐ ated document will be written to a file in that directory, and the name of that file will be derived from the input‐ file, the format, and the value given to option -ext (if present). (path|handle) format (in) This argument specifies the formatting engine to use when processing the input, and thus the format of the generated document. See section FORMATS for the possibilities recog‐ nized by the application. path inputfile (in) This argument specifies the path to the file to process. It has to exist, must be readable, and written in doctools format. dtplite validate inputfile This is a simpler form for use case [1]. The "validate" format generates no output at all, only syntax checks are performed. As such the specification of an output file or other options is not necessary and left out. dtplite -o output ?options? format inputdirectory This is the form for use case [2]. It differs from the form for use case [1] by having the input documents specified through a directory instead of a file. The other arguments are identical, except for output, which now has to be the path to an existing and writable directory. The input documents are all files in inputdirectory or any of its subdirectories which were recognized by fileutil::fileType as con‐ taining text in doctools format. dtplite -merge -o output ?options? format inputdirectory This is the form for use case [3]. The only difference to the form for use case [2] is the additional option -merge. Each such call will merge the generated documents coming from pro‐ cessing the input documents under inputdirectory or any of its subdirectories to the files under output. In this manner it is possible to incrementally build the unified documentation for any number of packages. Note that it is necessary to run through all the packages twice to get fully correct cross-references (for for‐ mats supporting them). OPTIONS This section describes all the options available to the user of the application, with the exception of the options -o and -merge. These two were described already, in section COMMAND LINE. -exclude string This option specifies an exclude (glob) pattern. Any files identi‐ fied as manpages to process which match the exclude pattern are ignored. The option can be provided multiple times, each usage adding an additional pattern to the list of exclusions. -ext string If the name of an output file has to be derived from the name of an input file it will use the name of the format as the extension by default. This option here will override this however, forcing it to use string as the file extension. This option is ignored if the name of the output file is fully specified through option -o. When used multiple times only the last definition is relevant. -header file This option can be used if and only if the selected format pro‐ vides an engine parameter named "header". It takes the contents of the specified file and assign them to that parameter, for whatever use by the engine. The HTML engine will insert the text just after the tag <body>. If navigation buttons are present (see option -nav below), then the HTML generated for them is appended to the header data originating here before the final assignment to the parameter. When used multiple times only the last definition is relevant. -footer file Like -header, except that: Any navigation buttons are ignored, the corresponding required engine parameter is named "footer", and the data is inserted just before the tag </body>. When used multiple times only the last definition is relevant. -style file This option can be used if and only if the selected format pro‐ vides an engine parameter named "meta". When specified it will generate a piece of HTML code declaring the file as the stylesheet for the generated document and assign that to the parameter. The HTML engine will insert this inot the document, just after the tag <head>. When processing an input directory the stylesheet file is copied into the output directory and the generated HTML will refer to the copy, to make the result more self-contained. When processing an input file we have no location to copy the stylesheet to and so just reference it as specified. When used multiple times only the last definition is relevant. -nav label url Use this option to specify a navigation button with label to dis‐ play and the url to link to. This option can be used if and only if the selected format provides an engine parameter named "header". The HTML generated for this is appended to whatever data we got from option -header before it is inserted into the gener‐ ated documents. When used multiple times all definitions are collected and a navi‐ gation bar is created, with the first definition shown at the left edge and the last definition to the right. FORMATS At first the format argument will be treated as a path to a tcl file con‐ taining the code for the requested formatting engine. The argument will be treated as the name of one of the predefined formats listed below if and only if the path does not exist. Note a limitation: If treating the format as path to the tcl script implementing the engine was sucessful, then this script has to implement not only the engine API for doctools, i.e. doctools_api, but for doc‐ toc_api and docidx_api as well. Otherwise the generation of a table of contents and of a keyword index will fail. List of predefined formats, i.e. as provided by the package doctools: nroff The processor generates *roff output, the standard format for unix manpages. html The processor generates HTML output, for usage in and display by web browsers. This engine is currently the only one providing the various engine parameters required for the additional customaiza‐ tion of the output. tmml The processor generates TMML output, the Tcl Manpage Markup Lan‐ guage, a derivative of XML. latex The processor generates LaTeX output. wiki The processor generates Wiki markup as understood by wikit. list The processor extracts the information provided by manpage_begin. This format is used internally to extract the meta data from which both table of contents and keyword index are derived from. null The processor does not generate any output. This is equivalent to validate. DIRECTORY STRUCTURES In this section we describe the directory structures generated by the application under output when processing all documents in an inputdirec‐ tory. In other words, this is only relevant to the use cases [2] and [3]. [2] The following directory structure is created when processing a single set of input documents. The file extension used is for output in HTML, but that is not relevant to the structure and was just used to have proper file names. output/ toc.html index.html files/ path/to/FOO.html The last line in the example shows the document generated for a file FOO located at inputdirectory/path/to/FOO [3] When merging many packages into a unified set of documents the generated directory structure is a bit deeper: output .toc .idx .tocdoc .idxdoc .xrf toc.html index.html FOO1/ ... FOO2/ toc.html files/ path/to/BAR.html Each of the directories FOO1, ... contains the documents generated for the package FOO1, ... and follows the structure shown for use case [2]. The only exception is that there is no per-package index. The files ".toc", ".idx", and ".xrf" contain the internal status of the whole output and will be read and updated by the next invokation. Their contents will not be documented. Remove these files when all packages wanted for the output have been processed, i.e. when the output is complete. The files ".tocdoc", and ".idxdoc", are intermediate files in doc‐ toc and docidx markup, respectively, containing the main table of contents and keyword index for the set of documents before their conversion to the chosen output format. They are left in place, i.e. not deleted, to serve as demonstrations of doctoc and docidx markup. BUGS, IDEAS, FEEDBACK This document, and the application it describes, will undoubtedly contain bugs and other problems. Please report such in the category doctools of the Tcllib SF Trackers [http://sourceforge.net/tracker/?group_id=12883]. Please also report any ideas for enhancements you may have for either application and/or documentation. SEE ALSO docidx introduction, doctoc introduction, doctools introduction KEYWORDS HTML, TMML, conversion, docidx, doctoc, doctools, manpage, markup, nroff CATEGORY Documentation tools COPYRIGHT Copyright (c) 2004 Andreas Kupries<EMAIL_ADDRESS>Documentation toolbox 1.0 dtplite(1)


What will your verse be?
Everyone has something to share. See how people are using iPad in their unique way to add to the world's story.
Watch the "Your Verse" film and explore the stories
What will your verse be?
Everyone has something to share. See how people are using iPad in their unique way to add to the world's story.
Watch the "Your Verse" film and explore the stories