Note: since working drafts are subject to frequent change, you are advised to reference the above URL, rather than the URLs for working drafts themselves.
The Joint Electronics Payment Initiative aims to bring key industry players together to assure that multiple payment protocols can operate effectively in Web applications. The concrete goal is automatable payment selection over HTTP.
The first step towards this was Don Eastlake's development of the Universal Payment Preamble, which is also available as an internet-draft (draft-eastlake-universal-payment). The second is the development of an HTTP Extension Protocol to embed UPP in HTTP. The latter proposal is part of the chartered activities of the IETF HTTP WG (draft-ietf-http-pep-03).
This document describes how to use UPP over PEP to support payment selection between clients and merchants. It explains basic operations: requesting available payment choices, presenting multiple choices, demanding a selection, making a selection, and accepting and rejecting choices.
Amongst other things, UPP provides a uniform vocabulary for naming options common to many payment systems, and a uniform syntax for each such option. It is not clear at the current time what mechanism should be used to allow independent payment system designers to name options so that they will not collide with the UPP namespace of shared options. We will use sub-bags to separate the name spaces. That is, we will assume that a bag of the form {upp {upp-parameter-name upp-parameter-value} ... } will be used to hold these parameters. A complete list of these common parameters and their syntax is available in the UPP specification.
In a complete implementation of UPP using PEP, it would be possible to specify these common parameters in the PEP-specified header fields Protocol:, Protocol-Request:, Protocol-Query:, and Protocol-Info: as well as in any payment-system specific headers. In the JEPI demonstration, however, we will not be using these parameters for the generic UPP protocol (they may be used in payment-specific protocols). In this document we will indicate where they are syntactically permitted by using the notation "upp-params." For the demonstration, these will always be omitted in the examples shown here.
For clarity, we omit all of the HTTP headers and message body with the exception of those parts directly related to the operation being demonstrated. The protocol-name URLs shown here are purely for example, and will be determined by the participants at a later date. The URLs for the various for lists will be determined by each merchant application. Because we do not expect proxy servers to participate in the payment negotiation shown during the JEPI demo, the scope parameters of all PEP headers have been omitted: they are defined to default to {scope origin} as required for the demonstration. Similarly, the strength of PEP directives defaults to optional ({str opt}), so it is only shown otherwise.
Either end (client or server) should be able to ask the other what forms of payment it supports.
In order for the client to ask the server what payment choices are available, the Protocol-Query: header is added to an HTTP request from the client to the server. JEPI implementors: In the demo, only the server will generate these requests.
GET URL Protocol-Query: {http://www.w3.org/UPP upp-params}
This means "do you have UPP available at the URL specified in the HTTP request that contains this header." If any of the upp-params are specified then they further restrict the meaning of the query (i.e. if a {upp {amount {frf}}} were specified, the query would mean "do you have UPP available, for amounts denominated in French francs, at the URL specified in the HTTP request that contains this header").
In order to ask a more general question (such as "what payment choices are available for all URLs at your site") the for option must be used:
GET URL Protocol-Query: {http://www.w3.org/UPP {for /*} upp-params}
Notice that in a for, the "URLs" ending in * are actually prefix strings. So the "/*" here means "any URL at your server that starts with '/'," which in turn means all URLs at your server.
The response to this HTTP message will fall into one of two categories:
A proper implementation of PEP requires that the protocol module associated with the specified protocol will be invoked when a Protocol-Query: line is encountered specifying that protocol. A proper implementation of the UPP protocol module will supply one of the responses indicated under Operation 2 (Present Payment Choices), indicating the payment options that the server wishes to advertise.
In order for the server to ask the client what payment choices are available, a similar mechanism is used. In this case, however, the server should use the {for } to indicate the parts of its URL space where payment might be discussed:
200 OK Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*} upp-params}
Technically, this is a way for the server to ask the client to reveal payments choices a user will consider for URLs that begin with /PaymentPages/. The client will reply (at least) whether the protocol can be used for the resource of the response, and (optionally) whether it might be used elsewhere (the range the server specified, anywhere on that server, etc).
A proper implementation of PEP requires that the protocol module associated with the specified protocol will be invoked when a Protocol-Query line is encountered specifying that protocol. A proper implementation of the UPP protocol module will supply one of the responses indicated under Operation 2 (Present Payment Choices), indicating the payment options that the client wishes to advertise.
Then, the next time the client accesses any resource in the for list from the query, it will include its answer(s) to the query.
Either end should be able to list the forms of payment it supports. Notice that this may not be a complete list, but rather a list of options that it "prefers" at the current moment. This list may be presented in response to a request (operation 1) or spontaneously. The latter behavior is analogous to the use of "logo stickers" on a store window or cash register.
JEPI implementors: the demo will only require this operation in response to a specific request.
This operation is performed by adding one or more Protocol-Info: headers to the HTTP packet. If the list is being presented in response to a request (operation 1), PEP requires that it include a header in the following form:
200 OK -or- GET ... Protocol-Info: {http://www.w3.org/UPP [for] [{str strength}] upp-params}
where the for should be the same as the for clause in the request (or omitted if it wasn't in the request); and the strength (if present) must be ref, req, or opt. The strength can be opt (or omitted) in any case; it may be ref only if payment won't be permitted at any of the URLs specified by the for clause; it may be req only if payment is required at all of the URLs specified by the for clause.
In addition, there should be Protocol-Info: headers for each of the payment systems that are to be presented to the other end. These will have the form:
200 OK -or- GET ... Protocol-Info: {http://...payment-system... [for] [{str strength}] payment-params}
where payment-protocol is the URL for the specific payment protocol, the for and strength are as discussed above, and the payment-params are additional parameters (including the UPP parameters) that are specific to the payment system.
For example, if a client receives the request:
200 OK Protocol-Query: {http://www.w3.org/UPP {for /PaymentPages/*} upp-params}
and wishes to indicate that it can pay using VISA over SET and via CyberCash coins it might reply as follows (details of the payment-specific lines are not finalized yet):
HEAD ... Protocol-Info: {http://www.w3.org/UPP {for /PaymentPages/*}} {http://www.SET.org/PEPSpec {params {upp {instrument-brand VISA}}} {for /PaymentPages/*}} {http://www.CyberCash.com/PEPSpec {params {upp {instrument-type ECASH}}} {for /PaymentPages/*}}
The merchant (server) may demand that the client choose a specific form of payment to be used to pay for items.
JEPI implementors: In the demo, this happens when the "invoice page" is sent from the server to the client; the demand indicates what components of the page will require a response with payment choice (operation 4). In the demonstration, this same invoice page will carry both the operation 2 and operation 3 headers together: the server will announce some of its payment options at the time it issues the invoice and requires that payment be accompanied by a particular payment choice.
As part of a standard server (successful) reply, it may deliver a page that includes references that will require payment (i.e. a "Pay Button" or "Pay URL"). These should be identified in the header of the response packet by asking the client to respond by initiating a UPP payment protocol sequence:
200 OK Protocol-request: {http://www.w3.org/UPP {str req} {for /PayButton}}
Technically, this means that the server asks the client to use the UPP protocol (operation 4) whenever it asks for retrieval of the exact URL /PayButton from this same server. The {str req} is a hint to the client that if it doesn't use the protocol, the request for that URL will be refused. Thus, the client is not absolutely required to remember that it should use UPP with the specified URL - but a network roundtrip will be avoided if it does so.
The customer (client) can indicate the payment method to be used to make a payment. This normally indicates to the server that payment should actually begin, and the response will either be to accept (operation 5) or reject (operation 6) the chosen mechanism.
In practice, this will only happen when a client replies to an operation 3 request for payment method. It must then respond with two headers: one indicating that it is responding to a request to use the UPP protocol by choosing a compatible payment protocol, and the compatible protocol header itself. For example, if the payment choice is to use VISA over SET, then we might expect a response as follows:
GET ... Protocol: {http://www.w3.org/UPP {via http://www.SET.org/PEPSpec}} {http://www.SET.org/PEPSpec {str req} {params {upp {instrument-type CREDIT} {instrument-brand VISA}} other-SET-params}}
The expected response is either an operation 5 (server accepts the choice of SET and VISA) or operation 6 (server refuses the choice).
It is expected that somewhere between receiving the operation 3 and issuing the operation 4 the client application will have to decide on the payment mechanism. Neither PEP nor UPP specifies how this happens. For the JEPI demonstration, it is assumed that the browser will intercept the request to access any specified payment URLs (from the for list of the required challenge) and will engage in a dialog with the user if necessary to produce the desired choice. This implies that what merchants might typically describe as the "Pay" button becomes the "Choose a Payment Mechanism and Pay" button.
The server, in response to a payment choice (operation 4), may accept the choice and initiate an actual payment operation. The payment operation itself is not part of the JEPI project and may or may not use PEP to handle the payment.
At this point, operation 4 has provided enough information to the server that it is willing to kick off the actual payment system. JEPI, PEP, and UPP provide no information on precisely how to do this, but there is one additional PEP/UPP header which can be optionally sent back to the client. If a normal MIME-based helper application is available to do the payment on the client side, then there is no need for the following header. On the other hand, a better user interface can often be produced if a helper application can be run while the client (browser) waits for the application to complete. To support this, UPP adds one final message from the server to the client. It provides the URLs that should be shown in each of three cases:
The header is as follows:
200 OK Protocol: {http://www.w3.org/UPP {params {upp {abort abort-URL} {cancel cancel-URL} {success success-URL}}}
The server, in response to a payment choice (operation 4), may reject the choice and request that another choice be made. UPP specifies that a rejection can occur either because the user canceled the transaction prior to completion or because the transaction failed for other (payment-system specific) reasons. They are distinguished and can result in different client actions.
If a client proposes a payment system that is not acceptable to the server, the server responds with a 400- or 500-class PEP error message. The body of the message should explain what went wrong as well as possible, including any explanation that the requested payment system may be able to supply. It should probably include a button to go back to the invoice page, if possible, but the browser's BACK button will work, too. The server should include one additional header on this message to reduce the chance that the same payment system will be tried a second time:
420 Client PEP Error -or- 520 Server PEP Error Protocol-Info: {http://...payment-system... {str ref} payment-params} Followed by an operation 3 header
where payment-system is the payment protocol that is being rejected, payment-params are the parameters of the payment system which caused the problem, and pay-URL is the URL of the item just requested (i.e. the one that initiates the payment protocol on the server side).
The error code is distinguished mainly by whether the server has the protocol and doesn't accept it and the client should know better (422 Protocol Extension Refused) or if the server does not have it (521 Protocol Extension Not Implemented) or cannot get it to work (520 Protocol Extension Error or 522 Protocol Extension Parameters Not Acceptable). Other PEP error codes may be more specifically applicable for particular payment systems.
Either side can ask the other if it supports payment by a particular payment mechanism.
JEPI implementors: This is not currently required for the demonstration, but it might be a useful addition for the client to ask the server this question prior to counter-offering with a payment mechanism not mentioned by the server in its list of supported mechanisms (operation 2).
The PEP header Protocol-Query can be used by either party at any time to ask this question. As with operation 1, there is a technical meaning for the query that requires the other end to respond with a Protocol-Info response that is specific to the particular URL being queried, and the {for } construct can be used to generalize the query.
Also as with operation 1 and 2, a proper implementation of a payment system module for use with UPP should provide additional information about where and with which parameters the payment system will operate when it is possible to do so. That is, a request for "do you support SET for VISA at URL /MerchantHomePage" must be answered "no" (unless payment happens on the home page), but a more thorough response will volunteer the information that such a payment is permitted elsewhere at the site.
200 OK -or- GET ... Protocol-Query: {payment-system [payment-system-params]}
where payment-system is the URL of the payment system protocol,
and payment-system-params are parameters specific to that
protocol (including common UPP parameters).
In short, this protocol only addresses payment selection in the clear. Security of the overall payments process lies in other components.
Donald E. Eastlake 3rd CyberCash, Inc. 318 Acton Street Carlisle, MA 01741 USA Tel: +1<PHONE_NUMBER> (+1<PHONE_NUMBER> main office, Reston, Virginia, USA) Fax: +1<PHONE_NUMBER> Email<EMAIL_ADDRESS>Rohit Khare Technical Staff, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Tel: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> Email<EMAIL_ADDRESS>Jim Miller Technology & Society Area Leader, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Tel: +1<PHONE_NUMBER> Fax: +1<PHONE_NUMBER> Email<EMAIL_ADDRESS>Copyright © 1997 W3C (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.


Places2Go REST API
GET /places HTTP/1.1 Host: <IP_ADDRESS>:3000 Accept-Encoding: gzip, deflate, sdch Accept-Language: es-ES
[{ "_id": "58c8d88b83ca2741d23c1fdc", "address": "Cenotes", "addressFmt": "Cenotes, Mexico", "__v": 0, "date": "2017-03-15T06:00:43.967Z", "loc": { "coordinates": [-96.15075329999999, 18.084935], "type": "Point" } }, { "_id": "58c8d8b483ca2741d23c1fdd", "address": "quito", "addressFmt": "Quito, Ecuador", "__v": 0, "date": "2017-03-15T06:01:24.693Z", "loc": { "coordinates": [-78.4678382, -0.1806532], "type": "Point" } }]
POST /places HTTP/1.1 Host: <IP_ADDRESS>:3000 Content-Length: 149 Accept: application/json, text/plain, */* content-type: application/json Accept-Encoding: gzip, deflate Accept-Language: es-ES, { "address": "Bariloche", "addressFmt": "San Carlos de Bariloche, Río Negro, Argentina", "latitude": -41.1334722, "longitude": -71.3102778 }
HTTP/1.1 200 OK X-Powered-By: Express Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE Access-Control-Allow-Headers: X-Requested-With,charset,content-type Content-Type: application/json; charset=utf-8 Content-Length: 223 ETag: W/"df-fUzORb2usqLy2T/FfRMj8g8AofM" Date: Wed, 15 Mar 2017 17:50:14 GMT Proxy-Connection: Keep-alive { "__v": 0, "address": "Bariloche", "addressFmt": "San Carlos de Bariloche, Río Negro, Argentina", "_id": "58c97ed665383147e4fd992f", "date": "2017-03-15T17:50:14.822Z", "loc": { "coordinates": [-71.3102778, -41.1334722], "type": "Point" } }
DELETE /places/58c8d88b83ca2741d23c1fdc HTTP/1.1 Host: <IP_ADDRESS>:3000 Content-Length: 86 Content-Type: application/json Accept: */* Accept-Encoding: gzip, deflate, sdch Accept-Language: es-ES { "address" : "Iruya", "latitude" : -22.7913886, "longitude" : -65.21593310000003 }
HTTP/1.1 200 OK X-Powered-By: Express Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE Access-Control-Allow-Headers: X-Requested-With,charset,content-type Content-Type: text/plain; charset=utf-8 Content-Length: 2 ETag: W/"2-nOO9QiTIwXgNtWtBJezz8kv3SLc" Date: Wed, 15 Mar 2017 17:33:46 GMT Proxy-Connection: Keep-alive OK
GET /geocode/Bariloche HTTP/1.1 Host: <IP_ADDRESS>:3000 Accept: application/json, text/plain, */* Accept-Encoding: gzip, deflate, sdch Accept-Language: es-ES
HTTP/1.1 200 OK X-Powered-By: Express Access-Control-Allow-Origin: * Access-Control-Allow-Methods: GET, POST, OPTIONS, PUT, PATCH, DELETE Access-Control-Allow-Headers: X-Requested-With,charset,content-type Content-Type: application/json; charset=utf-8 Content-Length: 1378 ETag: W/"562-xszhbsBW9/09dJgCTzn93slVVdY" Date: Wed, 15 Mar 2017 17:50:11 GMT Proxy-Connection: Keep-alive { "status": 200, "headers": { "content-type": "application/json; charset=UTF-8", "date": "Wed, 15 Mar 2017 17:50:00 GMT", "expires": "Thu, 16 Mar 2017 17:50:00 GMT", "cache-control": "public, max-age=86400", "access-control-allow-origin": "*", "server": "mafe", "x-xss-protection": "1; mode=block", "x-frame-options": "SAMEORIGIN", "alt-svc": "quic=\":443\"; ma=2592000; v=\"36,35,34\"", "accept-ranges": "none", "vary": "Accept-Language,Accept-Encoding", "connection": "close" }, "json": { "results": [{ "address_components": [{ "long_name": "San Carlos de Bariloche", "short_name": "San Carlos de Bariloche", "types": ["locality", "political"] }, { "long_name": "Bariloche", "short_name": "Bariloche", "types": ["administrative_area_level_2", "political"] }, { "long_name": "Río Negro", "short_name": "Río Negro", "types": ["administrative_area_level_1", "political"] }, { "long_name": "Argentina", "short_name": "AR", "types": ["country", "political"] }], "formatted_address": "San Carlos de Bariloche, Río Negro, Argentina", "geometry": { "bounds": { "northeast": { "lat": -41.068724, "lng": -71.18855289999999 }, "southwest": { "lat": -41.2011185, "lng": -71.4912761 } }, "location": { "lat": -41.1334722, "lng": -71.3102778 }, "location_type": "APPROXIMATE", "viewport": { "northeast": { "lat": -41.068724, "lng": -71.18855289999999 }, "southwest": { "lat": -41.2011185, "lng": -71.4912761 } } }, "place_id": "ChIJ5WDIIBV7GpYRZZp7y5euEII", "types": ["locality", "political"] }], "status": "OK" } }


GC(1) GC(1) NAME gc - count graph components SYNOPSIS gc [ -necCaDUrs? ] [ files ] DESCRIPTION gc is a graph analogue to wc in that it prints to standard output the number of nodes, edges, connected components or clusters contained in the input files. It also prints a total count for all graphs if more than one graph is given. OPTIONS The following options are supported: -n Count nodes. -e Count edges. -c Count connected components. -C Count clusters. By definition, a cluster is a graph or subgraph whose name begins with "cluster". -a Count all. Equivalent to -encC -r Recursively analyze subgraphs. -s Print no output. Only exit value is important. -D Only analyze directed graphs. -U Only analyze undirected graphs. -? Print usage information. By default, gc returns the number of nodes and edges. OPERANDS The following operand is supported: files Names of files containing 1 or more graphs in dot format. If no files operand is specified, the standard input will be used. EXIT STATUS The following exit values are returned: 0 Successful completion. 1 The -U or -E option was used, and a graph of the wrong type was encountered. AUTHOR Emden R. Gansner<EMAIL_ADDRESS>SEE ALSO wc(1), acyclic(1), gvpr(1), gvcolor(1), ccomps(1), sccmap(1), tred(1), libgraph(3) 21 March 2001 GC(1)


Back for a fourth year, Leeds Wool Festival is a celebration of all things woolly!
10 February – 28 August 2017
Take a free tour!
21 January - 31 December 2017
keep in the now with our
Upcoming events and workshops
Book tickets online now


Merry Xmas Everybody! Slade playing Bristol's O2 Academy just before Christmas
We all know their song which is the ultimate way to get into the festive spirit
by Robin MurrayThere are plenty of ways to get in the festive spirit in Bristol this Christmas.
You could visit the German market in Broadmead, pop into the fabulous spiegeltent on the harbourside or head to the winter wonderland at Cribbs Causeway, to name just a few ideas.
Or if you fancy a more raucous way to get in the mood, you could hear one of the greatest Christmas songs of all time performed live in the flesh by the legendary rock band who created it.
British rockers Slade are performing at Bristol's O2 Academy just 10 days before Christmas Day.
The gig will give people a chance to belt out best-selling single, Merry Xmas Everybody, along with the band and everyone else in the crowd.
Other notable hits penned by the Wolverhampton outfit include Far Far Away, Cum On Feel The Noize and My Oh My.
Sadly, Slade will be performing in Bristol without enigmatic lead singer Noddy Holder, who left the band in 1992.
Follow Discover Bristol
We have a dedicated Facebook page for all the latest on where to drink, eat, go out and events across Bristol.
From the best food and drink deals to exclusive sneak peeks at new restaurants and bars, gig reviews and weekend plans - Discover Bristol has got you covered.
You can follow the page here for all the latest news.
Slade were formed in 1966 with original members Noddy and Jim Lea, but today the band is made up of Dave Hill, Don Powell, John Berry and Russell Keefe.
The original lineup split in 1992 but the band re-formed later in the year as Slade II.
Tickets
Tickets for the gig on December 15 are priced at £28.35 and are available on Ticketmaster's website.
A spokesperson for the O2 Academy said: "Slade are without doubt one of the most iconic bands to come out of Britain and this Christmas they’ll be rocking out across the country on tour performing their much-loved hits."
Follow Discover Bristol
We have a dedicated Facebook page for all the latest on where to drink, eat, go out and events across Bristol.
From the best food and drink deals to exclusive sneak peeks at new restaurants and bars, gig reviews and weekend plans - Discover Bristol has got you covered.
You can follow the page here for all the latest news.
For the latest news in and around Bristol, visit and bookmark Bristol Live's homepage .


zeronet 学习笔记
暂时看起来 zeronet 是一种反共程序员们应该学习的技术, 另外一个软件可能是： IPFS。 这是一个简短的笔记...
这里是一 …
read morehttps://foreignpolicy.com/2020/08/07/slaughter-in-the-east-china-sea/ https://www.youtube.com/watch?v=FDr4RMvYM1s&feature=emb_logo
Slaughter in the East China Sea
What happens if China fights the United States and Japan? A mutual disaster, wargame predicts.
BY MICHAEL PECK | AUGUST 7, 2020, 2:24 PM
An undated photo …
read more


My name is Donald
I live in Ducksburg
Note: For ::after to work in IE8 and earlier, a DOCTYPE must be declared.


Introduction
A dynamic link library to program applications for MIDI-files of types SMF0 or SMF1.
The library HP MIDIFILE allows to load existing MIDI-files or create new ones, to read, insert, delete, change all MIDI-events
of GM1/GM2 and of YAMAHA XG/XF. With functions Select, Copy and Paste sets of events can be inserted at other time-points
into the same or another MIDI-file. There are functions to find and select MIDI-devices and to play the loaded song.
HP MIDIFILE is intended to simplify the creation and editing of MIDI-files. Most of the functions work with the logic of
events, not with internal data.
HP MIDIFILE offers functions to use Instrument Definition Files of the sequencer-software Cakewalk/Sonar.
The user of this library must be familiar with the structure of MIDI and MIDI-files. Applying
YAMAHA SysEx and meta-events he should look at XG- and XF-Specifications. A lot of good documents can be found in the web.
HP MIDIFILE is implemented for the programming language Visual C++ for Windows.


Opportunity records can reference two other types of records, a Contact and an Organization record. While creating your opportunity record, you will be asked to select an organization and contact. If they do not exist already you will have to create them first before proceeding to complete the opportunity record form.
Procedure for creating an opportunity:


Why You're Wrong
I saw this TED video by Kathryn Schulz, and it describes my thought process perfectly. When I have a discussion with you, and you disagree with me, I think:
- You're Ignorant
- The reason you disagree with me, is because you don't know the necessary facts.  If only you learnt some stuff everything would be ok. We carry on talking until I realise you do know the facts, at which point I think
- You're Stupid
- You know the necessary facts, so the reason we disagree is that you can't process the information.    You must be evil. Active malevolence can be the only explanation.
Well maybe it's not a perfect description of my though process. Normally I'm thinking I got flustered and didn't explain myself very well. But all the same. A great quote from the video:
What does it feel like to be wrong? It feels like being right.


|
MysoreScript
|
Struct holding metadata about a class. More...
#include <runtime.hh>
Public Attributes | |
| struct Class * | superclass |
| The superclass of this class, if it has one, or a null pointer if it is a root class. More... | |
| const char * | className |
| The name of this class. More... | |
| int32_t | methodCount |
| The number of methods that this class implements. More... | |
| int32_t | indexedIVarCount |
| The number of indexed instance variables that this class has. More... | |
| struct Method * | methodList |
An array of methodCount elements describing the methods that this class implements. More... | |
| const char ** | indexedIVarNames |
| The names of the instance variables. More... | |
Struct holding metadata about a class.
The first field of all instances of a class will point to one of these structures.
Definition at line 109 of file runtime.hh.
| const char* MysoreScript::Class::className |
The name of this class.
Definition at line 119 of file runtime.hh.
| int32_t MysoreScript::Class::indexedIVarCount |
The number of indexed instance variables that this class has.
Definition at line 127 of file runtime.hh.
| const char** MysoreScript::Class::indexedIVarNames |
The names of the instance variables.
Definition at line 136 of file runtime.hh.
| int32_t MysoreScript::Class::methodCount |
The number of methods that this class implements.
Definition at line 123 of file runtime.hh.
| struct Method* MysoreScript::Class::methodList |
An array of methodCount
elements describing the methods that this class implements.
Definition at line 132 of file runtime.hh.
| struct Class* MysoreScript::Class::superclass |
The superclass of this class, if it has one, or a null pointer if it is a root class.
Definition at line 115 of file runtime.hh.


Processor
with backpressure support.See: Description
| Class | Description |
|---|---|
| ExecutorPoweredProcessor<IN,OUT> |
A base processor used by executor backed processors to take care of their ExecutorService
|
| MutableSignal<T> | |
| ReactorProcessor<IN,OUT> |
A base processor
|
| RingBufferProcessor<E> |
An implementation of a RingBuffer backed message-passing Processor.
|
| RingBufferWorkProcessor<E> |
An implementation of a RingBuffer backed message-passing WorkProcessor.
|
| Enum | Description |
|---|---|
| MutableSignal.Type |
| Exception | Description |
|---|---|
| CancelException |
An exception signal from downstream subscribers consuming data when their state is denying any additional event.
|
| InsufficientCapacityException |
Exception thrown when the it is not possible to dispatch a signal a
Dispatcher . |
Processor
with backpressure support.
Unlike Dispatcher
, these components will be unique and bound to a given stream of data.
A Processor
will manage its own thread(s), one by Subscriber
.
The message-passing will be implementation dependant, e.g. using a com.lmax.disruptor.RingBuffer
.
Usually, the boundary will be implemented with a queue-based event dispatching and the Reactive Stream contract will
offer control over the available backlog. Long.MAX demand will however switch off the contract and rely on the impl
coordination strategy to back-off, like the RingBuffer waiting strategy, to slow down the Processor publisher.
These Processors are typically expansive to create, best to consider a few places to use them rather than creating them recurly.


Dear Dry,
Please join us at the Women, Money, Power Summit on October 8 at the Capital Hilton Hotel in Washington, D.C.!
I’m very excited that we are bringing together such a great combination of feminist activists, experts and readers. You don’t want to miss it, register today! [ http://feministmajority.org/women-money-power/2013WomenMoneyPower/registration.htm ]
The Summit is being kicked off Tuesday at 9:30 a.m. with a lively discussion on how to stop the War on Women and its attacks on everything from women’s health to voting rights, food stamps and our wallets. The second panel of the morning will focus on some cutting-edge research on women’s global reproductive rights.
At our luncheon at noon, we’ll honor trailblazing feminists: Rep. Rosa DeLauro (D - Conn.), Texas state Sen. Leticia Van de Putte, and Barbara Arnwine, executive director of the Lawyer’s Committee for Civil Rights Under Law. And that only gets us to 2 p.m.!
Our first afternoon summit discussion will present to attendees key strategies on ratifying the international women’s treaty CEDAW, passing the Equal Rights Amendment, organizing on critical upcoming ballot initiatives and ending violence against women.
We’ll wrap up with a town hall discussion on the Affordable Care Act, emphasizing what women need to know and how advocates can maximize its success.
Dry, I’m sure you can see what a fantastic event this will be. 38 organizations think so too and have already signed up to be sponsors! [ http://feministmajority.org/women-money-power/2013WomenMoneyPower/registration.htm ]
Visit the Women, Money, Power website [ http://feministmajority.org/women-money-power/2013WomenMoneyPower/registration.htm ] for more information. And stay tuned for upcoming updates


Viscous lidocaine 2% gel was applied to the right left naris. Cetacaine sprayed into the mouth.
A French feeding tube was placed through the naris into the esophagus stomach duodenum jejunum . Position was confirmed with instillation of a small amount of water-soluble contrast. The tube was flushed with water.
The tube was secured to the nose with .
Feeding tube placement. Ready for immediate use.


Getting help on using skimage
¶
Besides the user guide, there exist other opportunities to get help on
using skimage
.
Examples gallery¶
The General examples gallery provides graphical examples of typical image processing tasks. By a quick glance at the different thumbnails, the user may find an example close to a typical use case of interest. Each graphical example page displays an introductory paragraph, a figure, and the source code that generated the figure. Downloading the Python source code enables one to modify quickly the example into a case closer to one’s image processing applications.
Users are warmly encouraged to report on their use of skimage
on the
Mailing-list, in order to propose more examples in the future.
Contributing examples to the gallery can be done on github (see
How to contribute to skimage).
Search field¶
The quick search
field located in the navigation bar of the html
documentation can be used to search for specific keywords (segmentation,
rescaling, denoising, etc.).
API Discovery¶
NumPy provides a lookfor
function to search API functions.
By default lookfor
will search the NumPy API.
NumPy lookfor example:
`np.lookfor('eigenvector') `
But it can be used to search in modules, by passing in the module name as a string:
` np.lookfor('boundaries', 'skimage') `
or the module itself.
`
> import skimage
> np.lookfor('boundaries', skimage)
`
Docstrings¶
Docstrings of skimage
functions are formatted using Numpy’s
documentation standard,
starting with a Parameters
section for the arguments and a
Returns
section for the objects returned by the function. Also, most
functions include one or more examples.
Mailing-list¶
The scikit-image mailing-list is<EMAIL_ADDRESS>(users
should join before posting). This
mailing-list is shared by users and developers, and it is the right
place to ask any question about skimage
, or in general, image
processing using Python. Posting snippets of code with minimal examples
ensures to get more relevant and focused answers.
We would love to hear from how you use skimage
for your work on the
mailing-list!


procedure BlockTransferX(
Dst: TCustomBitmap32;
DstX: TFixed;
DstY: TFixed;
Src: TCustomBitmap32;
SrcRect: TRect;
CombineOp: TDrawMode;
CombineCallBack: TPixelCombineEvent
= nil);
BlockTransferX is an extended version of BlockTransfer that allows a destination coordinate (DstX, DstY) in fixed-point coordinates. This means that the source bitmap is not copied directly but rather transposed a fractional distance before it is copied. In order to still retain reasonable performance, linear interpolation is used for the fractional displacement.
See BlockTransfer for a detailed description.


The eBay grid is a flexbox first layout system, used to give to structure and form to designs. It will enable building consistent layouts across multiple pages.
By using our grid system pages can be made to adapt to any screen size. It uses media queries in order to change the layout. However, builds will be included for both adaptive and responsive use cases.
The large and medium grid layouts are based on fractions of sixteen; the small grid is fractions of eight. Each grid cell has a percentage width with fixed "gutters". Having fixed spacing allows for consistent rhythm in our vertical and horizontal spacing.
Currently the maximum width of a layout is 1280 pixels, but this system can easily be customized to fit all needs.
If you are using Lasso.js, you can include the grid css by adding a flag to your lasso configuration. For this to work you must include the @ebay/skin/grid module in your browser.json as a dependency. If no flags are specified the grid-core file will be loaded into your page.
grid-core
Adds the core grid system to your page. This includes just includes the lg, sm, and default grid sizes.
grid-large
In order to accommodate adaptive designs the large and extra-large classes were broken up into their own file. This allows for applications to only pull in the large and extra-large classes
grid-small
In order to accommodate adaptive designs the small classes were broken up into their own file. This allows for applications to only pull in the small classes
grid-full
Adds the entire grid system to your page. This includes the lg, sm and the default grid sizes. As well as the necessary classes to utilize nested grids.
The grid system is also available via CDN: https://ir.ebaystatic.com/cr/v/c1/skin/v6.3.3/ds4/grid-full.min.css
In order to simplify the grid system classes, the default classes to layout a page are .grid__cell--*of*, replacing the * with a number up to 16.
Content....
Content....
The standard .grid__cell modifier classes will also have modifier classes to faciliate responsive page changes for different screen sizes. These are the same as the standard .grid__cell modifier class except they have a "-lg" or "-sm" post-fix.
600 |
960 |
1280 |
|
| 8 columns | 16 columns | ||
| Small | Medium | Large | |
|---|---|---|---|
| Class | .grid__cell--*of*-sm
.grid__cell--4of8-sm |
.grid__cell--*of*
.grid__cell--5of16 |
.grid__cell--*of*-lg
.grid__cell--8of16-lg |
| Media query | @media(max-width: 600px) | @media(min-width: 961px) | |
| Viewport size | <= 600px | >= 961px | |
| Gutter size | 8px | 16px | 16px |
16
4
4
4
4
4
8
4
8
8
In order to make using the grid system easier, a set of commonly used fractions were identified. These classes can be used if the percentage of the column will be staying the same regardless of the screen size. This allows for less code to be written in the markup.
For example, instead of using .grid__cell--4of16 .grid__cell--2of8-sm to represent one-half on both large and small screens, the class .grid__cell--one-half .
.grid__cell--one-half
.grid__cell--one-half
.grid__cell--one-fourth
.grid__cell--three-fourth
.grid__cell--one-third
.grid__cell--two-third
.grid__cell--one-fifth
.grid__cell--four-fifth
.grid__cell--two-fifth
.grid__cell--three-fifth
One Fourth
Three Fourth
One Third
Two Third
One Fifth
Four Fifth
Two Fifth
Three Fifth
The grid__cell element's proportions are relative to their parent container. A few rules exist for the .grid .grid selector and the .grid .grid > .grid__group selector. So, in order for nesting to work properly .grid__group elements should have a direct parent that is a .grid element. In other words, you should not place a .grid__group directly inside a .grid__cell.
Only available in grid-full.less. Contains every possible fraction, which is the reason for the significantly larger file size.
I am nested
I am nested
Instead of using .grid__cell--16of16, .grid__group--full can be used to achieve a full width row with the cell properties. This requires one less element, which is nice.
Content....
Content....
Content....
Content....
In cases where you want to hide a segment of layout for a certain screen size use the .grid__cell--sm-hidden, .grid__cell--md-hidden, or .grid__cell--lg-hidden modifier class.
Content....
Content....
Content....
Content....
Content....
Content....
If there is a case where you need the content within a group to wrap, the .grid__group--wrap modifier class is used.
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Wrapping can be useful when a piece of a layout needs to adapt to different screen sizes.
Content....
Content....
Content....
Content....
Content....
Content....
Content....
Content....
If there is a desire to have a cell fill the rest of the left-over space, use .grid__cell--grow.
This can be used to make responsive choreography between .grid__cell elements easier.
Has Breakpoints
Growth
One Third
Has Breakpoints
Growth
One Third
Its goals are to help:
Currently the Design Grid Overlay Chrome extension is available in the extensions section of Chrome Web store.


In human behavior analysis, the Visual Focus Of Attention (VFOA) of a person is a very important cue. VFOA detection is difficult, though, especially in a unconstrained and crowded environment, typical of video surveillance scenarios. We estimate the VFOA by defining the Subjective View Frustum, which approximates the visual field of a person in a 2D (ground floor) representation of the scene. This opens up to several intriguing behavioral investigations. In particular, we propose the Inter-Relation Pattern Matrix, that suggests possible social interactions between the people.


| ID | Category ID | Category Name | position |
|---|---|---|---|
| ID | Category ID | Category Name | Position |
| Ashton Cox | Junior Technical Author | San Francisco | 66 |
| Michael Silva | Marketing Designer | London | 66 |
| Jackson Bradshaw | Director | New York | 65 |
| Olivia Liang | Support Engineer | Singapore | 64 |
| Paul Byrd | Chief Financial Officer (CFO) | New York | 64 |
| Serge Baldwin | Data Coordinator | Singapore | 64 |
| Garrett Winters | Accountant | Tokyo | 63 |
| Brielle Williamson | Integration Specialist | New York | 61 |
| ID | Category ID | Category Name | position |
|---|---|---|---|
| ID | Category ID | Category Name | Position |
| Ashton Cox | Junior Technical Author | San Francisco | 66 |
| Michael Silva | Marketing Designer | London | 66 |
| Jackson Bradshaw | Director | New York | 65 |
| Olivia Liang | Support Engineer | Singapore | 64 |
| Paul Byrd | Chief Financial Officer (CFO) | New York | 64 |
| Serge Baldwin | Data Coordinator | Singapore | 64 |
| Garrett Winters | Accountant | Tokyo | 63 |
| Brielle Williamson | Integration Specialist | New York | 61 |
| ID | Name | Position |
|---|---|---|
| ID | Category ID | Position |
| Ashton Cox | Junior Technical Author | San Francisco |
| Michael Silva | Marketing Designer | London |
| Jackson Bradshaw | Director | New York |
| Olivia Liang | Support Engineer | Singapore |
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
Default To 5
Default To 30
* These fields are required.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
* These fields are required.
* These fields are required.
* These fields are required.
| ID | Key | Name | Step | type | View Action | Pos | SVG | Price |
|---|---|---|---|---|---|---|---|---|
| ID | Category ID | Category Name | Position | |||||
| Ashton Cox | Junior Technical Author | San Francisco | 66 | Ashton Cox | Junior Technical Author | San Francisco | 66 | 66 |
| Michael Silva | Marketing Designer | London | 66 | Ashton Cox | Junior Technical Author | San Francisco | 66 | 66 |
* These fields are required.
* These fields are required.
* These fields are required.
Checkbox: show/hide an SVG snippet. Colour Picker/Colour Tile Picker: pick a colour from a data source. Custom: any custom SVG. Description: text on the form. Dropdown: select from a data source. Horizontal Rule: a horizontal line on the form. Image: image file upload. Pattern Transform: position and scale a pattern's content. Tile Picker (image): select from a list of data source item images. Tile Picker (description): select from a data source item descriptions. Transform: position and scale SVG elements. Text Box: enter text (e.g. for Set Text view action). Text Area: multiline text for notes/comments. Does not make multi-line SVG text. Slider: set a number value e.g. font size. Team Details: enter each team with each players' details: size, name and number. Must use 'teamdetails' key. Editor Units: Add multiple images and text. Must use 'editor' key. Color List: Generate a list of colours from an image and allow customer to enter pantones next to each major colour. Key must be same as image key + list. e.g. key = "imagelist" if the image key was "image".
* These fields are required.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
* These fields are required.
* These fields are required.
* These fields are required.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
* These fields are required.
* These fields are required.
* These fields are required.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
How this field affects the SVG.
Fill: fills the entire selected region the selected colour.
Outline Colour: changes the outline colour on the selected region.
Show Selected: shows the current data source item and hides the rest.
Toggle: turn on/off the selected region.
Pattern Fill: fills the entire selected region the pattern selected from the data source.
Pattern Transform: move and scale pattern.
Set Image: changes an SVG image to display the image currently selected by the customer. SVG
image required e.g.
* These fields are required.
* These fields are required.
* These fields are required.
| ID | Name | SKU | Price | Position | Active |
|---|---|---|---|---|---|
| ID | Name | SKU | Price | Position | Active |
| Ashton Cox | Junior Technical Author | San Francisco | 66 | Ashton Cox | Junior Technical Author |
| Michael Silva | Marketing Designer | London | 66 | Ashton Cox | Junior Technical Author |
* These fields are required.
| ID | Name | Position | Price |
|---|---|---|---|
| ID | Name | Position | Price |
| Ashton Cox | Junior Technical Author | San Francisco | 66 |
| Michael Silva | Marketing Designer | London | 66 |
| Jackson Bradshaw | Director | New York | 65 |
| Olivia Liang | Support Engineer | Singapore | 64 |
| Paul Byrd | Chief Financial Officer (CFO) | New York | 64 |
| Serge Baldwin | Data Coordinator | Singapore | 64 |
| Garrett Winters | Accountant | Tokyo | 63 |
| Brielle Williamson | Integration Specialist | New York | 61 |
* These fields are required.
| ID | Product/Design Name | Position |
|---|---|---|
| Ashton Cox | Junior Technical Author | San Francisco |
| Michael Silva | Marketing Designer | London |
| ID | Product Name | Image | position |
|---|---|---|---|
| ID | Product Name | Image | Position |
| Ashton Cox | Junior Technical Author | San Francisco | 66 |
| Michael Silva | Marketing Designer | London | 66 |
| Jackson Bradshaw | Director | New York | 65 |
| Olivia Liang | Support Engineer | Singapore | 64 |
| Paul Byrd | Chief Financial Officer (CFO) | New York | 64 |
| Serge Baldwin | Data Coordinator | Singapore | 64 |
| Garrett Winters | Accountant | Tokyo | 63 |
| Brielle Williamson | Integration Specialist | New York | 61 |
* These fields are required.
| ID | Product/Design Name | Position |
|---|---|---|
| ID | Product/Design Name | Position |
| Ashton Cox | Junior Technical Author | San Francisco |
| Michael Silva | Marketing Designer | London |
| Jackson Bradshaw | Director | New York |
* These fields are required.
| ID | Minimum Quantity | Unit Price | Fixed Discount | Percent Discount |
|---|---|---|---|---|
| ID | Minimum Quantity | Unit Price | Fixed Discoun | Percent Discount |
| Ashton Cox | Junior Technical Author | San Francisco | Product/Design Name | Position |
| Michael Silva | Marketing Designer | London | Product/Design Name | Position |
| Jackson Bradshaw | Director | New York | Product/Design Name | Position |


I was looking for a way to quickly encrypt large files in python.
After some digging, I ran across this post on stackoverflow.com. The basic idea here is to use standard python libraries to take a plaintext file and make an AES encrypted copy in a manner that is compatible with OpenSSL tools.
The code provided in the post work like a charm when collecting memory, disk space is a big issue. Most systems these days are running at least 8GB. Making two full size copies of a memory dump on a host machine is not practical even under ideal conditions. Even if I compress first, we still need enough free space to cover of the original plus the compressed copy. Sometimes that is not available.
To help with this issue, I adapted the script to encrypt the file as it reads it.
Here is the important tweak that I made:
So we are reading chunk of the file, encrypting it, then overwriting the chunk with encrypted data until we get to the end of the file.
Does this really work you ask? Of course it does.
Don't know why this feels like a magic trick but TA DA!
This doesn't fix all of my issues with moving huge files around but this does encrypt it locally before it is sent over the network without needing double the space.
Big thanks to Thjis van Dien for putting this solution out there.


Time Films· Various Through the Years
2015 - Present.Below are various films I have made that loosely explore similar concepts of time as a malleable and non-linear material. If a photograph is believed to freeze a moment in time forever, and film/video is understood as a series or montage of individual images, then surely moving footage contains a sculptural, physical quality.
These short films represent a growing personal exploration of how film can be used to play with time as a material; using it to reveal, call to attention, and meditate on the spaces and movements we encounter as humans.
Premiere After Effects Video Editing Film Equiptment
The Project Hilaria
Exploring time distortion as a way of exploring and uncovering our visual surroundings. Simultaneously empowering the physicality of revealing the moment, and liquifying the perpetual elements of time. Shot at the Louvre in Paris France.
The Project Shaped Series
Juxtaposing locked and walled geometries with melting and evaporating represenatations of time. In a Bauhausian fashion, recognising that in order to make sense of our society's complex yet conservative viewpoint on time, we must release our previous conceptions, and return to the fundamental qualities of our world: shape, space, movement.
The Project D'Orsay
Enlongating moments, freezing eternities. Alan Watts.


Because thymus.js runs on the client it's not inheriently
application context aware. Therefore, thymus.js uses a
configurable
data-thx-context-path
attribute on the thymus.js script tag. It's value
establishes the path to the root context of the application that
will be resolved along with the fragment's inclusion URL. Fragment
definitions can point to resources with different path levels. So,
it's imporant that the
data-thx-context-path
synchronizes with the path defined within the fragment. For
example, a fragment that resides in example.com/my-app/frags/nav.htm
may also be included in example.com/my-app/index.htm as
well as example.com/my-app/user/info.htm. If the fragment
is defined something like:

 ...

And both example.com/my-app/index.htm and example.com/my-app/user/info.htm contain a corresponding include (or replacement):

 ...

Then the thymus.js script definitions would be as follows:
 <meta charset="utf-8" />
 <meta charset="utf-8" />
Notice that in both resources the
data-thx-context-path
points to example.com/my-app with my-app being the
root context (example.com/my-app/index.htm uses "."
which infers the current path; which would be example.com/my-app/
while example.com/my-app/user/info.htm uses "../"
which infers one directory up; which would be example.com/my-app/).
This vasly simplifies fragment path resolution (escpecially for
nested fragments) and ensures that all fragment
inclusion/replacement paths are relative to the root context path
of the application. It also permits the use of the same paths to
exist in
data-thx-include
or
data-thx-replace
attributes; regardless of where the page that defines it resides.
File extensions in fragment URLs are optional (and sometimes
undesirable). That's why thymus.js, by default, will use
the URL defined in
data-thx-include
or
data-thx-replace
per verbatim unless a
data-thx-frag-extension
is defined. If a
data-thx-frag-extension
attribute is defined on the thymus.js
script
it will use the
data-thx-frag-extension
value as the file extension and will appened it to any fragment
URLs that do not already have a file extension (should typically
be prefixed with a period). Any fragment URLs that have their own
file extension will not get the
data-thx-frag-extension
appended their fragment URLs. A special value of inherit
can be used if fragments should inherit the parent page file
extension (if any). Here are a few variations:

As with Fragment Path Resolution, relative
URLs within fragments are resolved to their absolute URL
counterparts relative to the root context of the application as
defined by the
data-thx-context-path
on the thymus.js
script
. Only
href
and
src
attributes with relative paths are eligable for updating. Any
href
/
src
attributes that contain URLs that begin with an IANA
registered scheme or begin with a / will NOT be
updated by thymus.js. When any
href
/
src
attributes within a fragment begin with a protocol-relative
URL (i.e. //) and the page is being called using a file URI
scheme the URL will default to
http:
in order to preserve external URL integrity. Here are a few
examples:
  ...
  ...
  ...
  <link href="//code.jquery.com/ui/jquery-ui-git.css" rel="stylesheet" />  <link href="http://code.jquery.com/ui/jquery-ui-git.css" rel="stylesheet" />
Typically,
data-thx-include
/
data-thx-replace
use the name of the fragment as the target. For instance,
data-thx-include="frags/nav/nav :: topnav"
points to a fragment target with a corresponding
data-thx-fragment="topnav"
(with topnav being the fragment name/target). The advantage
of this is that it abstracts any fragment identification away from
CSS/JS definitions. The disadvantage is that it requires the use
of separate
data-thx-fragment
attributes that are specific to thymus.js. For this reason
and for selection flexibility thymus.js permits the use of
additional types of fragment targets.
JQuery selectors can be used to identify the retrieved fragment's DOM element(s) that will be included or replaced within the DOM. For example:

 ...

 User

 User
 ...

A
data-thx-replace
would not make sense if the selector returned more than one
element (in which case only the last found element would be
present in the replacement). However, a
data-thx-include
with a selector that returns more than one result would:

User 1

User 2

User 1

User 2

Not only can fragment targets contain corresponding
data-thx-fragment
names or JQuery selectors, they can also contain a
function
that will handle raw fragment results.

source
type
data
status
xhr
process
function
that will process the inclusion or replacement.
Arguments:
error
function
defined as the fragment target must be available for execution at
the time that the fragment result is returned.
content-type
Resolution
By default thymus.js assumes that content retrieved for
fragments have
text/html
content, but there are also other types of fragments that are
supported by thymus.js. Not all of the standard
media types are supported and will cause errors if an attempt is
made to non-supported content types via thymus.js. See the model-to-view transitions section for more
details on using other supported
content-type
.


Build Materials
Link
Link
AnotherLink
Another Link
Post header
Username
01/01/2000
Category
Sample post 1
Learn more
Post header
Username
01/01/2000
Category
Sample post 1
Learn more
Post header
Username
01/01/2000
Category
Sample post 1
Learn more
Post header
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd
Post header
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd
Sample post 1dsadasd


{% include 'header_fix.html' %} Have an account? Log in to access the site. Log In Have an account? Log in to access the site. Log In Site Sign up Register {% include 'footer.html' %}
Log in to access the site.


 Typically, lmcurve() is used to approximate a data set t,y by a parametric function f(ti;par). On success, par represents a local minimum, not necessarily a global one; it may depend on its starting value.
lmcurve_tyd() does the same for a data set t,y,dy, where dy represents the standard deviation of empirical data y. Residues are computed as r[i] := (y[i] - f(t[i];par))/dy[i]. Users must ensure that all dy[i] are positive.
Function arguments:
Number of free variables. Length of parameter vector par.
Parameter vector. On input, it must contain a reasonable guess. On output, it contains the solution found to minimize ||r||.
Number of data points. Length of vectors t and y. Must statisfy n_par <= m_dat.
Array of length m_dat. Contains the abcissae (time, or "x") for which function f will be evaluated.
Array of length m_dat. Contains the ordinate values that shall be fitted.
Only in lmcurve_tyd(). Array of length m_dat. Contains the standard deviations of the values y.
A user-supplied parametric function f(ti;par).
Parameter collection for tuning the fit procedure. In most cases, the default &lm_control_double is adequate. If f is only computed with single-precision accuracy, &lm_control_float should be used. Parameters are explained in lmmin(3).
A record used to return information about the minimization process: For details, see lmmin(3).
Fit a data set y(x) by a curve f(x;p):
#include "lmcurve.h"
#include <stdio.h>
/* model function: a parabola */
double f( double t, const double *p )
{
return p[0] + p[1]*t + p[2]*t*t;
}
int main()
{
int n = 3; /* number of parameters in model function f */
double par[3] = { 100, 0, -10 }; /* really bad starting value */
/* data points: a slightly distorted standard parabola */
int m = 9;
int i;
double t[9] = { -4., -3., -2., -1., 0., 1., 2., 3., 4. };
double y[9] = { 16.6, 9.9, 4.4, 1.1, 0., 1.1, 4.2, 9.3, 16.4 };
lm_control_struct control = lm_control_double;
lm_status_struct status;
control.verbosity = 7;
printf( "Fitting ...\n" );
lmcurve( n, par, m, t, y, f, &control, &status );
printf( "Results:\n" );
printf( "status after %d function evaluations:\n %s\n",
status.nfev, lm_infmsg[status.outcome] );
printf("obtained parameters:\n");
for ( i = 0; i < n; ++i)
printf(" par[%i] = %12g\n", i, par[i]);
printf("obtained norm:\n %12g\n", status.fnorm );
printf("fitting data as follows:\n");
for ( i = 0; i < m; ++i)
printf( " t[%2d]=%4g y=%6g fit=%10g residue=%12g\n",
i, t[i], y[i], f(t[i],par), y[i] - f(t[i],par) );
return 0;
}
Copyright (C) 2009-2015 Joachim Wuttke, Forschungszentrum Juelich GmbH
Software: FreeBSD License
Documentation: Creative Commons Attribution Share Alike
Homepage: http://apps.jcns.fz-juelich.de/lmfit
Please send bug reports and suggestions to the author <j.wuttke@fz-juelich.de>.


4 Hours 20 Minutes ago
Sync to Heartrate (Only available on mobile app)
Sync to your Pace (Only available on mobile app)
Sync with Friends
Christiano Ronaldo
Floyd Mayweather Jr
Roger Federer


(*=invited, p=poster, o=oral)
Mizuta, K., S. Grunwald, M.A. Phillips, C. B. Moss, C. Wendell Jr., A. R. Bacon. 2020. Sensitivity Analysis of Metafrontier Data Envelopment Analysis for Assessing Soil Carbon Sequestration Efficiencies. North America Productivity Workshop XI. FL, USA (o)
Mizuta, K., S. Grunwald, and M.A. Phillips. 2019. Introduction to Pedo-Econometrics. Soil Science Society of America International Annual Meeting. CA, USA (o)
Mizuta, K., S. Grunwald, and M.A. Phillips. 2019. Econometric Case Study to Compute the Capability of Soil Carbon Sequestration in Florida. Soil Science Society of America International Annual Meeting. CA, USA (o)
Mizuta, K., S. Grunwald, M.A. Phillips, W.P. Cropper, A. Bacon, C.B. Moss. 2019. How to Make Sense of the Plurality of Soil Carbon Sequestration assessed within the Data Envelopment Analysis Indication System. 26th Pedometrics International Conference. Ontario, Canada (p)
Grunwald, S., R.K. Kastner-Wilcox, C.M. Clingensmith, K. Mizuta, and C. Gavilan. 2018. The integral soil model to address local and global soil health and security. 21st World Congress of Soil Science, Rio de Janeiro. Brazil (o)
Mizuta, K., S. Grunwald, 2018. The developmental history of soil concepts. Annual Soil and Water Sciences Research Forum. Gainesville, FL (p)
Grunwald, S., R. Kastner-Wilcox, C. Gavilan, K. Mizuta, and C. M. Clingensmith. 2017. Facts, data and people’s beliefs – An integral model to address soil health and security. Soil Science Society International Annual Meeting. FL, USA (o)
Grunwald, S., C. M. Clingensmith, R. Kastner-Wilcox, K. Mizuta, and C. Gavilan. 2017. The integral soil model in support of global soil health and security. Soil Science Society International Annual Meeting. FL, USA (o)
Mizuta, K., S. Grunwald, W.P. Cropper, W. Lee, G.M. Vasques, M.A. Phillips, W.G. Harris, D., B. Myers, and X. Xiong. 2017. A novel pedometrics-econometrics approach to assess soil carbon capability. 25th anniversary Pedometrics International Conference. Wageningen, Netherland (o)
Mizuta, K., S. Grunwald, G.M.Vasques, W.Lee, M.A.Phillips, W.P. Cropper, X, Xiong, W.G.Harris,B.Myers. 2017. Modelling Pedo-Econometric carbon scores with VNIR spectroscopy. 25th anniversary Pedometrics International Conference. Wageningen, Netherland (p)
Mizuta, K. 2017. Climate change, soil carbon, and environmental security. Invited by Dr. Michelle Phillips, Warrington College, University of Florida. (*)
Mizuta, K. and S. Grunwald. 2016. Lessons from Econometric Theory to develop novel indication systems for soil quality, soil health and soil security. Soil Science Society International Annual Meeting. AZ, USA (o)
Mizuta, K. 2016. Science and soil. Japanese Association of Integral Studies. FL, USA (o)
Mizuta, K., Grunwald, S., Cropper, W.P. Lee, W.S., Vasques G.M. Phillips, M.A. 2016. Prototype development of a new soil index using the econometric method Data Envelopment Analysis. Annual Soil and Water Sciences Research Forum, Gainesville, FL (selected as the BEST poster) (p)
Mizuta, K. 2016. Alumnus talk-career path to graduate schools in the U.S. Invited by Soka University, Japan. (*)
Mizuta, K. 2016. Index study for soil science and pedo-metrics. Invited by Soka University, Japan. (*)
Mizuta, K. 2016. Up-to-date research flow of soil science - soil security and pedo-metrics. Invited by Kyoto University, Japan. (*)
Mizuta, K. 2016. Application processes for scholarships and graduate schools in the U.S. Invited by Kyoto University, Japan (*)
Ceddia, M.B., É.F.M. Pinheiro, K. Mizuta, S. Grunwald, C. M. Clingensmith, and B. Cao 2015. Applying the Meta Soil Model: the connections between Soil Security and water security in a permanent protection area in Brazil. The Global Soil Security Symposium, TX, USA (o)
Grunwald, S., B. Cao, M.B. Ceddia, C.M. Clingensmith, K. Mizuta, and É.F.M. Pinheiro. 2015. The Meta Soil Model: An Integrative Multi-Model Framework for Soil Security. The Global Soil Security Symposium. TX, USA (o)
Mizuta. K. 2015. Alumnus talk –pathway to the U.S. graduate schools. Invited by Soka University. (*)
Mizuta. K. 2014. How to prepare applications for U.S. graduate school admissions and scholarships? Invited by International Cross-Cultural Committee Co. (Seattle Office, WA, USA). (*)
Mizuta, K. and S. Sato. 2014. Soil aggregate formation and stability induced by starch and cellulose. 20th World Congress of Soil Science. Jeju, Korea (o)
Mizuta, K., Taguchi, S. and Sato, S. 2014. CO2 flux from a Japanese tropical soil applied with glucose and starch. Soil Science Society International Annual Meeting. CA, USA (p)


URL Shortener
Operations:
Create Short URL
Short Name:
URL:
List All Short URLs
Update Short URL
Short Name:
New URL:
Delete Short URL
Short Name:
List All Users
Sign In
Username:
Sign Out
Sign Up
Username:
Response:


Before Change
logger.debug("No rng and no run_id given: using run_id %d as seed.", run_id)
rng = np.random.RandomState(seed=run_id)
elif isinstance(rng, int):
if run_id is None:
run_id = rng
else:
pass
rng = np.random.RandomState(seed=rng)
elif isinstance(rng, np.random.RandomState):
if run_id is None:
run_id = rng.randint(MAXINT)
else:
pass
else:
raise ValueError("This should not happen! Please contact the developers! Arguments: rng=%s of type %s and "
"run_id=% of type %s" % (rng, type(rng), run_id, type(run_id)))
return run_id, rng
After Change
elif rng is None and isinstance(run_id, int):
logger.debug("No rng and no run_id given: using run_id %d as seed.", run_id)
rng_return = np.random.RandomState(seed=run_id)
run_id_return = run_id
elif isinstance(rng, int) and run_id is None:
run_id_return = rng
rng_return = np.random.RandomState(seed=rng)
elif isinstance(rng, int) and isinstance(run_id, int):
run_id_return = run_id
rng_return = np.random.RandomState(seed=rng)
elif isinstance(rng, np.random.RandomState) and run_id is None:
rng_return = rng
run_id_return = rng.randint(MAXINT)
elif isinstance(rng, np.random.RandomState) and isinstance(run_id, int):
rng_return = rng
run_id_return = run_id
else:
raise ValueError("This should not happen! Please contact the developers! Arguments: rng=%s of type %s and "
"run_id=%s of type %s" % (rng, type(rng), str(run_id), type(run_id)))
return run_id_return, rng_return


- abolish
- To abolish a predicate is to retract all the
predicate's clauses and to remove all information about it
from the Prolog system, to make it as if that predicate had never
existed.
- advice-point
- A special case of breakpoint, the advice breakpoint. It is
distinguished from spypoints in that it is intended for
non-interactive debugging, such as checking of program invariants,
collecting information, profiling, etc.
- alphanumeric
- An alphanumeric character is any of the lowercase characters from
`a' to `z', the uppercase characters from `A' to
`Z', the numerals from `0' to `9', or underscore
(`_').
- ancestors
- An ancestor of a goal is any goal that the system is
trying to solve when it calls that goal. The most distant
ancestor is the goal that was typed at the top-level prompt.
- anonymous variable
- An anonymous variable is one that has no unique name, and whose
value is therefore inaccessible. An anonymous variable is denoted
by an underscore (`_').
- argument
- See predicate, structure, and arity.
- arity
- The arity of a structure is its number of arguments.
For example, the structure
customer(jones,85)
has an arity
of 2.
- atom
- A character sequence used to uniquely denote some entity in the problem
domain. A number is not an atom. Examples of legal atoms are:
hello * := '#$%' 'New York' 'don\'t'
See ref-syn-trm-ato. Atoms are recognized by the built-in
predicate atom/1
. Each Prolog atom is represented
internally by a unique integer, represented in C as an SP_atom
.
- atomic term
- Synonym for constant.
- backtrace
- A collection of information on the control flow of the program,
gathered by the debugger. Also the display of this information produced
by the debugger. The backtrace includes data on goals that
were called but not exited and also on goals that exited
nondeterminately.
- backtracking
- The process of reviewing the goals that have been satisfied and
attempting to resatisfy these goals by finding alternative
solutions.
- binding
- The process of assigning a value to a variable; used in
unification.
- blocked goal
- A goal that is suspended because it is not instantiated
enough.
- body
- The body of a clause consists of the part of a Prolog
clause following the `:-' symbol.
- breakpoint
- A description of certain invocations in the program where the user
wants the debugger to stop, or to perform some other actions. A
breakpoint is specific if it applies to the calls of a
specific predicate, possibly under some conditions; otherwise, it
is generic. Depending on the intended usage, breakpoints can
be classified as debugger breakpoints, also known as
spypoints, or advice breakpoints, also called
advice-points; see Advanced Debugging.
- breakpoint spec
- A term describing a breakpoint. Composed of a test
part, specifying the conditions under which the breakpoint should
be applied, and an action part, specifying the effects of the
breakpoint on the execution.
- byte-list
- A byte-list is a list of bytes, i.e. integers in [0,...,255].
- buffer
- A temporary workspace in Emacs that contains a file being edited.
- built-in predicate
- A predicate that comes with the system and that does not have to
be explicitly loaded before it is used.
- callable term
- A callable term is either a compound term or an atom.
Callable terms are recognized by the built-in predicate
callable/1
.
- character code
- An integer that is the numeric representation of a character in the
character code set.
- character code set
- A subset of the set {0, ..., 2^31-1} that can be handled in
input/output. SICStus Prolog fixes the character code set to a
superset of Unicode, which includes the ASCII code set, i.e. codes
0..127, and these codes are interpreted as ASCII characters
- character-conversion mapping
- SICStus Prolog maintains a character-conversion mapping, which is
used while reading terms and programs. Initially, the
mapping prescribes no character conversions. It can be modified by the
built-in predicate
char_conversion(
In,
Out)
,
following which In will be converted to Out. Character
coversion can be switched off by the char_conversion
Prolog flag.
- character-type mapping
- A function mapping each element of the character code set to one
of the character categories (layout, letter, symbol-char, etc.),
required for parsing tokens.
- choicepoints
- A memory block representing outstanding choices for some goals or
disjunctions.
- clause
- A fact or a rule.  A fact consists of a head only, and is
equivalent to a rule with the body
true
.
- code-list
- A code-list is a list of character codes.
- compactcode
- Virtual code representation of compiled code. A reasonable
compromise between performance and space requirement. A valid value for
the
compiling
Prolog flag.
- compile
- To load a program (or a portion thereof) into Prolog through
the compiler. Compiled code runs more quickly than
interpreted code, but you cannot debug compiled code in as
much detail as interpreted code.
- compound term
- A compound term is a term that is an atom together
with one or more arguments. For example, in the term
father(X)
, father
is the name, and X
is the first
and only argument. The argument to a compound term
can be another compound term, as in father(father(X))
.
Compound terms are recognized by the built-in predicate
compound/1
.
- conjunction
- A series of goals connected by the connective “and” (that is, a
series of goals whose principal operator is `,').
- console-based executable
- An executable that inherits the standard streams from the process
that invoked it, e.g. a UNIX shell or a DOS-prompt.
- constant
- An integer (for example: 1, 20, -10), a floating-point number (for
example: 12.35), or an atom. Constants are recognized by
the built-in predicate
atomic/1
.
- consult
- To load a program (or a portion thereof) into Prolog through
the interpreter. Interpreted code runs more slowly than
compiled code, but you can debug interpreted code in more
detail than compiled code.
- control structure
- A built-in predicate that is “part of the language” in the sense
that it is treated specially in certain language features. The set of
such control structures and language features is enuemrated in
ref-sem-ctr.
- creep
- What the debugger does in trace mode, also known as
single-stepping. It goes to the next port of a procedure
box and prints the goal, then prompts you for input. See Basic Debug.
- cursor
- The point on the screen at which typed characters appear. This is
usually highlighted by a line or rectangle the size of one space, which
may or may not blink.
- cut
- Written as
!
. A built-in predicate that succeeds when
encountered; if backtracking should later return to the cut,
the goal that matched the head of the clause
containing the cut fails immediately.
- database
- The Prolog database comprises all of the clauses that have
been loaded or asserted into the Prolog system or that have been
asserted, except those clauses that have been retracted or
abolished.
- db_reference
- A compound term denoting a unique reference to a dynamic
clause.
- debug
- A mode of program execution in which the debugger stops to print
the current goal only at predicates that have
spypoints set on them (see leap).
- debugcode
- Interpreted representation of compiled code. A valid value
for the
compiling
Prolog flag.
- declaration
- A declaration looks like a directive, but is not executed
but rather conveys information about predicates about to be loaded.
- deinit function
- A function in a foreign resource that is called prior to unloading
the resource.
- determinate
- A predicate is determinate if it can supply only one answer.
- development system
- A stand-alone executable with the full programming environment,
including top-level, compiler, debugger etc. The default
sicstus
executable is a development system; new
development systems containing pre-linked foreign resources
can also be created.
- directive
- A directive is a goal preceded by the prefix operator
`:-', whose intuitive meaning is “execute this as a query,
but do not print out any variable bindings.”
- disjunction
- A series of goals connected by the connective “or” (that is, a
series of goals whose principal operator is `;').
- dynamic predicate
- A predicate that can be modified while a program is running.
The semantics of such updates is described in ref-mdb-bas.
A predicate must explicitly be declared to be dynamic or it
must be added to the database via one of the assertion
predicates.
- encoded string
- A sequence of bytes representing a sequence of possibly wide character
codes, using the UTF-8 encoding.
- escape sequence
- A sequence of characters beginning with `\' inside certain
syntactic tokens (see ref-syn-syn-esc).
- export
- A module exports a predicate so that other
modules can import it.
- extended runtime system
- A stand-alone executable. In addition to the normal set of
built-in runtime system predicates, extended runtime systems
include the compiler. Extended runtime systems require the
extended runtime library, available from SICS as an add-on product.
- fact
- A clause with no conditions—that is, with an empty
body. A fact is a statement that a relationship exists
between its arguments. Some examples, with possible
interpretations, are:
king(louis, france). % Louis was king of France.
have_beaks(birds). % Birds have beaks.
employee(nancy, data_processing, 55000).
% Nancy is an employee in the
% data processing department.
- file specification
- An atom or a compound term denoting the name of a file. The
rules for mapping such terms to absolute file names are described
in ref-fdi.
- floundered query
- A query where all unsolved goals are blocked.
- foreign predicate
- A predicate that is defined in a language other than Prolog, and
explicitly bound to Prolog predicates by the Foreign Language
Interface.
- foreign resource
- A named set of foreign predicates.
- functor
- The functor of a compound term is its name and arity.
For example, the compound term
foo(a,b)
is said to have
“the functor foo
of arity two”, which is generally
written foo/2
.
The functor of a constant is the term itself paired
with zero. For example, the constant nl
is said to have
“the functor nl
of arity zero”, which is generally
written nl/0
.
- garbage collection
- The freeing up of space for computation by making the space occupied by
terms that are no longer available for use by the Prolog system.
- generalized predicate spec
- A generalized predicate spec is a term of one of the
following forms. It is always interpreted wrt. a given module
context:
- Name
- all predicates called Name no matter what arity, where
Name is an atom for a specific name or a variable for
all names, or
- Name/Arity
- the predicate of that name and arity, or
- Name/[Arity,...,Arity]
- the predicates of that name with one of the given arities, or
- Module:Spec
- specifying a particular module Module instead of the default
module, where Module is an atom for a specific
module or a variable for all modules, or
- [Spec,...,Spec]
- the set of all predicates covered by the Specs.
- glue code
- Interface code between the Prolog engine and foreign predicates.
Automatically generated by the foreign language interface as part of
building a linked foreign resource.
- goal
- A simple goal is a predicate call. When called, it will
either succeed or fail.
A compound goal is a formula consisting of simple goals
connected by connectives such as “and” (`,') or “or”
(`;').
A goal typed at the top-level is called a query.
- ground
- A term is ground when it is free of (unbound)
variables. Ground terms are recognized by the
built-in predicate
ground/1
.
- guarded clause
- A clause of the form
Head :- Goals, !, Goals.
- head
- The head of a clause is the single goal, which will be
satisfied if the conditions in the body (if any) are true;
the part of a rule before the `:-' symbol. The head of
a list is the first element of the list.
- extendible predicate
- An extendible predicate is a dynamic, multifile
predicate, to which new clauses can be added by the user.
- hook predicate
- A hook predicate is a predicate that somehow alters or
customizes the behavior of a hookable predicate.
- hookable predicate
- A hookable predicate is a built-in predicate whose behavior
is somehow altered or customized by a hook predicate.
- import
- Exported predicates in a module can be imported
by other modules. Once a predicate has been imported
by a module, it can be called, or exported, as if it were
defined in that module.
There are two kinds of importation: predicate-importation, in which
only specified predicates are imported from a module; and
module-importation, in which all the predicates exported by a module
are imported.
- indexing
- The process of filtering a set of potentially matching clauses of
a predicate given a goal. For interpreted and
compiled code, indexing is done on the principal
functor of the first argument. Indexing is coarse
wrt. large integers and floats.
- init function
- A function in a foreign resource that is called upon loading the
resource.
- initialization
- An initialization is a goal that is executed when the file
in which the initialization is declared is loaded. An
initialization is declared as a directive
:-
initialization
Goal.
- instantiation
- A variable is instantiated if it is bound to a
non-variable term; that is, to an atomic term or a
compound term.
- interpret
- Load a program or set of clauses into Prolog through
the interpreter (also known as consulting).
Interpreted code runs more slowly than compiled code, but
more extensive facilities are available for debugging interpreted
code.
- invocation box
- Same as procedure box.
- large integer
- An integer that is not a small integer.
- layout term
- In the context of handling line number information for source code, a
source term Source gets associated to a layout term
Layout, which is one of the following:
[]
, if no line number information is available for Source.
- If Source is a simple term, Layout is the number of the line where
Source occurs.
- If Source is a compound term, Layout is a list whose head is
the number of the line where the first token of Source occurs,
and whose remaining elements are the layouts of the arguments of
Source.
- leap
- What the debugger does in debug mode. The debugger shows only the
ports of predicates that have spypoints on them. It
then normally prompts you for input, at which time you may leap
again to the next spypoint (see trace).
- leashing
- Determines how frequently the debugger will stop and prompt you for
input when you are tracing. A port at which the debugger
stops is called a “leashed port”.
- linked foreign resource
- A foreign resource that is ready to be installed in an atomic
operation, normally represented as a shared object or DLL.
- list
- A list is written as a set of zero or more terms between
square brackets. If there are no terms in a list, it is
said to be empty, and is written as `[]'. In this first set of
examples, all members of each list are explicitly stated:
[aa, bb,cc] [X, Y] [Name] [[x, y], z]
In the second set of examples, only the first several members of each
list are explicitly stated, while the rest of the list is
represented by a variable on the right-hand side of the “rest
of” operator, `|':
[X | Y] [a, b, c | Y] [[x, y] | Rest]
`|' is also known as the “list constructor.” The first element of
the list to the left of `|' is called the head of the
list. The rest of the list, including the variable
following `|' (which represents a list of any length), is
called the tail of the list.
- load
- To load a Prolog clause or set of clauses, in source
or binary form, from a file or set of files.
- meta-call
- The process of interpreting a callable term as a goal.
This is done e.g. by the built-in predicate
call/1
.
- meta-logical predicate
- A predicate that performs operations that require reasoning about
the current instantiation of terms or decomposing
terms into their constituents. Such operations cannot be
expressed using predicate definitions with a finite number of
clauses.
- meta-predicate
- A meta-predicate is one that calls one or more of its
arguments; more generally, any predicate that needs to
assume some module in order to operate is called a
meta-predicate. Some arguments of a meta-predicate
are subject to module name expansion.
- module
- A module is a set of predicates in a module-file. The
name of a module is an atom. Some predicates in a
module are exported. The default module is
user
.
- module name expansion
- The process by which certain arguments of meta-predicates
get prefixed by the source module. See ref-mod-mne.
- module-file
- A module-file is a file that is headed with a module
declaration of the form:
:- module(ModuleName, ExportedPredList).
which must appear as the first term in the file.
- multifile predicate
- A predicate whose definition is to be spread over more than one
file. Such a predicate must be preceded by an explicit
multifile declaration in all files containing clauses
for it.
- mutable term
- A special form of compound term subject to destructive assignment.
See ref-lte-mut. Mutable terms are recognized by the
built-in predicate
mutable/1
.
- name clash
- A name clash occurs when a module attempts to define or
import a predicate that it has already defined or
imported.
- occurs-check
- A test to ensure that binding a variable does not bind
it to a term where that variable occurs.
- one-char atom
- An atom that consists of a single character.
- operator
- A notational convenience that allows you to express any compound
term in a different format. For example, if
likes
in
| ?- likes(sue, cider).
is declared an infix operator, the query above could be
written:
| ?- sue likes cider.
An operator does not have to be associated with a predicate.
However, certain built-in predicates are declared as
operators. For example,
| ?- =..(X, Y).
can be written as
| ?- X =.. Y.
because =..
has been declared an infix operator.
Those predicates that correspond to built-in operators are
written using infix notation in the list of built-in
predicates at the beginning of the part that contains the reference
pages.
Some built-in operators do not correspond to built-in
predicates; for example, arithmetic operators. See
ref-syn-ops-bop for a list of built-in operators.
- pair
- A compound term K
-
V. Pairs are used by
the built-in predicate keysort/2
and by many library
modules.
- parent
- The parent of the current goal is a goal that, in its
attempt to obtain a successful solution to itself, is calling the
current goal.
- port
- One of the seven key points of interest in the execution of a Prolog
predicate. See Procedure Box for a definition.
- pre-linked foreign resource
- A linked foreign resource that is linked into a stand-alone
executable as part of building the executable.
- precedence
- A number associated with each Prolog operator, which is used to
disambiguate the structure of the term represented by an
expression containing a number of operators. Operators of
lower precedence are applied before those of higher
precedence; the operator with the highest precedence
is considered the principal functor of the expression. To
disambiguate operators of the same precedence, the
associativity type is also necessary. See ref-syn-ops.
- predicate
- A functor that specifies some relationship existing in the problem
domain. For example,
< /2
is a built-in predicate
specifying the relationship of one number being less than another. In
contrast, the functor + /2
is not (normally used as) a
predicate.
A predicate is either built-in or is implemented by a
procedure.
- predicate spec
- A compound term name
/
arity or
module:
name/
arity denoting a predicate.
- procedure
- A set of clauses in which the head of each clause has
the same predicate. For instance, a group of clauses of the
following form:
connects(san_francisco, oakland, bart_train).
connects(san_francisco, fremont, bart_train).
connects(concord, daly_city, bart_train).
is identified as belonging to the predicate connects/3
.
- procedure box
- A way of visualizing the execution of a Prolog procedure, A
procedure box is entered and exited via ports.
- profiledcode
- Virtual code representation of compiled code, instrumented for
profiling. A valid value for the
compiling
Prolog flag.
- profiling
- The process of gathering execution statistics of parts of the
program, essentially counting the times selected program
points have been reached.
- program
- A set of procedures designed to perform a given task.
- PO file
- A PO (Prolog object) file contains a binary representation of a set of
modules, predicates, clauses and directives.
They are portable between different platforms, except between 32-bit and
64-bit platforms. They are created by
save_files/2
,
save_modules/2
, and save_predicates/2
.
- query
- A query is a question put by the user to the Prolog system. A
query is written as a goal followed by a full-stop in
response to the Prolog system prompt. For example,
| ?- father(edward, ralph).
refers to the predicate father/2
. If a query has no
variables in it, the system will respond either `yes' or
`no'. If a query contains variables, the system will
try to find values of those variables for which the query is
true. For example,
| ?- father(edward, X).
X = ralph
After the system has found one answer, the user can direct the system to
look for additional answers to the query by typing ;.
- recursion
- The process in which a running predicate calls itself, presumably
with different arguments and for the purpose of solving some
subset of the original problem.
- region
- The text between the cursor and a previously set mark in an Emacs
buffer.
- rule
- A clause with one or more conditions. For a rule to
be true, all of its conditions must also be true. For example,
has_stiff_neck(ralph) :-
hacker(ralph).
This rule states that if the individual ralph
is a hacker,
he must also have a stiff neck. The constant ralph
is
replaced in
has_stiff_neck(X) :-
hacker(X).
by the variable X
. X
unifies with anything,
so this rule can be used to prove that any hacker has a stiff
neck.
- runtime kernel
- A shared object or DLL containing the SICStus virtual machine and other
runtime support for stand-alone executables.
- runtime system
- A stand-alone executable with a restricted set of built-in
predicates and no top-level. Stand-alone applications containing
debugged Prolog code and destined for end-users are typically packaged
as runtime systems.
- saved-state
- A snapshot of the state of Prolog saved in a file by
save_program/[1,2]
.
- semantics
- The relation between the set of Prolog symbols and their combinations
(as Prolog terms and clauses), and their meanings. Compare
syntax.
- sentence
- A clause or directive.
- side-effect
- A predicate that produces a side-effect is one that has any
effect on the “outside world” (the user's terminal, a file, etc.), or
that changes the Prolog database.
- simple term
- A simple term is a constant or a variable.
Simple terms are recognized by the built-in predicate
simple/1
.
- skeletal goal
- A compound term name
(
arg, ...,
arg)
or
module:
name(
arg, ...,
arg)
denoting a predicate.
- small integer
- An integer in the range
[-2^28,2^28-1]
on 32-bit platforms, or
[-2^60,2^60-1]
on 64-bit platforms.
- source code
- The human-readable, as opposed to the machine-executable, representation
of a program.
- source module
- The module that is the context of a file being loaded. For
module-files, the source module is named in the file's
module declaration. For other files, the source
module is inherited from the context.
- SP_term_ref
- A “handle” object providing an interface from C to Prolog terms.
- spypoint
- A special case of breakpoint, the debugger breakpoint,
intended for interactive debugging. Its simplest form, the plain
spypoint instructs the debugger to stop at all ports of all
invocations of a specified predicate. Conditional spypoints
apply to a single predicate, but are more selective: the user can
supply applicability tests and prescribe the actions to be
carried out by the debugger. A generic spypoint is like a
conditional spypoint, but not restricted to a single
predicate. See Advanced Debugging.
- stand-alone executable
- A binary program that can be invoked from the operating system,
containing the SICStus runtime kernel. A stand-alone
executable is a development system (e.g. the default
sicstus
executable), or a runtime system. Both kinds are
created by the application builder. A stand-alone executable does
not itself contain any Prolog code; all Prolog code must be loaded
upon startup.
- static predicate
- A predicate that can be modified only by being reloaded or by
being abolished. See dynamic predicate.
- steadfast
- A predicate is steadfast if it refuses to give the wrong answer even
when the query has an unexpected form, typically with values supplied
for arguments intended as output.
- stream
- An input/output channel. See ref-iou.
- stream alias
- A name assigned to a stream at the time of opening, which can be
referred to in I/O predicates. Must be an atom. There are
also three predefined aliases for the standard streams:
user_input
, user_output
and user_error
.
- stream object
- A term denoting an open Prolog stream. See ref-iou.
- stream position
- A term representing the current position of a stream. This
position is determined by the current byte, character and line counts
and line position. Standard term comparison on stream
position terms works as expected. When
SP1
and SP2
refer to positions in the same stream, SP1@<SP2
if and
only if SP1
is before SP2
in the stream. You should
not otherwise rely on their internal representation.
- stream property
- A term representing the property of an open Prolog stream. The
possible forms of this term are defined in ref-iou-sfh-bos.
- string
- A special syntactic notation, which, by default, denotes a
code-list, e.g.:
"SICStus"
By setting the Prolog flag double_quotes
, the meaning of
strings can be changed. With an appropriate setting, a
string can be made to denote a char-list, or an atom.
Strings are not a separate data type.
- subterm selector
- A list of argument positions selecting a subterm within a
term (i.e. the subterm can be reached from the term by
successively selecting the argument positions listed in the
selector). Example: within the term
q, (r, s; t)
the
subterm s
is selected by the selector [2, 1, 2]
.
- syntax
- The part of Prolog grammar dealing with the way in which symbols are put
together to form legal Prolog terms. Compare semantics.
- term
- A basic data object in Prolog. A term can be a constant, a
variable, or a compound term.
- trace
- A mode of program execution in which the debugger creeps to
the next port and prints the goal.
- type-in module
- The module that is the context of queries.
- unblocked goal
- A goal that is not blocked.
- unbound
- A variable is unbound if it has not yet been
instantiated.
- unification
- The process of matching a goal with the head of a
clause during the evaluation of a query, or of matching
arbitrary terms with one another during program execution.
The rules governing the unification of terms are:
- Two constants unify with one another if they are identical.
- A variable unifies with a constant or a compound
term. As a result of the unification, the variable is
instantiated to the constant or compound term.
- A variable unifies with another variable. As a result
of the unification, they become the same variable.
- A compound term unifies with another compound term if
they have the same functor and if all of the arguments can
be unified.
- unit clause
- See fact.
- variable
- A logical variable is a name that stands for objects that may or
may not be determined at a specific point in a Prolog program.
When the object for which the variable stands is determined in the
Prolog program, the variable becomes instantiated. A
logical variable may be unified with a constant, a
compound term, or another variable. Variables become
uninstantiated when the predicate they occur in
backtracks past the point at which they were instantiated.
Variables may be written as any sequence of alphanumeric
characters starting with either a capital letter or `_'; e.g.:
X Y Z Name Position _c _305 One_stop
See ref-syn-trm-var.
- volatile
- Predicate property. The clauses of a volatile
predicate are not saved in saved-states.
- windowed executable
- An executable that pops up its own window when run, and that directs the
standard streams to that window.
- zip
- Same as debug mode, except no debugging information is collected
while zipping.


How interesting can it be to be named according to the day of the week you were born?This tradition is carried out in Ghana and the names given are called Akan names.Let me take you throught the process.To know your Akan name follow the following:
You enter the day you were born
the program calculates the day of the week you were born
Depending on your gender outputs an Akan Name will be given to you.


Level One
{{ user.first_name }}, you've completed level one Messi. Congrats! Be sure you're submission was your best attempt.


Main
Pitching
Player Evaluation ID
Enter Player ID
Velocity (mph)
Accuracy (# Strikes)
2
Mechanics
5
Willing to Catch
No
Player ID Missing or Not Valid
Pitching Velocity Required
Save Player