Version 2; implemented in xboard/WinBoard 4.2.1 and later. (Sept 3, 2009)
Changes since version 1 are indicated in red.
Changes for WinBoard 4.3.xx are indicated in green.
Changes for WinBoard 4.4.xx are indicated in blue.
This document is a set of rough notes on the protocol that xboard and WinBoard use to communicate with gnuchessx and other chess engines. These notes may be useful if you want to connect a different chess engine to xboard. Throughout the notes, "xboard" means both xboard and WinBoard except where they are specifically contrasted.
There are two reasons I can imagine someone wanting to do this:
In case (2), if you are using xboard, you will need to configure the "Zippy" code into it, but WinBoard includes this code already. See the file zippy.README in the xboard or WinBoard distribution for more information.
These notes are unpolished, but I've attempted to make them complete in this release. If you notice any errors, omissions, or misleading statements, let me know.
I'd like to hear from everyone who is trying to interface their own chess engine to xboard/WinBoard. Please join the mailing list for authors of xboard/WinBoard compatible chess engines and post a message about what you're doing. The list is now hosted by Yahoo Groups; you can join at http://groups.yahoo.com/group/chess-engines, or you can read the list there without joining. The list is filtered to prevent spam.
Note that the WinBoard 4.3.xx line was developed independently of the original GNU project, by H.G.Muller. If you have questions about WinBoard 4.3.xx, or want to report bugs in it, report them in the appropriate section of the WinBoard forum.
An xboard chess engine runs as a separate process from xboard itself, connected to xboard through a pair of anonymous pipes. The engine does not have to do anything special to set up these pipes. xboard sets up the pipes itself and starts the engine with one pipe as its standard input and the other as its standard output. The engine then reads commands from its standard input and writes responses to its standard output. This is, unfortunately, a little more complicated to do right than it sounds; see section 6 below.
And yes, contrary to some people's expectations, exactly the same thing is true for WinBoard. Pipes and standard input/output are implemented in Win32 and work fine. You don't have to use DDE, COM, DLLs, BSOD, or any of the other infinite complexity that Microsoft has created just to talk between two programs. A WinBoard chess engine is a Win32 console program that simply reads from its standard input and writes to its standard output. See sections 5 and 6 below for additional details.
To diagnose problems in your engine's interaction with xboard, use the -debug flag on xboard's command line to see the messages that are being exchanged. In WinBoard, these messages are written to the file WinBoard.debug instead of going to the screen.
You can turn debug mode on or off while WinBoard is running by pressing Ctrl+Alt+F12. You can turn debug mode on or off while xboard is running by binding DebugProc to a shortcut key (and pressing the key!); see the instructions on shortcut keys in the xboard man page.
While your engine is running under xboard/WinBoard, you can send a command directly to the engine by pressing Shift+1 (xboard) or Alt+1 (WinBoard 4.0.3 and later). This brings up a dialog that you can type your command into. Press Shift+2 (Alt+2) instead to send to the second chess engine in Two Machines mode. On WinBoard 4.0.2 and earlier, Ctrl+Alt is used in place of Alt; this had to be changed due to a conflict with typing the @-sign on some European keyboards.
Originally, xboard was just trying to talk to the existing command-line interface of GNU Chess 3.1+ and 4, which was designed for people to type commands to. So the communication protocol is very ad-hoc. It might have been good to redesign it early on, but because xboard and GNU Chess are separate programs, I didn't want to force people to upgrade them together to versions that matched. I particularly wanted to keep new versions of xboard working with old versions of GNU Chess, to make it easier to compare the play of old and new gnuchess versions. I didn't foresee the need for a clean protocol to be used with other chess engines in the future.
Circumstances have changed over the years, and now there are many more engines that work with xboard. I've had to make the protocol description more precise, I've added some features that GNU Chess does not support, and I've specified the standard semantics of a few features to be slightly different from what GNU Chess 4 does.
This release of the protocol specification is the first to carry a version number of its own -- version 2. Previous releases simply carried a last-modified date and were loosely tied to specific releases of xboard and WinBoard. The version number "1" applies generally to all those older versions of the protocol.
Protocol version 2 remains compatible with older engines but has several new capabilities. In particular, it adds the "feature" command, a new mechanism for making backward-compatible changes and extensions to the protocol. Engines that do not support a particular new feature do not have to use it; new features are not enabled unless the engine specifically requests them using the feature command. If an engine does not send the feature command at all, the protocol behavior is nearly identical to version 1. Several new features can be selected by the feature command in version 2, including the "ping" command (recommended for all engines), the "setboard" command, and many optional parameters. Additional features will probably be added in future versions.
If it is necessary to have a separate name,
it would be best to refer to the protocol including the green additions as version 2f.
I really don't think it is a different protocol from version 2, though.
I just tried to clarify some ambiguities in the original definition,
now that the WinBoard 4.3.xx line has implemented them in a specific way.
The hand-shaking protocol for features as defined in protocol 2 perfectly
allows addition of an occasional new features without any need for stepping up the protocol version number,
and I think refraining from the latter would enormously lower the barrier for actual
implementation of these features in engines.
The two really new things are the engine debug comments, and the "nps" command.
The former merely tries to regulate an extremely common existing pactice
of having engines dump debug messages on WinBoard in an unprotected way,
as usually you get away with that.
Due to some Microsoft brain damage that I don't understand, WinBoard does not work with chess engines that were compiled to use a DOS extender for 32-bit addressing. (Probably not with 16-bit DOS or Windows programs either.) WinBoard works only with engines that are compiled for the Win32 API. You can get a free compiler that targets the Win32 API from http://sources.redhat.com/cygwin/. I think DJGPP 2.x should also work if you use the RSXNTDJ extension, but I haven't tried it. Of course, Microsoft Visual C++ will work. Most likely the other commercial products that support Win32 will work too (Borland, etc.), but I have not tried them. Delphi has been successfully used to write engines for WinBoard; if you want to do this, Tony Werten has donated some sample code that should help you get started.
Beware of using buffered I/O in your chess engine. The C stdio library, C++ streams, and the I/O packages in most other languages use buffering both on input and output. That means two things. First, when your engine tries to write some characters to xboard, the library stashes them in an internal buffer and does not actually write them to the pipe connected to xboard until either the buffer fills up or you call a special library routine asking for it to be flushed. (In C stdio, this routine is named fflush.) Second, when your engine tries to read some characters from xboard, the library does not read just the characters you asked for -- it reads all the characters that are currently available (up to some limit) and stashes any characters you are not yet ready for in an internal buffer. The next time you ask to read, you get the characters from the buffer (if any) before the library tries to read more data from the actual pipe.
Why does this cause problems? First, on the output side, remember that your engine produces output in small quantities (say, a few characters for a move, or a line or two giving the current analysis), and that data always needs to be delivered to xboard/WinBoard for display immediately. If you use buffered output, the data you print will sit in a buffer in your own address space instead of being delivered.
You can usually fix the output buffering problem by asking for the buffering to be turned off. In C stdio, you do this by calling setbuf(stdout, NULL). A more laborious and error-prone method is to carefully call fflush(stdout) after every line you output; I don't recommend this. In C++, you can try cout.setf(ios::unitbuf), which is documented in current editions of "The C++ Programming Language," but not older ones. Another C++ method that might work is cout.rdbuf()->setbuf(NULL, 0). Alternatively, you can carefully call cout.flush() after every line you output; again, I don't recommend this.
Another way to fix the problem is to use unbuffered operating system calls to write directly to the file descriptor for standard output. On Unix, this means write(1, ...) -- see the man page for write(2). On Win32, you can use either the Unix-like _write(1, ...) or Win32 native routines like WriteFile.
Second, on the input side, you are likely to want to poll during your search and stop it if new input has come in. If you implement pondering, you'll need this so that pondering stops when the user makes a move. You should also poll during normal thinking on your move, so that you can implement the "?" (move now) command, and so that you can respond promptly to a "result", "force", or "quit" command if xboard wants to end the game or terminate your engine. Buffered input makes polling more complicated -- when you poll, you must stop your search if there are either characters in the buffer or characters available from the underlying file descriptor.
The most direct way to fix this problem is to use unbuffered operating system calls to read (and poll) the underlying file descriptor directly. On Unix, use read(0, ...) to read from standard input, and use select() to poll it. See the man pages read(2) and select(2). (Don't follow the example of GNU Chess 4 and use the FIONREAD ioctl to poll for input. It is not very portable; that is, it does not exist on all versions of Unix, and is broken on some that do have it.) On Win32, you can use either the Unix-like _read(0, ...) or the native Win32 ReadFile() to read. Unfortunately, under Win32, the function to use for polling is different depending on whether the input device is a pipe, a console, or something else. (More Microsoft brain damage here -- did they never hear of device independence?) For pipes, you can use PeekNamedPipe to poll (even when the pipe is unnamed). For consoles, you can use GetNumberOfConsoleInputEvents. For sockets only, you can use select(). It might be possible to use WaitForSingleObject more generally, but I have not tried it. Some code to do these things can be found in Crafty's utility.c, but I don't guarantee that it's all correct or optimal.
A second way to fix the problem might be to ask your I/O library not to buffer on input. It should then be safe to poll the underlying file descriptor as described above. With C, you can try calling setbuf(stdin, NULL). However, I have never tried this. Also, there could be problems if you use scanf(), at least with certain patterns, because scanf() sometimes needs to read one extra character and "push it back" into the buffer; hence, there is a one-character pushback buffer even if you asked for stdio to be unbuffered. With C++, you can try cin.rdbuf()->setbuf(NULL, 0), but again, I have never tried this.
A third way to fix the problem is to check whether there are characters in the buffer whenever you poll. C I/O libraries generally do not provide any portable way to do this. Under C++, you can use cin.rdbuf()->in_avail(). This method has been reported to work with EXchess. Remember that if there are no characters in the buffer, you still have to poll the underlying file descriptor too, using the method described above.
A fourth way to fix the problem is to use a separate thread to read from stdin. This way works well if you are familiar with thread programming. This thread can be blocked waiting for input to come in at all times, while the main thread of your engine does its thinking. When input arrives, you have the thread put the input into a buffer and set a flag in a global variable. Your search routine then periodically tests the global variable to see if there is input to process, and stops if there is. WinBoard and my Win32 ports of ICC timestamp and FICS timeseal use threads to handle multiple input sources.
Engines that run on Unix need to be concerned with two Unix signals: SIGTERM and SIGINT. This applies both to engines that run under xboard and (the unusual case of) engines that WinBoard remotely runs on a Unix host using the -firstHost or -secondHost feature. It does not apply to engines that run on Windows, because Windows does not have Unix-style signals. Beginning with version 2, you can now turn off the use of either or both signals. See the "feature" command in section 9 below.
First, when an engine is sent the "quit" command, it is also given a SIGTERM signal shortly afterward to make sure it goes away. If your engine reliably responds to "quit", and the signal causes problems for you, you should either ignore it by calling signal(SIGTERM, SIG_IGN) at the start of your program, or disable it with the "feature" command.
Second, xboard will send an interrupt signal (SIGINT) at certain times when it believes the engine may not be listening to user input (thinking or pondering). WinBoard currently does this only when the engine is running remotely using the -firstHost or -secondHost feature, not when it is running locally. You probably need to know only enough about this grungy feature to keep it from getting in your way.
The SIGINTs are basically tailored to the needs of GNU Chess 4 on systems where its input polling code is broken or disabled. Because they work in a rather peculiar way, it is recommended that you either ignore SIGINT by having your engine call signal(SIGINT, SIG_IGN), or disable it with the "feature" command.
Here are details for the curious. If xboard needs to send a command when it is the chess engine's move (such as before the "?" command), it sends a SIGINT first. If xboard needs to send commands when it is not the chess engine's move, but the chess engine may be pondering (thinking on its opponent's time) or analyzing (analysis or analyze file mode), xboard sends a SIGINT before the first such command only. Another SIGINT is not sent until another move is made, even if xboard issues more commands. This behavior is necessary for GNU Chess 4. The first SIGINT stops it from pondering until the next move, but on some systems, GNU Chess 4 will die if it receives a SIGINT when not actually thinking or pondering.
There are two reasons why WinBoard does not send the Win32 equivalent of SIGINT (which is called CTRL_C_EVENT) to local engines. First, the Win32 GNU Chess 4 port does not need it. Second, I could not find a way to get it to work. Win32 seems to be designed under the assumption that only console applications, not windowed applications, would ever want to send a CTRL_C_EVENT.
All commands from xboard to the engine end with a newline (\n), even where that is not explicitly stated. All your output to xboard must be in complete lines; any form of prompt or partial line will cause problems.
At the beginning of each game, xboard sends an initialization string. This is currently "new\nrandom\n" unless the user changes it with the initString or secondInitString option.
xboard normally reuses the same chess engine process for multiple games. At the end of a game, xboard will send the "force" command (see below) to make sure your engine stops thinking about the current position. It will later send the initString again to start a new game. If your engine can't play multiple games, you can disable reuse either with the "feature" command (beginning in protocol version 2; see below) or with xboard's -xreuse (or -xreuse2) command line option. xboard will then ask the process to quit after each game and start a new process for the next game.
Beginning in protocol version 2 (in which N=2), this command will be sent immediately after the "xboard" command. If you receive some other command immediately after "xboard" (such as "new"), you can assume that protocol version 1 is in use. The "protover" command is the only new command that xboard always sends in version 2. All other new commands to the engine are sent only if the engine first enables them with the "feature" command. Protocol versions will always be simple integers so that they can easily be compared.
Your engine should reply to the protover command by sending the "feature" command (see below) with the list of non-default feature settings that you require, if any.
Your engine should never refuse to run due to receiving a higher protocol version number than it is expecting! New protocol versions will always be compatible with older ones by default; the larger version number is simply a hint that additional "feature" command options added in later protocol versions may be accepted.
| wildcastle | Shuffle chess where king can castle from d file |
| nocastle | Shuffle chess with no castling at all |
| fischerandom | Fischer Random |
| bughouse | Bughouse, ICC/FICS rules |
| crazyhouse | Crazyhouse, ICC/FICS rules |
| losers | Win by losing all pieces or getting mated (ICC) |
| suicide | Win by losing all pieces including king, or by having fewer pieces when one player has no legal moves (FICS) |
| giveaway | Win by losing all pieces including king, or by having no legal moves (ICC) |
| twokings | Weird ICC wild 9 |
| kriegspiel | Kriegspiel (engines not supported) |
| atomic | Atomic |
| 3check | Win by giving check 3 times |
| xiangqi | Chinese Chess (9x10 board) |
| shogi | Japanese Chess (9x9 bord) |
| capablanca | Capablanca Chess (10x8 board, with Archbishop and Chancellor) |
| gothic | Gothic Chess (10x8 board, same with better opening setup) |
| falcon | Falcon Chess (10x8 board, with two Falcon pieces) |
| shatranj | ancient Arabic Chess, with Elephants and General in stead of B and Q |
| courier | Courier Chess (12x8 board, a medieval precursor of modern Chess |
| knightmate | King moves as Knight and vice versa |
| berolina | Pawns capture straight ahead, and move diagonally |
| janus | Janus Chess (10x8, with two Archbishops) |
| caparandom | shuffle variant like FRC (10x8 board) |
| cylinder | Pieces wrap around between side edges, like board is a cylinder |
| super | Superchess: a shuffle variant with 4 fairy pieces on 8x8 board |
| great | Great Shatranj: sliders are replaced by corresponding short-range pieces on a 10x8 board |
| unknown | Unknown variant (not supported) |
(This command is obsolete as of protocol version 2, but is still sent in some situations to accommodate older engines unless you disable it with the feature command.) Set White on move. Set the engine to play Black. Stop clocks.
The engine should limit its thinking to DEPTH ply. The commands "level" or "st" and "sd" can be used together in an orthogonal way. If both are issued, the engine should observe both limitations: In the protocol, the "sd" command isn't a time control. It doesn't say that your engine has unlimited time but must search to exactly the given depth. It says that you should pay attention to the time control as normal, but cut off the search at the specified depth even if you have time to search deeper. If you don't have time to search to the specified depth, given your normal time management algorithm, then you will want to stop sooner than the given depth.
The "new" command should set the search depth back to unlimited. This is already stated in the spec. The "level" command should not affect the search depth. As it happens, xboard/WinBoard currently always sends sd (if needed) right after level, but that isn't part of the spec.
Set a clock that always belongs to the opponent. N is a number in centiseconds (units of 1/100 second). Even if the opponent changes to playing the opposite color, this clock remains with the opponent.
If needed for purposes of board display in force mode (where the engine is not participating in the game) the time clock should be associated with the last color that the engine was set to play, the otim clock with the opposite color.
This business of "clocks remaining with the engine" is apparently so ambiguous that many engines implement it wrong. The clocks in fact always remain with the color. Which clock reading is relayed with "time", and which by "otim", is determined by which side the engine plays. Note that the way the clocks operate and receive extra time (in accordance with the selected time control) is not affected in any way by which moves are made by the engine, which by the opponent, and which were forced.
Beginning in protocol version 2, if you can't handle the time and otim commands, you can use the "feature" command to disable them; see below. The following techniques from older protocol versions also work: You can ignore the time and otim commands (that is, treat them as no-ops), or send back "Error (unknown command): time" the first time you see "time".
See below for the syntax of moves. If the move is illegal, print an error message; see the section "Commands from the engine to xboard". If the move is legal and in turn, make it. If not in force mode, stop the opponent's clock, start the engine's clock, start thinking, and eventually make a move.
When xboard sends your engine a move, it normally sends coordinate algebraic notation. Examples:
| Normal moves: | e2e4 |
| Pawn promotion: | e7e8q |
| Castling: | e1g1, e1c1, e8g8, e8c8 |
| Bughouse/crazyhouse drop: | P@h3 |
| ICS Wild 0/1 castling: | d1f1, d1b1, d8f8, d8b8 |
| FischerRandom castling: | O-O, O-O-O (oh, not zero) |
Note that on boards with more than 9 ranks, counting of the ranks starts at 0.
Beginning in protocol version 2, you can use the feature command to select SAN (standard algebraic notation) instead; for example, e4, Nf3, exd5, Bxf7+, Qxf7#, e8=Q, O-O, or P@h3. Note that the last form, P@h3, is a extension to the PGN standard's definition of SAN, which does not support bughouse or crazyhouse.
xboard doesn't reliably detect illegal moves, because it does not keep track of castling unavailability due to king or rook moves, or en passant availability. If xboard sends an illegal move, send back an error message so that xboard can retract it and inform the user; see the section "Commands from the engine to xboard".
Move now. If your engine is thinking, it should move immediately; otherwise, the command should be ignored (treated as a no-op). It is permissible for your engine to always ignore the ? command. The only bad consequence is that xboard's Move Now menu command will do nothing.
It is also permissible for your engine to move immediately if it gets any command while thinking, as long as it processes the command right after moving, but it's preferable if you don't do this. For example, xboard may send post, nopost, easy, hard, force, quit, or other commands while the engine is on move.
In this command, N is a decimal number. When you receive the command, reply by sending the string pong N, where N is the same number you received. Important: You must not reply to a "ping" command until you have finished executing all commands that you received before it. Pondering does not count; if you receive a ping while pondering, you should reply immediately and continue pondering. Because of the way xboard uses the ping command, if you implement the other commands in this protocol, you should never see a "ping" command when it is your move; however, if you do, you must not send the "pong" reply to xboard until after you send your move. For example, xboard may send "?" immediately followed by "ping". If you implement the "?" command, you will have moved by the time you see the subsequent ping command. Similarly, xboard may send a sequence like "force", "new", "ping". You must not send the pong response until after you have finished executing the "new" command and are ready for the new game to start.
The ping command is new in protocol version 2 and will not be sent unless you enable it with the "feature" command. Its purpose is to allow several race conditions that could occur in previous versions of the protocol to be fixed, so it is highly recommended that you implement it. It is especially important in simple engines that do not ponder and do not poll for input while thinking, but it is needed in all engines.
result 1-0 {White mates}
Here are some notes on interpreting the "result" command. Some apply only to playing on ICS ("Zippy" mode).
If you won but did not just play a mate, your opponent must have resigned or forfeited. If you lost but were not just mated, you probably forfeited on time, or perhaps the operator resigned manually. If there was a draw for some nonobvious reason, perhaps your opponent called your flag when he had insufficient mating material (or vice versa), or perhaps the operator agreed to a draw manually.
You will get a result command even if you already know the game ended -- for example, after you just checkmated your opponent. In fact, if you send the "RESULT {COMMENT}" command (discussed below), you will simply get the same thing fed back to you with "result" tacked in front. You might not always get a "result *" command, however. In particular, you won't get one in local chess engine mode when the user stops playing by selecting Reset, Edit Game, Exit or the like.
The setboard command is the new way to set up positions, beginning in protocol version 2. It is not used unless it has been selected with the feature command. Here FEN is a position in Forsythe-Edwards Notation, as defined in the PGN standard. Note that this PGN standard referred to here only applies to normal Chess; Obviously in variants that cannot be described by a FEN for normal Chess, e.g. because the board is not 8x8, other pieces then PNBRQK participate, there are holdings that need to be specified, etc., xboard will use a FEN format that is standard or suitable for that varant. In particular, in FRC or CRC, WinBoard will use Shredder-FEN or X-FEN standard, i.e. it can use the rook-file indicator letter to represent a castling right (like HAha) whenever it wants, but if it uses KQkq, this will always refer to the outermost rook on the given side.
Illegal positions: Note that either setboard or edit can be used to send an illegal position to the engine. The user can create any position with xboard's Edit Position command (even, say, an empty board, or a board with 64 white kings and no black ones). If your engine receives a position that it considers illegal, I suggest that you send the response "tellusererror Illegal position", and then respond to any attempted move with "Illegal move" until the next new, edit, or setboard command.
The edit command is the old way to set up positions. For compatibility with old engines, it is still used by default, but new engines may prefer to use the feature command (see below) to cause xboard to use setboard instead. The edit command puts the chess engine into a special mode, where it accepts the following subcommands:
| c | change current piece color, initially white |
| Pa4 (for example) | place pawn of current color on a4 |
| xa4 (for example) | empty the square a4 (not used by xboard) |
| # | clear board |
| . | leave edit mode |
See the Idioms section below for additional subcommands used in ChessBase's implementation of the protocol.
The edit command does not change the side to move. To set up a black-on-move position, xboard uses the following command sequence:
new force a2a3 edit <edit commands> .
This sequence is used to avoid the "black" command, which is now considered obsolete and which many engines never did implement as specified in this document.
After an edit command is complete, if a king and a rook are on their home squares, castling is assumed to be available to them. En passant capture is assumed to be illegal on the current move regardless of the positions of the pawns. The clock for the 50 move rule starts at zero, and for purposes of the draw by repetition rule, no prior positions are deemed to have occurred. In FRC or CRC, any rook and king put on the back rank should be considered to have castling rights, even if it later becomes apparent that they cannot be both in the initial position, because the position just set up is asymmetric. It is upto WinBoard to find work-around in cases where this is not desired, similar to the "black kludge" shown above, by setting up an earlier position, and then do a move to destroy castling rights or create e.p. rights. (Don't bet your life on it...)
rating 2600 1500
xboard now supports bughouse engines when in Zippy mode. See zippy.README for information on Zippy mode and how to turn on the bughouse support. The bughouse move format is given above. xboard sends the following additional commands to the engine when in bughouse mode. Commands to inform your engine of the partner's game state may be added in the future.
partner mann
holding [PPPRQ] []
holding [PPPRQ] [R] BR
In general, an engine should not send any output to xboard that is not described in this document. As the protocol is extended, newer versions of xboard may recognize additional strings as commands that were previously not assigned a meaning.
Beginning with version 2, the protocol includes the "feature" command, which lets your engine control certain optional protocol features. Feature settings are written as FEATURE=VALUE, where FEATURE is a name from the list below and VALUE is the value to be assigned. Features can take string, integer, or boolean values; the type of value is listed for each feature. String values are written in double quotes (for example, feature myname="Miracle Chess 0.9"), integers are written in decimal, and boolean values are written as 0 for false, 1 for true. Any number of features can be set in one feature command, or multiple feature commands can be given.
Your engine should send one or more feature commands immediately after receiving the "protover" command, since xboard needs to know the values of some features before sending further commands to the engine. Because engines that predate protocol version 2 do not send "feature", xboard uses a timeout mechanism: when it first starts your engine, it sends "xboard" and "protover N", then listens for feature commands for two seconds before sending any other commands. To end this timeout and avoid the wait, set the feature "done=1" at the end of your last feature command. To increase the timeout, if needed, set the feature "done=0" before your first feature command and "done=1" at the end. If needed, it is okay for your engine to set done=0 soon as it starts, even before it receives the xboard and protover commands. This can be useful if your engine takes a long time to initialize itself. It should be harmless even if you are talking to a (version 1) user interface that does not understand the "feature" command, since such interfaces generally ignore commands from the engine that they do not understand.
The feature command is designed to let the protocol change without breaking engines that were written for older protocol versions. When a new feature is added to the protocol, its default value is always chosen to be compatible with older versions of the protocol that did not have the feature. Any feature that your engine does not set in a "feature" command retains its default value, so as the protocol changes, you do not have to change your engine to keep up with it unless you want to take advantage of a new feature. Because some features are improvements to the protocol, while others are meant to cater to engines that do not implement all the protocol features, the recommended setting for a feature is not always the same as the default setting. The listing below gives both default and recommended settings for most features.
You may want to code your engine so as to be able to work with multiple versions of the engine protocol. Protocol version 1 does not send the protover command and does not implement the feature command; if you send a feature command in protocol version 1, it will have no effect and there will be no response. In protocol version 2 or later, each feature F that you set generates the response "accepted F" if the feature is implemented, or "rejected F" if it is not. Thus an engine author can request any feature without having to keep track of which protocol version it was introduced in; you need only check whether the feature is accepted or rejected. This mechanism also makes it possible for a user interface author to implement a subset of a protocol version by rejecting some features that are defined in that version; however, you should realize that engine authors are likely to code for xboard and may not be prepared to have a feature that they depend on be rejected. If the GUI rejects an option feature because of the syntax of the value, it should print the value string with the "rejected" command, e.g. "rejected option nonsense" in response to receiving feature option="nonsense".
Here are the features that are currently defined.
Illegal move: e2e4 Illegal move (in check): Nf3 Illegal move (moving into check): e1g1
Generally, xboard will never send an ambiguous move, so it does not matter whether you respond to such a move with an Illegal move message or an Error message.
Error (ambiguous move): Nf3 Error (unknown command): analyze Error (command not legal now): undo Error (too many parameters): level 1 2 3 4 5 6 7
setup (PN.RQKpn.rqk) 6x6+0_fairy rnqknr/pppppp/6/6/PPPPPP/RNQKNR w - - 0 1could be used by an engine for Los-Alamos Chess in response to 'variant losalamos', and would automatically switch the GUI to this variant as soon as the user selected it from the GUI menu. The PIECETOCHAR element would ensure a Bishop would not be accepted as promotion choice.
For the actual move text from your chess engine (in place of MOVE above), your move should be either
xboard itself also accepts some variants of SAN, but for compatibility with non-xboard interfaces, it is best not to rely on this behavior.
Warning: Even though all versions of this protocol specification have indicated that xboard accepts SAN moves, some non-xboard interfaces are known to accept only coordinate notation. See the Idioms section for more information on the known limitations of some non-xboard interfaces. It should be safe to send SAN moves if you receive a "protover 2" (or later) command from the interface, but otherwise it is best to stick to coordinate notation for maximum compatibility. An even more conservative approach would be for your engine to send SAN to the interface only if you have set feature san=1 (which causes the interface to send SAN to you) and have received "accepted san" in reply.
0-1 {Black mates} 1-0 {White mates} 1/2-1/2 {Draw by repetition} 1/2-1/2 {Stalemate}
xboard relays the result to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. Note that "definitey over" above means that sending this command will be taken by WinBoard as an unconditional refusal of the engine to play on, which might cause you to forfeit if the game was in fact not over. This command should thus not be used to offer draws, accept draws, or make draw-by-rule claims that are not yet valid in the current position (but will be after you move). For offering and claiming such draws, "offer draw" should be used.
Note that (in accordance with FIDE rules) only KK, KNK, KBK and KBKB with all bishops on the same color can be claimed as draws on the basis of insufficient mating material. The end-games KNNK, KBKN, KNKN and KBKB with unlike bishops do have mate positions, and cannot be claimed. Complex draws based on locked Pawn chains will not be recognized as draws by most interfaces, so do not claim in such positions, but just offer a draw or play on.
Note to GUI programmers: RESULT commands that the engine sends immediately after its move might be detected by the GUI only after the opponent has moved, because of communication and scheduling delays, no matter how fast the engine sent it. Any judgement of the validity of RESULT claims based on te "current" board position will have to account for this uncertainty.
If the user asks your engine to "show thinking", xboard sends your engine the "post" command. It sends "nopost" to turn thinking off. In post mode, your engine sends output lines to show the progress of its thinking. The engine can send as many or few of these lines as it wants to, whenever it wants to. Typically they would be sent when the PV (principal variation) changes or the depth changes. The thinking output should be in the following format:
ply score time nodes pv
Where:
| ply | Integer giving current search depth. |
| score | Integer giving current evaluation in centipawns. |
| time | Current search time in centiseconds (ex:1028 = 10.28 seconds). |
| nodes | Nodes searched. |
| pv | Freeform text giving current "best" line. You can continue the pv onto another line if you start each continuation line with at least four space characters. |
Example:
9 156 1084 48000 Nf3 Nc6 Nc3 Nf6
Meaning:
9 ply, score=1.56, time = 10.84 seconds, nodes=48000, PV = "Nf3 Nc6 Nc3 Nf6"
Longer example from actual Crafty output:
4 109 14 1435 1. e4 d5 2. Qf3 dxe4 3. Qxe4 Nc6 4 116 23 2252 1. Nf3 Nc6 2. e4 e6 4 116 27 2589 1. Nf3 Nc6 2. e4 e6 5 141 44 4539 1. Nf3 Nc6 2. O-O e5 3. e4 5 141 54 5568 1. Nf3 Nc6 2. O-O e5 3. e4
You can use the PV to show other things; for instance, while in book, Crafty shows the observed frequency of different reply moves in its book. In situations like this where your engine is not really searching, start the PV with a '(' character:
0 0 0 0 (e4 64%, d4 24%)
GNU Chess output is very slightly different. The ply number is followed by an extra nonblank character, and the time is in seconds, not hundredths of seconds. For compatibility, xboard accepts the extra character and takes it as a flag indicating the different time units. Example:
2. 14 0 38 d1d2 e8e7 3+ 78 0 65 d1d2 e8e7 d2d3 3& 14 0 89 d1d2 e8e7 d2d3 3& 76 0 191 d1e2 e8e7 e2e3 3. 76 0 215 d1e2 e8e7 e2e3 4& 15 0 366 d1e2 e8e7 e2e3 e7e6 4. 15 0 515 d1e2 e8e7 e2e3 e7e6 5+ 74 0 702 d1e2 f7f5 e2e3 e8e7 e3f4 5& 71 0 1085 d1e2 e8e7 e2e3 e7e6 e3f4 5. 71 0 1669 d1e2 e8e7 e2e3 e7e6 e3f4 6& 48 0 3035 d1e2 e8e7 e2e3 e7e6 e3e4 f7f5 e4d4 6. 48 0 3720 d1e2 e8e7 e2e3 e7e6 e3e4 f7f5 e4d4 7& 48 0 6381 d1e2 e8e7 e2e3 e7e6 e3e4 f7f5 e4d4 7. 48 0 10056 d1e2 e8e7 e2e3 e7e6 e3e4 f7f5 e4d4 8& 66 1 20536 d1e2 e8e7 e2e3 e7e6 e3d4 g7g5 a2a4 f7f5 8. 66 1 24387 d1e2 e8e7 e2e3 e7e6 e3d4 g7g5 a2a4 f7f5 9& 62 2 38886 d1e2 e8e7 e2e3 e7e6 e3d4 h7h5 a2a4 h5h4 d4e4 9. 62 4 72578 d1e2 e8e7 e2e3 e7e6 e3d4 h7h5 a2a4 h5h4 d4e4 10& 34 7 135944 d1e2 e8e7 e2e3 e7e6 e3d4 h7h5 c2c4 h5h4 d4e4 f7f5 e4f4 10. 34 9 173474 d1e2 e8e7 e2e3 e7e6 e3d4 h7h5 c2c4 h5h4 d4e4 f7f5 e4f4
If your engine is pondering (thinking on its opponent's time) in post mode, it can show its thinking then too. In this case your engine may omit the hint move (the move it is assuming its opponent will make) from the thinking lines if and only if it sends xboard the move in the usual "Hint: xxx" format before sending the first line.
xboard supports three styles of time control: conventional chess clocks, the ICS-style incremental clock, and an exact number of seconds per move.
In conventional clock mode, every time control period is the same. That is, if the time control is 40 moves in 5 minutes, then after each side has made 40 moves, they each get an additional 5 minutes, and so on, ad infinitum. At some future time it would be nice to support a series of distinct time controls. This is very low on my personal priority list, but code donations to the xboard project are accepted, so feel free to take a swing at it. I suggest you talk to me first, though.
The command to set a conventional time control looks like this:
level 40 5 0 level 40 0:30 0
The 40 means that there are 40 moves per time control. The 5 means there are 5 minutes in the control. In the second example, the 0:30 means there are 30 seconds. The final 0 means that we are in conventional clock mode.
Note that the time parameter in this command is not a pure numeric argument, but in general is a character string, in order to pass the number of seconds. Engines are encouraged to ignore any unexpected characters at the end of this string, i.e. following the MIN or MIN:SEC specification. Future protocol versions might (under control of an appropriate feature) append such extra characters to this argument, in order to inform the engine in advance of the time control it can expect after the current session completes. E.g. "level 40 25+5 0" could mean that the engine has to play 40 moves in 25 minutes, but should expect to get only 5 minutes for the entire remainder of the game after that, rather than another 25 minutes for the next 40 moves. When the time comes, (i.e. after the 40 moves), it will be informed of the time-control change by receiving a new "level 0 5 0" command, but engines with advanced time management might want to plan for this in advance.
The command to set an incremental time control looks like this:
level 0 2 12
Here the 0 means "play the whole game in this time control period", the 2 means "base=2 minutes", and the 12 means "inc=12 seconds". As in conventional clock mode, the second argument to level can be in minutes and seconds.
At the start of the game, each player's clock is set to base minutes. Immediately after a player makes a move, inc seconds are added to his clock. A player's clock counts down while it is his turn. Your flag can be called whenever your clock is zero or negative. (Your clock can go negative and then become positive again because of the increment.)
The number of moves given in the level command (when non-zero) should be taken as the number of moves still to do before the specified time will be added to the clock, if the "level" command is received after some moves have already been played. The time given should be interpreted as the time left on its clock (including any time left over from the previous sessions), and not necessarily the time that will be added to the clock after the specified number of moves has been played. This is only relevant in WinBoard 4.3.xx, which might send the engine "level" commands during a game, just before the engine has to start thinking about the first move of a new time-control session. Example: if at the start of the game "level 40 60 0" was given (40 moves per hour), and the engine receives "level 20 22 0" just before move 41, it should understand that it should do the next 20 moves in 22 minutes (pehaps because the secondary session was 20 moves per 15 minutes, and it had 7 minutes left on its clock after the first 40 moves).
A special rule on some ICS implementations: if you ask for a game with base=0, the clocks really start at 10 seconds instead of 0. xboard itself does not know about this rule, so it passes the 0 on to the engine instead of changing it to 0:10.
ICS also has time odds games. With time odds, each player has his own (base, inc) pair, but otherwise things work the same as in normal games. The Zippy xboard accepts time odds games but ignores the fact that the opponent's parameters are different; this is perhaps not quite the right thing to do, but gnuchess doesn't understand time odds. Time odds games are always unrated.
The command to set an exact number of seconds per move looks like this:
st 30
This means that each move must be made in at most 30 seconds. Time not used on one move does not accumulate for use on later moves.
xboard supports analyzing fresh games, edited positions, and games from files. However, all of these look the same from the chess engine's perspective. Basically, the engine just has to respond to the "analyze" command. Beginning in protocol version 2, if your engine does not support analyze mode, it should use the feature command to set analyze=0. The older method of printing the error message "Error (unknown command): analyze" in response to the "analyze" command will also work, however.
To enter analyze mode, xboard sends the command sequence "post", "analyze". Analyze mode in your engine should be similar to force mode, except that your engine thinks about what move it would make next if it were on move. Your engine should accept the following commands while in analyze mode:
If the user selects "Periodic Updates", xboard will send the string ".\n" to the chess engine periodically during analyze mode, unless the last PV received began with a '(' character.
The chess engine should respond to ".\n" with a line like this:
stat01: time nodes ply mvleft mvtot mvname
Where:
| time | Elapsed search time in centiseconds (ie: 567 = 5.67 seconds). |
| nodes | Nodes searched so far. |
| ply | Search depth so far. |
| mvleft | Number of moves left to consider at this depth. |
| mvtot | Total number of moves to consider. |
| mvname | Move currently being considered (SAN or coordinate notation). Optional; added in protocol version 2. |
Examples:
stat01: 1234 30000 7 5 30 stat01: 1234 30000 7 5 30 Nf3
Meaning:
After 12.34 seconds, I've searched 7 ply/30000 nodes, there are a total of 30 legal moves, and I have 5 more moves to search before going to depth 8. In the second example, of the 30 legal moves, the one I am currently searching is Nf3.
Implementation of the "." command is optional. If the engine does not respond to the "." command with a "stat01..." line, xboard will stop sending "." commands. If the engine does not implement this command, the analysis window will use a shortened format to display the engine info.
To give the user some extra information, the chess engine can output the strings "++\n" and "--\n", to indicate that the current search is failing high or low, respectively. You don't have to send anything else to say "Okay, I'm not failing high/low anymore." xboard will figure this out itself.
Some engines have variant interpretations of the force/go/white/black, time/otim, and hard/easy command sets. In order to accommodate these older engines, xboard uses these commands only according to the stylized patterns ("idioms") given in this section. The obsolete white and black commands have historically been particularly troublesome, and it is recommended that new engines set the feature colors=0 and/or ignore the commands.
To support older engines, certain additional commands from the engine to xboard are also recognized. (These are commands by themselves, not values to be placed in the comment field of the PGN result code.) These forms are not recommended for new engines; use the PGN result code commands or the resign command instead.
| Command | Interpreted as |
|---|---|
| White resigns | 0-1 {White resigns} |
| Black resigns | 1-0 {Black resigns} |
| White | 1-0 {White mates} |
| Black | 0-1 {Black mates} |
| Draw | 1/2-1/2 {Draw} |
| computer mates | 1-0 {White mates} or 0-1 {Black mates} |
| opponent mates | 1-0 {White mates} or 0-1 {Black mates} |
| computer resigns | 0-1 {White resigns} or 1-0 {Black resigns} |
| game is a draw | 1/2-1/2 {Draw} |
| checkmate | 1-0 {White mates} or 0-1 {Black mates} |
Commands in the above table are recognized if they begin a line and arbitrary characters follow, so (for example) "White mates" will be recognized as "White", and "game is a draw by the 50 move rule" will be recognized as "game is a draw". All the commands are case-sensitive.
An alternative move syntax is also recognized:
| Command | Interpreted as |
|---|---|
| NUMBER ... MOVE | move MOVE |
Here NUMBER means any string of decimal digits, optionally ending in a period. MOVE is any string containing no whitespace. In this command format, xboard requires the "..." even if your engine is playing White. A command of the form NUMBER MOVE will be ignored. This odd treatment of the commands is needed for compatibility with gnuchessx. The original reasons for it are lost in the mists of time, but I suspect it was originally a bug in the earliest versions of xboard, before I started working on it, which someone "fixed" in the wrong way, by creating a special version of gnuchess (gnuchessx) instead of changing xboard.
Any line that contains the words "offer" and "draw" is recognized as "offer draw".
The "Illegal move" message is recognized even if spelled "illegal move" and even if the colon (":") is omitted. This accommodates GNU Chess 4, which prints messages like "Illegal move (no matching move)e2e4", and old versions of Crafty, which print just "illegal move".
In Zippy mode, for compatibility with older versions of Crafty, xboard passes through to ICS any line that begins "kibitz", "whisper", "tell", or "draw". Do not use this feature in new code. Instead, use the commands "tellall", "tellothers", "tellopponent", "tellics" (if needed), "1/2-1/2 {COMMENT}", or "offer draw", as appropriate.
If the engine responds to the "sd DEPTH" command with an error message indicating the command is not supported (such as "Illegal move: sd"), xboard sets an internal flag and subsequently uses the command "depth\nDEPTH" instead, for the benefit of GNU Chess 4. Note the newline in the middle of this command! New engines should not rely on this feature.
If the engine responds to the "st TIME" command with an error message indicating the command is not supported (such as "Illegal move: st"), xboard sets an internal flag and subsequently uses the command "level 1 TIME" instead, for the benefit of GNU Chess 4. Note that this is not a standard use of the level command, as TIME seconds are not added after each player makes 1 move; rather, each move is made in at most TIME seconds. New engines should not implement or rely on this feature.
In support of the -firstHost/-secondHost features, which allow a chess engine to be run on another machine using the rsh protocol, xboard recognizes error messages that are likely to come from rsh as fatal errors. The following messages are currently recognized:
ChessBase/Fritz now implements the xboard/winboard protocol and can use WinBoard-compatible engines in its GUI. ChessBase's version of the protocol is generally the same as version 1, except that they have added the commands fritz, reset, and ponder, and the edit subcommands castle and ep. If you want your engine to work well with the ChessBase/Fritz GUI, you may need to implement these additional commands, and you should also be aware of the peculiar way that ChessBase uses the protocol. See their web page for documentation.
ChessMaster 8000 also implements version 1 of the xboard/winboard protocol and can use WinBoard-compatible engines. The original release of CM8000 also has one additional restriction: only pure coordinate notation (e.g., e2e4) is accepted in the move command. A patch to correct this should be available from The Learning Company (makers of CM8000) in February 2001.


Toggle navigation
Sample Dashboard
Chat
Call
Search
Counter
Sale Service Doughnut
Sales
Services
Line Chart
Top 10 Employees
Top 10 Chat Drivers
Map
Day Hour Heat Map
Bubble Chart
Word Cloud


I am trying to find some way to relate column types across the the most used Databases: MySQL, PostgreSQL, and SQLite.
Here is what I have so far, but I'm afraid it's not done and I need some people with more experience to help me finish any missing types.
MySQL PostgreSQL SQLite
TINYINT SMALLINT INTEGER
SMALLINT SMALLINT
MEDIUMINT INTEGER
BIGINT BIGINT
BIT BIT INTEGER
_______________________________________________________
TINYINT UNSIGNED SMALLINT INTEGER
SMALLINT UNSIGNED INTEGER
MEDIUMINT UNSIGNED INTEGER
INT UNSIGNED BIGINT
BIGINT UNSIGNED NUMERIC(20)
_______________________________________________________
DOUBLE DOUBLE PRECISION REAL
FLOAT REAL REAL
DECIMAL DECIMAL REAL
NUMERIC NUMERIC REAL
_______________________________________________________
BOOLEAN BOOLEAN INTEGER
_______________________________________________________
DATE DATE TEXT
TIME TIME
DATETIME TIMESTAMP
_______________________________________________________
TIMESTAMP DEFAULT TIMESTAMP DEFAULT TEXT
NOW() NOW()
_______________________________________________________
LONGTEXT TEXT TEXT
MEDIUMTEXT TEXT TEXT
BLOB BYTEA BLOB
VARCHAR VARCHAR TEXT
CHAR CHAR TEXT
_______________________________________________________
columnname INT columnname SERIAL INTEGER PRIMARY
AUTO_INCREMENT KEY AUTOINCREMENT
CREATE TABLE
definitions between these three types. Since they are in use often I find that open source code needs to be ready for any of them. – Xeoncross Dec 21 '09 at 22:02


|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Object edu.biu.scapi.circuits.garbledCircuit.IdentityGate
public class IdentityGate
The identity gates are used in the extended circuit. There are cases when the user want to set the input and/or output keys (which are the garbled values of 0/1 for each wire). In that cases, the extended circuit adds to the composed circuit identity gates for each input and output wires. This way, if the user gave input keys, there are input identity gates for each input wire w, with input wire indexed -(w+1) and output wire w. If the user gave output keys, there are output identity gates for each output wire w, with input wire indexed w and output wire -(w+1). Notice that for the composed circuit the input and output wires remain the same. The identity gates maps the 0 input key to the 0 output key, and the 1 input key to the 1 output key.
| Method Summary | |
|---|---|
void |
compute(java.util.Map<java.lang.Integer,GarbledWire> computedWires)
Computes the output of this gate and sets the output wire(s) to that value. |
int[] |
getInputWireIndices()
|
int[] |
getOutputWireIndices()
|
boolean |
verify(Gate g,
java.util.Map<java.lang.Integer,javax.crypto.SecretKey[]> allWireValues)
This method tests an ungarbled Gate for equality to this GarbledGate . |
| Methods inherited from class java.lang.Object |
|---|
equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
| Method Detail |
|---|
public void compute(java.util.Map<java.lang.Integer,GarbledWire> computedWires) throws java.security.InvalidKeyException, javax.crypto.IllegalBlockSizeException, CiphertextTooLongException
GarbledGate
compute
in interface GarbledGate
computedWires
- A Map
containing the GarbledWires
s that have already been computed and had their values set.
java.security.InvalidKeyException
javax.crypto.IllegalBlockSizeException
CiphertextTooLongException
public boolean verify(Gate g, java.util.Map<java.lang.Integer,javax.crypto.SecretKey[]> allWireValues) throws java.security.InvalidKeyException, javax.crypto.IllegalBlockSizeException, CiphertextTooLongException
GarbledGate
Gate
for equality to this GarbledGate
. That is, they have the same truth table and indices.
It is called verify since in general, when this method is used, the assumption is that they are equal and we are verifying this assumption.
verify
in interface GarbledGate
g
- an ungarbled Gate
to be tested for equality to this GarbledGate
.allWireValues
- contains both keys of all wires.
true
if the gates have the same truth table and indeces, and false
otherwise.
java.security.InvalidKeyException
javax.crypto.IllegalBlockSizeException
CiphertextTooLongException
public int[] getInputWireIndices()
getInputWireIndices
in interface GarbledGate
public int[] getOutputWireIndices()
getOutputWireIndices
in interface GarbledGate
|
||||||||||
| PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
| SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |


There are just a handful important terms in Horntell around which our whole discussion will revolve. They are:
App: One Horntell account can be used for more than one app. Each such app that you configure in your account is called an app in Horntell.
Environment: We understand that before pushing the integration in public, you’d like to test it out in your development environment. Therefore, each app comes with two environments - LIVE (for production) and TEST (for development/testing). The two environments run independently of each other and the data between them is not shared (unless you decide to move things from TEST to LIVE yourself).
Profiles: Cards are user-specific. Your every user has a corresponding profile created in Horntell account. A user in your app is called a profile in Horntell.
Cards: These are the Assistive Cards in Horntell’s terms. We use Cards and Assistive Cards interchangeably throughout the ecosystem.
Campaigns: In our beta, we found our users hardcoding the Card’s content in their codebase. This meant that to change the content, they’d to go through the long shipping cycle. Ugh! Using campaigns, you can save the content of the Card in your dashboard as a template and put the identifier of the campaign in your codebase. Need to change the content? Do it on the fly from your dashboard. Sweet!
Segments: Segments are the group of users that share some common characteristics. We have put the following segments in your Horntell account for each app:
- All: everyone.
- New: everyone who signed up less than 3 days ago.
- Active: everyone who signed up more than 30 days ago but was last seen less than 3 days ago.
- Slipping Away: everyone who signed up less than 30 days ago but was last seen more than 7 days ago.
- Lost: everyone who was last seen more than 30 days ago.
Note: We may open up feature to create your own custom segments in future.


@* * Copyright 2023 HM Revenue & Customs * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. *@ @import config.FrontendAppConfig @import uk.gov.hmrc.govukfrontend.views.html.components.FormWithCSRF @this( uiForm: FormWithCSRF, main_template: main_template ) @(appConfig: FrontendAppConfig)(serviceInfoContent: Html)(implicit request: Request[_], messages: Messages) @link(key: String, url: String) = { @messages(s"partnershipRegisterByPhone.$key") } @main_template( title = messages("partnershipRegisterByPhone.title"), appConfig = appConfig, serviceInfoContent = Some(serviceInfoContent)) { @components.heading("partnership-registration-by-phone", "partnershipRegisterByPhone.heading")
@Html(messages("partnershipRegisterByPhone.p1", link("p1.linkText", appConfig.getGovUKUrl("contact"))))
@messages("partnershipRegisterByPhone.list1heading")
@messages("partnershipRegisterByPhone.list2heading")
@messages("partnershipRegisterByPhone.list3heading")
@messages("partnershipRegisterByPhone.p2")
@Html(messages("partnershipRegisterByPhone.p3", link("p3.linkText", appConfig.getGovUKUrl("paye"))))
}


this is a regular quote still that quote
this is a regular quote
still that quote
this is a test alert-box same test alert box
this is a test alert-box
same test alert box


--- layout: newsstory title: FIXTURES ANNOUNCED match: ---
With the World Cup over we can now concentrate on what's a mercifully short wait until the new season. Hurrah!
The fixture list is now out, and I've uploaded all of the DMPL fixtures on to the site for your perusal. The season kicks off on August 17 at The Grove against Welling and finishes on May 3 at home to Chippenham - the last away game being a reasonable trip to Folkestone. The FA Trophy draw has also been made, and we're at home to Bath in the 1st Round.
No additional player news as yet, other than we're back in training with the first friendly against the Harriers next week (July 16th). I'm getting a little excited already.


Categories
Politics
Finances
Sport
Cars
Fashion
Nature
History
IT
Politics
Finances
Sport
Cars
Fashion
Nature
History
IT
Politics
Finances
Sport
Cars
Fashion
Nature
History
IT


Suffered Alteration in Some Form
The Internet Tend To Repeat
Making it Look Like Readable
8AM - 09PM
Subscribe to our newsletter and get 20% off your first purchase


RT @sweetlew: A historic day for @newrelic as we launch Insights and create a new category: Software Analytics. http://blog.newrelic.com/2014/03/19/announcing-new-relic-insights-from-lew-cirne/
3/19/2014, 10:10:43 AM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @sweetlew: A historic day for @newrelic as we launch Insights and create a new category: Software Analytics. http://blog.newrelic.com/2014/03/19/announcing-new-relic-insights-from-lew-cirne/
3/19/2014, 10:10:43 AM
Favs: 0
Retweets: 0
link


I've always been into philosophy, but only in the last few years have I been deeply interested in politics. As exciting as the question "What does it mean to exist?" is, these days I'm into slightly more pragmatic things like how do we get everyone healthcare. I have lofty goals of making a more effective and tough left, but ultimately I just want to do as much good in the world as possible.  After you think about it and still haven't figured it out, email me.


Minimalist-chic coffee bar with hot & cold drinks, window-bar seating, communal tables & WiFi.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Hip coffeehouse with a courtyard patio also serves craft beers & hosts live music on the weekends.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Handcrafted, health-conscious breakfast & lunch fare (plus a coffee bar) in a homey environment.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Modern, counter-serve cafe offering espresso drinks, tea, cold-pressed juices & baked goods.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Relaxed spot for custom-bean coffee drinks & craft beers paired with sweet & savory baked goods.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Quaint coffee shop offering espresso drinks, plus breakfast & lunch eats in a laid-back atmosphere.
Phone:<PHONE_NUMBER>
Email<EMAIL_ADDRESS>400 King St
Charleston, SC 33444
Do you search of the perfect cup of coffee? Look no further, here you can find and rate the top cafes in your city.


Zend\Search\Lucene is a general purpose text search engine written entirely in PHP 5. Since it stores its index on the filesystem and does not require a database server, it can add search capabilities to almost any PHP-driven website. Zend\Search\Lucene supports the following features:
- Ranked searching - best results returned first
- Many powerful query types: phrase queries, boolean queries, wildcard queries, proximity queries, range queries and many others.
- Search by specific field (e.g., title, author, contents)
Zend\Search\Lucene was derived from the Apache Lucene project. The currently (starting from ZF 1.6) supported Lucene index format versions are 1.4 - 2.3. For more information on Lucene, visit http://lucene.apache.org/java/docs/.
Note
Previous Zend\Search\Lucene implementations support the Lucene 1.4 (1.9) - 2.1 index formats.
Starting from Zend Framework 1.5 any index created using pre-2.1 index format is automatically upgraded to Lucene 2.1 format after the Zend\Search\Lucene update and will not be compatible with Zend\Search\Lucene implementations included into Zend Framework 1.0.x.
Zend\Search\Lucene operates with documents as atomic objects for indexing. A document is divided into named fields, and fields have content that can be searched.
A document is represented by the Zend\Search\Lucene\Document class, and this objects of this class contain instances of Zend\Search\Lucene\Field that represent the fields on the document.
It is important to note that any information can be added to the index. Application-specific information or metadata can be stored in the document fields, and later retrieved with the document during search.
It is the responsibility of your application to control the indexer. This means that data can be indexed from any source that is accessible by your application. For example, this could be the filesystem, a database, an HTML form, etc.
Zend\Search\Lucene\Field class provides several static methods to create fields with different characteristics:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 | $doc = new Zend\Search\Lucene\Document();
// Field is not tokenized, but is indexed and stored within the index.
// Stored fields can be retrieved from the index.
$doc->addField(Zend\Search\Lucene\Field::Keyword('doctype',
'autogenerated'));
// Field is not tokenized nor indexed, but is stored in the index.
$doc->addField(Zend\Search\Lucene\Field::UnIndexed('created',
time()));
// Binary String valued Field that is not tokenized nor indexed,
// but is stored in the index.
$doc->addField(Zend\Search\Lucene\Field::Binary('icon',
$iconData));
// Field is tokenized and indexed, and is stored in the index.
$doc->addField(Zend\Search\Lucene\Field::Text('annotation',
'Document annotation text'));
// Field is tokenized and indexed, but is not stored in the index.
$doc->addField(Zend\Search\Lucene\Field::UnStored('contents',
'My document content'));
|
Each of these methods (excluding the Zend\Search\Lucene\Field::Binary() method) has an optional $encoding parameter for specifying input data encoding.
Encoding may differ for different documents as well as for different fields within one document:
1 2 3 4 5 6 7 | $doc = new Zend\Search\Lucene\Document();
$doc->addField(Zend\Search\Lucene\Field::Text('title',
$title,
'iso-8859-1'));
$doc->addField(Zend\Search\Lucene\Field::UnStored('contents',
$contents,
'utf-8'));
|
If encoding parameter is omitted, then the current locale is used at processing time. For example:
1 2 3 | setlocale(LC_ALL, 'de_DE.iso-8859-1');
...
$doc->addField(Zend\Search\Lucene\Field::UnStored('contents', $contents));
|
Fields are always stored and returned from the index in UTF-8 encoding. Any required conversion to UTF-8 happens automatically.
Text analyzers (see below) may also convert text to some other encodings. Actually, the default analyzer converts text to ‘ASCII//TRANSLIT’ encoding. Be careful, however; this translation may depend on current locale.
Fields’ names are defined at your discretion in the addField() method.
Java Lucene uses the ‘contents’ field as a default field to search. Zend\Search\Lucene searches through all fields by default, but the behavior is configurable. See the “Default search field” chapter for details.
Keyword fields are stored and indexed, meaning that they can be searched as well as displayed in search results. They are not split up into separate words by tokenization. Enumerated database fields usually translate well to Keyword fields in Zend\Search\Lucene.
UnIndexed fields are not searchable, but they are returned with search hits. Database timestamps, primary keys, file system paths, and other external identifiers are good candidates for UnIndexed fields.
Binary fields are not tokenized or indexed, but are stored for retrieval with search hits. They can be used to store any data encoded as a binary string, such as an image icon.
Text fields are stored, indexed, and tokenized. Text fields are appropriate for storing information like subjects and titles that need to be searchable as well as returned with search results.
UnStored fields are tokenized and indexed, but not stored in the index. Large amounts of text are best indexed using this type of field. Storing data creates a larger index on disk, so if you need to search but not redisplay the data, use an UnStored field. UnStored fields are practical when using a Zend\Search\Lucene index in combination with a relational database. You can index large data fields with UnStored fields for searching, and retrieve them from your relational database by using a separate field as an identifier.
| Field Type | Stored | Indexed | Tokenized | Binary |
|---|---|---|---|---|
| Keyword | Yes | Yes | No | No |
| UnIndexed | Yes | No | No | No |
| Binary | Yes | No | No | Yes |
| Text | Yes | Yes | Yes | No |
| UnStored | No | Yes | Yes | No |
Zend\Search\Lucene offers a HTML parsing feature. Documents can be created directly from a HTML file or string:
1 2 3 4 5 | $doc = Zend\Search\Lucene\Document\Html::loadHTMLFile($filename);
$index->addDocument($doc);
...
$doc = Zend\Search\Lucene\Document\Html::loadHTML($htmlString);
$index->addDocument($doc);
|
Zend\Search\Lucene\Document\Html class uses the DOMDocument::loadHTML() and DOMDocument::loadHTMLFile() methods to parse the source HTML, so it doesn’t need HTML to be well formed or to be XHTML. On the other hand, it’s sensitive to the encoding specified by the “meta http-equiv” header tag.
Zend\Search\Lucene\Document\Html class recognizes document title, body and document header meta tags.
The ‘title’ field is actually the /html/head/title value. It’s stored within the index, tokenized and available for search.
The ‘body’ field is the actual body content of the HTML file or string. It doesn’t include scripts, comments or attributes.
The loadHTML() and loadHTMLFile() methods of Zend\Search\Lucene\Document\Html class also have second optional argument. If it’s set to TRUE, then body content is also stored within index and can be retrieved from the index. By default, the body is tokenized and indexed, but not stored.
The third parameter of loadHTML() and loadHTMLFile() methods optionally specifies source HTML document encoding. It’s used if encoding is not specified using Content-type HTTP-EQUIV meta tag.
Other document header meta tags produce additional document fields. The field ‘name’ is taken from ‘name’ attribute, and the ‘content’ attribute populates the field ‘value’. Both are tokenized, indexed and stored, so documents may be searched by their meta tags (for example, by keywords).
Parsed documents may be augmented by the programmer with any other field:
1 2 3 4 5 6 7 8 | $doc = Zend\Search\Lucene\Document\Html::loadHTML($htmlString);
$doc->addField(Zend\Search\Lucene\Field::UnIndexed('created',
time()));
$doc->addField(Zend\Search\Lucene\Field::UnIndexed('updated',
time()));
$doc->addField(Zend\Search\Lucene\Field::Text('annotation',
'Document annotation text'));
$index->addDocument($doc);
|
Document links are not included in the generated document, but may be retrieved with the Zend\Search\Lucene\Document\Html::getLinks() and Zend\Search\Lucene\Document\Html::getHeaderLinks() methods:
1 2 3 | $doc = Zend\Search\Lucene\Document\Html::loadHTML($htmlString);
$linksArray = $doc->getLinks();
$headerLinksArray = $doc->getHeaderLinks();
|
Starting from Zend Framework 1.6 it’s also possible to exclude links with rel attribute set to ‘nofollow’. Use Zend\Search\Lucene\Document\Html::setExcludeNoFollowLinks($true) to turn on this option.
Zend\Search\Lucene\Document\Html::getExcludeNoFollowLinks() method returns current state of “Exclude nofollow links” flag.
Zend\Search\Lucene offers a Word 2007 parsing feature. Documents can be created directly from a Word 2007 file:
1 2 | $doc = Zend\Search\Lucene\Document\Docx::loadDocxFile($filename);
$index->addDocument($doc);
|
Zend\Search\Lucene\Document\Docx class uses the ZipArchive class and simplexml methods to parse the source document. If the ZipArchive class (from module php_zip) is not available, the Zend\Search\Lucene\Document\Docx will also not be available for use with Zend Framework.
Zend\Search\Lucene\Document\Docx class recognizes document meta data and document text. Meta data consists, depending on document contents, of filename, title, subject, creator, keywords, description, lastModifiedBy, revision, modified, created.
The ‘filename’ field is the actual Word 2007 file name.
The ‘title’ field is the actual document title.
The ‘subject’ field is the actual document subject.
The ‘creator’ field is the actual document creator.
The ‘keywords’ field contains the actual document keywords.
The ‘description’ field is the actual document description.
The ‘lastModifiedBy’ field is the username who has last modified the actual document.
The ‘revision’ field is the actual document revision number.
The ‘modified’ field is the actual document last modified date / time.
The ‘created’ field is the actual document creation date / time.
The ‘body’ field is the actual body content of the Word 2007 document. It only includes normal text, comments and revisions are not included.
The loadDocxFile() methods of Zend\Search\Lucene\Document\Docx class also have second optional argument. If it’s set to TRUE, then body content is also stored within index and can be retrieved from the index. By default, the body is tokenized and indexed, but not stored.
Parsed documents may be augmented by the programmer with any other field:
1 2 3 4 5 6 7 8 9 10 | $doc = Zend\Search\Lucene\Document\Docx::loadDocxFile($filename);
$doc->addField(Zend\Search\Lucene\Field::UnIndexed(
'indexTime',
time())
);
$doc->addField(Zend\Search\Lucene\Field::Text(
'annotation',
'Document annotation text')
);
$index->addDocument($doc);
|
Zend\Search\Lucene offers a Powerpoint 2007 parsing feature. Documents can be created directly from a Powerpoint 2007 file:
1 2 | $doc = Zend\Search\Lucene\Document\Pptx::loadPptxFile($filename);
$index->addDocument($doc);
|
Zend\Search\Lucene\Document\Pptx class uses the ZipArchive class and simplexml methods to parse the source document. If the ZipArchive class (from module php_zip) is not available, the Zend\Search\Lucene\Document\Pptx will also not be available for use with Zend Framework.
Zend\Search\Lucene\Document\Pptx class recognizes document meta data and document text. Meta data consists, depending on document contents, of filename, title, subject, creator, keywords, description, lastModifiedBy, revision, modified, created.
The ‘filename’ field is the actual Powerpoint 2007 file name.
The ‘title’ field is the actual document title.
The ‘subject’ field is the actual document subject.
The ‘creator’ field is the actual document creator.
The ‘keywords’ field contains the actual document keywords.
The ‘description’ field is the actual document description.
The ‘lastModifiedBy’ field is the username who has last modified the actual document.
The ‘revision’ field is the actual document revision number.
The ‘modified’ field is the actual document last modified date / time.
The ‘created’ field is the actual document creation date / time.
The ‘body’ field is the actual content of all slides and slide notes in the Powerpoint 2007 document.
The loadPptxFile() methods of Zend\Search\Lucene\Document\Pptx class also have second optional argument. If it’s set to TRUE, then body content is also stored within index and can be retrieved from the index. By default, the body is tokenized and indexed, but not stored.
Parsed documents may be augmented by the programmer with any other field:
1 2 3 4 5 6 7 8 | $doc = Zend\Search\Lucene\Document\Pptx::loadPptxFile($filename);
$doc->addField(Zend\Search\Lucene\Field::UnIndexed(
'indexTime',
time()));
$doc->addField(Zend\Search\Lucene\Field::Text(
'annotation',
'Document annotation text'));
$index->addDocument($doc);
|
Zend\Search\Lucene offers a Excel 2007 parsing feature. Documents can be created directly from a Excel 2007 file:
1 2 | $doc = Zend\Search\Lucene\Document\Xlsx::loadXlsxFile($filename);
$index->addDocument($doc);
|
Zend\Search\Lucene\Document\Xlsx class uses the ZipArchive class and simplexml methods to parse the source document. If the ZipArchive class (from module php_zip) is not available, the Zend\Search\Lucene\Document\Xlsx will also not be available for use with Zend Framework.
Zend\Search\Lucene\Document\Xlsx class recognizes document meta data and document text. Meta data consists, depending on document contents, of filename, title, subject, creator, keywords, description, lastModifiedBy, revision, modified, created.
The ‘filename’ field is the actual Excel 2007 file name.
The ‘title’ field is the actual document title.
The ‘subject’ field is the actual document subject.
The ‘creator’ field is the actual document creator.
The ‘keywords’ field contains the actual document keywords.
The ‘description’ field is the actual document description.
The ‘lastModifiedBy’ field is the username who has last modified the actual document.
The ‘revision’ field is the actual document revision number.
The ‘modified’ field is the actual document last modified date / time.
The ‘created’ field is the actual document creation date / time.
The ‘body’ field is the actual content of all cells in all worksheets of the Excel 2007 document.
The loadXlsxFile() methods of Zend\Search\Lucene\Document\Xlsx class also have second optional argument. If it’s set to TRUE, then body content is also stored within index and can be retrieved from the index. By default, the body is tokenized and indexed, but not stored.
Parsed documents may be augmented by the programmer with any other field:
1 2 3 4 5 6 7 8 | $doc = Zend\Search\Lucene\Document\Xlsx::loadXlsxFile($filename);
$doc->addField(Zend\Search\Lucene\Field::UnIndexed(
'indexTime',
time()));
$doc->addField(Zend\Search\Lucene\Field::Text(
'annotation',
'Document annotation text'));
$index->addDocument($doc);
|
The source code of this file is hosted on GitHub. Everyone can update and fix errors in this document with few clicks - no downloads needed.


Juntupg1708.github.io
Eit 1986 sind wir Ihr Partner für professionelle Audioelektronik. Ganz nach dem Motto “Tools - not Toys”. Booking.com: 29,093,407 hotel and property listings. We d like to show you nearby Subaru retailers, special offers, pricing, and vehicle inventory that are available ARD.de - das Online-Portal der ARD - ARD Startseite. Aufgenommen mit Cubase 8, Yamaha UR824, MYTEK 192 ADC, LAKE PEOPLE MIC-AMP F355. Ach ja, das Mikrofon braucht Einiges an Vorverstärkung, nicht zu vergessen. Ach ja, das Mikrofon braucht Einiges an Vorverstärkung, nicht zu vergessen. Lake People Bedienungsanleitungen (Archiv) - violectric.de. Lake People Aed F62 Mk I Bedienungsanleitung. Sennheiser MD441-U Dynamisches Mikrofon - thomann.de. Official Wizz Air website Book direct for the cheapest.
Search and rescue (SAR) is the search for and provision of aid to people who are in distress or imminent danger. The general field of search and rescue includes many specialty sub-fields, typically determined by the type of terrain the search is conducted.
 Our 29,093,407 listings include 5,795,152 listings of homes, apartments, and other unique places to stay, and are located in 144,597 destinations in 230 countries and territories. Lake People Audio-Equipment mit 3 Jahren Garantie und Money. Mark Blyth @MkBlyth. Professor of Political Economy at Brown University. Author of Austerity: The History of a Dangerous Idea, Great Transformations.
Welcome to AEG. AEG was founded in Germany over a century ago on a simple philosophy: everything it designs should be perfect in both form and function. Videos und Audios aus den Mediatheken, aktuelle Nachrichten und Hintergründe, das ARD-Programm auf einen Blick. Book direct at the official wizzair.com site to get the best prices on cheap flights to more than 140 destinations.


SuperLuminauts is a local-multiplayer spaceship shooter where your missiles leave trails in space & time
"It's a top down sort of twin stick shooter that has a lot of physics about it - you're just going to have to watch... there's a lot more to it than we thought when we played the first round"
Every projectile you fire leaves a trail in space-time, like a grandfather paradox waiting to happen. A richocheting, neon, grandfather paradox. Like an artist you can plan each stroke with precision, or like a modern artist you can throw a haphazard mess and do a pretty good job too.
2-4 Player Couch Chaos
To start playing, all you need is a keyboard & mouse and another human being who you don't mind being temporary mortal enemies with. To maximize victorious gloating, you'll need to add 2 or more controllers for four players.
A Sci-Fi Rainbow of Ships
Though all vehicles are outfitted with the same specs,
we all know the coolest ship with the radest paint job is going to win.
3 New Ways to Play
We've scoured the universe of infinite game-modes, and we thought these were the most fun ways to demolish the fabric of space-time! And also involved the fewest subatomic-implosions and/or lizard-people uprisings.
Stellar Tunes
To make the bleeps, bloops, and music of SuperLuminauts, Cameron (LoadCard) digitized himself into the game with a microphone and synthesizer, and came back with 5 stellar tracks and the ability to speak to computers.


One of the nifty Hugo features we should cover: flexible configuration and front matter formats! This entry has front
matter in toml
, unlike the last one which used yaml
, and json
is also available if that’s your preference.
The toml
front matter used on this entry:
+++
title = "Another Hugo Post"
description = "Nothing special, but one post is boring."
date = "2014-09-02"
categories = [ "example", "configuration" ]
tags = [
"example",
"hugo",
"toml"
]
+++
This flexibility also extends to your site’s global configuration file. You’re free to use any format you prefer::simply
name the file config.yaml
, config.toml
or config.json
, and go on your merry way.
How would this entry’s front matter look in json
? That’s easy enough to demonstrate:
{
"title": "Another Hugo Post",
"description": "Nothing special, but one post is boring.",
"date": "2014-09-02",
"categories": [ "example", "configuration" ],
"tags": [
"example",
"hugo",
"toml"
],
}


The Art of Brunching
"The socially acceptable excuse to drink before noon"
We love nothing more than a good brunch, be they brilliantly boozy or vibrant and virtuous.
Find a brunch near you
London
Manchester
Nottingham
Leeds
Newcastle
Edinburgh


A service is a transaction in which no physical goods are transferred from the seller to the buyer. The benefits of such a service are held to be demonstrated by the buyer's willingness to make the exchange.
Web design encompasses many different skills and disciplines in the production and maintenance of websites. The different areas of web design include web graphic design; user interface design; authoring, including standardised code and proprietary software; user experience design; and search engine
App design combines the user interface (UI) and user experience (UX). While UI lends itself to the overall style of the app (including the colors, fonts, and general look and feel), UX focuses on the actual functionality and usability.
Microsoft Word is a word processor developed by Microsoft. It was first released on October 25, 1983,[6] under the name Multi-Tool Word for Xenix systems.[7][8][9] Subsequent versions were later written for several other platforms including IBM PCs running DOS (1983), Apple Macintosh running the Classic Mac OS (1985), AT&T UNIX PC (1985), Atari ST (1988), OS/2 (1989), Microsoft Windows (1989), SCO Unix (1994), and macOS (2001).
Microsoft Excel is a spreadsheet developed by Microsoft for Windows, macOS, Android and iOS. It features calculation, graphing tools, pivot tables, and a macro programming language called Visual Basic for Applications.
In This website I made a front end which looks like a glass.
Link is given below you can check it!
In this website I made my portfolio. It is a Single page website
A front end web developer is the person who implements web designs through coding languages like HTML, CSS, and JavaScript. Though it’s not as common anymore, front end developers are/were sometimes called “client-side developers” to distinguish them from back end developers who program what goes on behind the scenes (like databases). If you head to any site, you can see the work of a front end developer everywhere—in the navigation, layouts including this article page, even the way that a site looks different from your phone
Click For Resume


Name:
Email:
How Did You Hear About Me?:
How did you hear about me?
Internet
Google
Magazine
A relative
Other
What Web Services are you interested in??
New Website
Website Redesign
Special Application
Complimentary Lollipops
Other
Would you like to join our mailing list?
Yes
No
Comments:


--- layout: boardnews title: 'Alumni Board meets in Berlin' date: 'September 4th, 2015' author: 'Peter Dabrowski' permalink: '/board-news/10-alumni-board-meets-in-berlin' titleImage: 'board-news/berlin-e1441355022607.jpg' preview: 't = -28 days was on the ticker for homecoming when the Alumni Board kicked of their 2nd meeting this year in Berlin on August 29th in the offices of Rapidape. Last prep and finalization' ---
In the picture: Left to right: Stefan Anca, Stephan Ziegler, Alina Degtiarova, Peter Dabrowski, Predrag Tapavicki, Daniel Garcia & Stefan Rustler.
t = -28 days was on the ticker for homecoming when the Alumni Board kicked of their 2nd meeting this year in Berlin on August 29th in the offices of Rapidape. Last prep and finalization for our main annual event were obviously a major item on the agenda. Sales via our all new ticket shop were successfully launched and expectations are high with a headcount of more than 100 participants! It will be the second ever double reunion, with the Classes of 2005 and 2010 celebrating their 10 and 5 year graduation anniversary respectively.
For the first time in more than a year the board was joined by our Alma Mater, represented by Predrag Tapavicki (Head of Corporate Relations and Talent Management) and Stephan Ziegler (Alumni and Career Services Officer). A great addition to the team, with a productive exchange and alignment on projects, such as the Generation Fund, where a close cooperation with the university is essential.
In good old tradition Saturday evening was topped off by meeting with the Berlin Local Chapter at the Prater Biergarten in Prenzlauer Berg. Keep your eyes open for our elections update and our candidates for Treasurer and Members and Content Manager and see many of you at Homecoming… t = -21 days!
Want more details on the Board Meeting content? Check out meetings here (you must be logged in to view) and, as usual. we welcome your feedback at<EMAIL_ADDRESS>or in comment section below.


Executes the command. Before execution it validates args using the defined schema. The command execution intercepts exceptions raised by the called function and returns them as an error in callback.
(optional) transaction id to trace execution through call chain.
the parameters (arguments) to pass to this command for execution.
function to be called when command is complete
Gets the command name.
the name of this command.
Validates the command args before execution using the defined schema.
the parameters (arguments) to validate using this command's schema.
an array of ValidationResults or an empty array (if no schema is set).
Generated using TypeDoc
Concrete implementation of ICommand interface. Command allows to call a method or function using Command pattern.
Example
let command = new Command("add", null, (correlationId, args, callback) => { let param1 = args.getAsFloat("param1"); let param2 = args.getAsFloat("param2"); let result = param1 + param2; callback(null, result); }); command.execute( "123", Parameters.fromTuples( "param1", 2, "param2", 2 ), (err, result) => { if (err) console.error(err); else console.log("2 + 2 = " + result); } ); // Console output: 2 + 2 = 4
ICommand
CommandSet


Helped by market rates, Greece repays IMF early
by The Associated PressATHENS, Greece (AP) — Greece’s finance ministry says the country has completed an early repayment of loans to the International Monetary Fund worth 2.7 billion euros ($2.9 billion).
The action completed Monday had received the required approval from European bailout lenders and will help Greece lower its debt servicing costs by taking advantage of favorable market rates.
Greece completed its third successive international bailout program last year, after receiving rescue loans over eight years from its European Union partners and the IMF to avoid default and remain in the euro zone.
Greek government bond yields have fallen sharply in recent months, rivaling rates in fellow-euro zone member Italy and assisting Greece’s return to markets. The yield on Greece’s 10-year bond late Monday was 1.37%, tumbling from nearly 4% at the start of the year.
The Associated Press


Currency calculator:
Enter amount in US dollars :
Enter currency symbol:
Or select here
Currency Symbol:
Exchange
Conversion was completed!
Try again
Conversion cannot be completed!
Try again


Please watch this video about the mobile application.
0:00hi i doing this is russell Greenspan technology tutor.com i'm here to demo
0:06our mobile application for the iphone ipod touch and the ipad
0:12it's the Tudor , - goes the mobile companion for Tudor calm and use the
0:17same account information that you use to access to her calm on your computer so
0:21i'm gonna go ahead and sign in and I'm presented with the options available to me
0:25I can connect to a tutor for live once one help i can review resources in our
0:30skills that our library
0:32I can look at the files in my tutor , marker or i can review past sessions and
0:37I've had with other tutors and I've already got a file in my locker and i'm
0:41going to go ahead and connect to a tutor for help with this problem
0:44so this problem is about slope this is where I picked the problem that i have in my locker
0:49there you can see it and this is where I picked the subject that I need help
0:53so I need help in ninth grade algebra my sig necked and that's it i'm now waiting for the tutor
1:05all right so I'm not connected to the tutor you can see on the left is the
1:10chat area and on the right is the whiteboard area where the tutor and I
1:16can draw back and forth to each other and this is the problem that i shared my
1:20tutor to picture of homework that I've taken a picture of with my ipad and now
1:28using the whiteboard
1:29- and I can mark this problem up so using my finger and when
1:32draw directly onto this whiteboard here and the tutor of course is seeing
1:36everything I draw and the tutor can drop back to me
1:47as the tutor is drawing
1:49I'm seeing on my board with the tutors
1:55and i'm going to go ahead and complete this equation try
2:08she's my finger increase the thickness and draw a sharp line change the color
2:27so let's have a session on your iPad using 2.com to go and a session at the
2:33end of the session are presented with a survey
2:35I'm going to say this to you did an excellent job and thanks to the first
2:40time and that's it thanks for watching hope you enjoyed that demo please
2:49download the app 2.com / - go and let us know what you think


--- layout: post title: AFL 2009 Commercial external-url: http://www.youtube.com/watch?v=YgnM9gNlMgk&fmt=18 ---
Brilliant commercial for the new season starting this weekend. I bought my Lions season tickets yesterday. Similar to this also brilliant Nike Football commercial.


Lets make some music!
If there is an error while rendering, move one of the sliders. That should start the app properly.
Drums
Speed: {{sliderVal2}}
Volume: {{sliderVal3}}
Bass
Speed: {{sliderVal4}}
Volume: {{sliderVal5}}
Arp
Speed: {{sliderVal6}}
Volume: {{sliderVal7}}
Chords
Speed: {{sliderVal8}}
Volume: {{sliderVal9}}
Drums
Speed: {{sliderVal10}}
Volume: {{sliderVal11}}
Arp
Speed: {{sliderVal12}}
Volume: {{sliderVal13}}
BassDrum
Speed: {{sliderVal14}}
Volume: {{sliderVal15}}
Cymbal
Speed: {{sliderVal16}}
Volume: {{sliderVal17}}
Hihat
Speed: {{sliderVal18}}
Volume: {{sliderVal19}}
SlowDrum
Speed: {{sliderVal20}}
Volume: {{sliderVal21}}
SnareDrum
Speed: {{sliderVal22}}
Volume: {{sliderVal23}}
Vibes
Speed: {{sliderVal24}}
Volume: {{sliderVal25}}
{{drums}} {{bass}} {{arp}} {{chords}} {{drums2}} {{arp2}} {{bassDrum}} {{cymbal}} {{hihat}} {{slowdrum}} {{snaredrum}} {{vibes}}


Our Sponsors
Conference Sponsor
K-CAP 2015 is proud to be an ACM-SIGAI-sponsored conference
Diamond
Gold
Friends of K-CAP


A simple international telephone number input. Allows you to create a phone number field with country dropdown.
This is re-written version (with enhancement) of ng4-intl-phone. So credit should go to kondi0.
To install this library, run:
$ npm install ngx-international-phone-number --save
Once you have installed it you can import InternationalPhoneNumberModule
from ngx-international-phone-number
in any application module. E.g.
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { AppComponent } from './app.component';
// Import your library
import { InternationalPhoneNumberModule } from 'ngx-international-phone-number';
@NgModule({
declarations: [
AppComponent
],
imports: [
BrowserModule,
// InternationalPhoneNumberModule module
InternationalPhoneNumberModule
],
providers: [],
bootstrap: [AppComponent]
})
export class AppModule { }
Once it is imported, you can use international-phone-number
:
<!-- app.component.html -->
<form name="sample-form" (ngSubmit)="submit()" #f="ngForm">
<international-phone-number [(ngModel)]="model.phone_number" placeholder="Enter phone number" [maxlength]="20" [defaultCountry]="'in'" [required]="true" #phoneNumber="ngModel" name="phone_number" [allowedCountries]="['in', 'ca', 'us']"></international-phone-number>
<div *ngIf="f.submitted && !phoneNumber.valid" class="help-block">Phone number is required and should be valid</div>
<button type="submit">Submit</button>
</form>
defaultCountryCode : An ISO 639-1 country code can be provided to set default country selected.
placeholder: A placeholder text which would be displayed in input widget
required: Indicates whether it's required or not
allowDropdown: Indicates whether to allow selecting country from dropdown
allowedCountries: A list of countries (iso codes) that would get display in country dropdown. E.g. [allowedCountries]="['in', 'ca', 'us']" would only show Canada, India and US. If not provided, all the countries would get displayed.
If you are getting error "Can't resolve 'google-libphonenumber'" while building with aot, try to install google-libphonenumber. Run npm install<EMAIL_ADDRESS>--save
* Original Author: kondi0
* Author: nikhiln
MIT


Hey, your connection is lost , please check your internet connection
What you do today can improve all your tomorrows.