text:
Serial Programming/Unix V7

= Unix V7 Serial Programming =

Unix V7 - Introduction
Unix V7 was one of the early Unix versions which gained some wider distribution also outside of universities. It was commercially released in 1978. As a consequence, the Unix V7 way of accessing and controlling terminals set the standard for terminal and serial communication in Unix for quite some time. The V7 API does not consist of any particular C function calls. Instead, the settings and configuration of the serial device is done via the standard ioctl(2) system call, and data transfer is done via the standard read(2) and write(2) system calls.

Although, the API originated in Unix V7 it of course didn't remain unchanged. E.g. XENIX used a different name for the  data structure. Some systems use a 32 bit value for the  entry in the   structure, others a 16 bit value. BSD added a bunch of ioctls, BSD 4.3 added a bunch of option codes (together sometimes called the BSD I/O environment), partly incompatible with Unix SVR3 codes, ...

All in all, if a later terminal API like  or   is available, it makes much sense to use the later API instead of the Unix V7, or V7-lookalike API. If the Unix V7 API is really used, some extensive study of the particular system's documentation and include files is in order. Nevertheless, there is some chance to find that the API is used in some classic Unix source code, particular in free software from that age that survived until today.

Originally, the necessary definitions for the terminal (serial) specific ioctl(2) system calls could be found in the sgtty.h and sys/tty.h> headers. However, in later Unix versions the contents was moved to sys/ttold.h and parts of it also ended up in termios.h, or the API was removed completely.

Mentioning termios.h here sounds rather strange, since it is a later API. But termio and termios borrowed from the V7 API, and systems which still support the V7 API often do this by emulating the API on top of the normal termio or termios interface with a compatible device driver. This is done by pushing an additional STREAMS device driver module on top of the termio or termios device driver. That STREAMS module is typically called ttycompat. How a particular Unix system can be configured to automatically push the module onto a device, how it can be manually pushed, or how the STREAMS device framework works is out of the scope of this description.

Unix V7 - Mode of Operation
As already mentioned, the Unix V7 way of controlling terminal devices is to use ioctl(2) system calls. ioctl(2) is not specific to serial devices. The system call is part of Unix's generic device driver interface. The more widely used system calls for this interface are read(2) and write(2). While read(2) and write(2) do transport the "payload" (the data), ioctl(2) on the other hand controls the I/O operation as such. That is, it enables a program to configure the device.

The generic signature of the system call is

int ioctl(int fd, int command, ...); or int ioctl(int fd, int command, ...); or ioctl(fd, command, data) /* Unix V7 - K&R C */ int fd, command; char *data;
 * 1) include       /* Unix SVR4 family */
 * 1) include    /* Unix BSD family */

With the following arguments:

 * : is a file descriptor pointing to an opened device.

 * :is an integer which tells the device what to do, and logically needs to be known by the device. The list of commands a serial device is supposed to understand is defined in sys/ttold.h (newer Unix systems) or <tt>sgtty.h</tt> plus <tt>sys/tt.h</tt> (old Unix systems like Unix V7) as macros. For the remainder of this section <tt>sys/ttold.h</tt> is used. Typically, <tt>sys/ttold.h</tt> is itself included by <tt>sys/ioctl.h</tt>. However, it doesn't hurt to include it explicitly for good measure.

 * The names of the core terminal I/O control command macros start with . In addition, a few file I/O control commands are also applicable. Their names start with  . We come to the commands and their purpose later, however, device-specific commands  are not discussed.

 * :The actual parameter for the vararg ellipse  arguments of ioctl is typically only a single pointer to some data structure - at least for the terminal control commands. This matches the old ioctl format, where there was one single   argument.

 * :For terminal control the  pointer points to a data structure of type
 * or
 * or

These data structures are used to communicate different types of information between the device driver and the application program. They control which settings are supposed to be done, or allow to fetch which parameters are currently set for the device.

Typically  looks like:

struct sgttyb { char sg_ispeed; /* input line speed  */ char sg_ospeed; /* output line speed */ char sg_erase;  /* erase char        */ char sg_kill;   /* kill char         */ int sg_flags;   /* flags             */ };

As one can see, it allows a program to communicate basic settings like the line speed and essential characters for the line discipline. Remember, the interface was made for communication with terminals, and therefore provides the support for a line discipline.

Typically  contains additional information about terminal control characters and looks like:

struct tchars { char t_intrc; /* interrupt character       */ char t_quitc; /* quit character            */ char t_startc; /* start output character   */ char t_stopc; /* stop output character     */ char t_eofc;  /* end-of-file character     */ char t_brkc;  /* input delimiter character */ };

In addition to these data structures BSD added more terminal control characters in:

struct ltchars { char t_suspc; /* stop-process character         */ char t_dsuspc; /* delayed stop-process character */ char t_rprntc; /* reprint line character        */ char t_flushc; /* flush output character        */ char t_werasc; /* word erase character          */ char t_lnextc; /* literal next character        */ };

To summarize, a configuration of a serial device generally follows the following template of statements (pseudo code, error handling, etc. excluded):

int fd; :  . /*   * Open the device. * O_RDRW  - open for reading and writing * O_NDELAY - ignore the state of the DCD line. Otherwise *           the ioctl blocks until DCD indicates the *           remote side is ready. Also affects behavior of *            the read(2) system call, which will now not block *           if there is no input data available. * O_NOCTTY - Do not become a controlling terminal. Has no effect for STREAMS */ fd = open("/dev/ttya", O_RDWR | O_NDELAY | O_NOCTTY); /* * Assume we have a "modern" STREAMS device implementation * and need to push the STREAMS modules on the stream to * get the desired V7 compatibility emulation. * TODO: Add error handling. */ if(ioctl(fd, I_FIND, "ldterm") == 0) { ioctl(fd, I_PUSH, "ldterm");    /* termios STREAMS terminal line discipline module */ } if(ioctl(fd, I_FIND, "ttcompat") == 0) { ioctl(fd, I_PUSH, "ttcompat");  /* Unix V7 STREAMS compatibility module */ } /* done with setting up the device */ :  . /* Probably set some values in data here */ ioctl(fd, TIO..., &data);     /* configure serial line */
 * 1) include <sys/stream.h>    /* for ldterm */
 * 2) include <sys/termios.h>   /* for ldterm - could of course also be used directly */
 * 3) include <sys/stropts.h>   /* for handling the STREAMS module */
 * 4) include <sys/ioctl.h>     /* ioctl signature */
 * 5) include <sys/ttold.h>     /* terminal control */
 * 6) include <sys/types.h>     /* for open */
 * 7) include <sys/stat.h>      /* for open */
 * 8) include <fcntl.h>         /* for open */

Overview
As already mentioned, the possible terminal I/O control commands to be used for terminal devices via ioctl are defined as macros. This section discusses their meaning and usage in ioctl system calls.

Unfortunately, the set of commands is a mess. Almost every implementation of Unix decided it would be cool to add their own, incompatible commands. To add insult to injury, some popular Unix versions defined particular commands, but couldn't be bothered to implement them for decades, then dropped them. And to make even more programmers happy, half of the commands where never in any way seriously documented or described. The programmers apparently thought that only those with access to the Kernel source code are deemed worthy to program serial interfaces.

Original Unix V7 ioctls
This section lists the original Unix V7 I/O control commands. They are presented as they are used as part of an ioctl(2) call. This has been done, so the passed data types can also be presented. The argument data types are underlined in the following list.

Line Discipline
These commands did exist in V7, and were implemented. However, they were not documented. Particularly, the argument's meaning was not documented (and probably not used). Later the following argument interpretation was added:
 * ioctl(fd, TIOCGETD, int * dscp):Get line discipline. See below.
 * ioctl(fd, TIOCSETD, int * dscp:Set line discipline.
 * OTTYDISC or 0:Unix V7 tty driver behavior
 * NETLDISC or 1:BSD Unix driver behavior
 * NTTYDISC or 2:New tty line discipline (whatever that is)

A typical usage looks as it follows. The  test is done to avoid executing the ioctl on a system with undefined TIOCSETD argument semantics (like the original V7, where the arguments of the command were not documented). The following changes the line discipline of the device identified by the handle fd to the Unix V7 tty driver behavior.

int dscp = OTTYDISC; ioctl(fd, TIOCSETD, &dscp);
 * 1) ifdef OTTYDISC
 * 1) endif

Hang-up on close
When a DT (data terminal, the computer) is no longer ready to send and receive serial data on an interface, it is supposed to drop the DTR (Data Terminal Ready) RS-232 control line of that serial interface. The following command allows to automate this.

 * ioctl(fd, TIOCHPCL, NULL):Set hang up on last close flag. Typically this is implemented as dropping the DTR (Data Terminal Ready) pin on the serial interface when the last close(2) is called on the device. Note, there is no direct inverse operation in V7. However, the flag can be cleared in some implementations via the   member of.

A typical sequence of events would look like it follows:

/********************************************************** * Set hang up on last close flag *********************************************************/ /* /* open device */ fd = open("/dev/ttya", O_RDWR | O_NDELAY | O_NOCTTY); /* device configuration (omitted) */ /* Set hang up on last close flag to drop DTR on last close */ ioctl(fd, TIOCHPCL, NULL); /* communicate via serial interface */ /* * Close device. If this is the last close (which it typically is), DTR * will be dropped/ */ close(fd);

/********************************************************** * Clear hang up on last close flag via TIOCSETP * Note the slightly different flag name HUPCL here * vs. HPCL in TIOCHPCL. *********************************************************/ struct sgttyb tparam; ... fd = open( ... ); ... ioctl(fd, TIOCGETP, &tparam); /* get current values */ tparam.sg_flags &= ~HUPCL;    /* only clear H[U]PCL flag */ ioctl(fd, TIOCSETP, &tparam); /* apply changed parameters */

Modem State
Unix V7 had undocumented and probably unsupported commands for getting and setting a modem state. The original semantics of the  variable have been lost in the mist of time. On some implementations the later TIOCM_x macros for TIOCMGET/TIOCMSET are available and do also work with TIOCMODx. The TIOCM_x flags are:
 * ioctl(fd, TIOCMODG, int * state):Get modem state. Usually not implemented and not used. See TIOCMGET for getting the RS-232 control line status.
 * ioctl(fd, TIOCMODS, int * state):Set modem state. Usually not implemented and not used. See TIOCMSET for setting the RS-232 control lines.
 * TIOCM_LE: (not V7) Line enable signal
 * TIOCM_DTR: (not V7) Data terminal ready
 * TIOCM_RTS: (not V7) Request to send
 * TIOCM_ST: (not V7) Secondary transmit (?)
 * TIOCM_SR: (not V7) Secondary receive (?)
 * TIOCM_CTS: (not V7) Clear to send
 * TIOCM_CD, TIOCM_CAR: (not V7) Carrier detect
 * TIOCM_RI, TIOCM_RNG: (not V7) Ring indicator
 * TIOCM_DSR: (not V7) Data set ready

/********************************************************** * Set the RTS line if possible. * This mixes a TIOCM_x macro intended for TIOCMGET/TIOCMSET * with TIOCMODx and is not recommended. *********************************************************/ int state; ...   ioctl(fd, TIOCMODG, &state); state |= TIOCM_RTS; ioctl(fd, TIOCMODS, &state);
 * 1) if defined(TIOCM_RTS) && defined(TIOCMODG)
 * 1) endif

Terminal Parameters

 * ioctl(fd, TIOCGETP, struct sgttyb * data):Get the terminal parameters. They are stored in.
 * gtty(fd, struct sgttyb * data):Short version for TIOCGETP ioctl on some systems derived from V7.
 * ioctl(fd, TIOCSETP, struct sgttyb * data):Set the interface to the provided parameters. Waits until output has drained. Clears (throws away) any pending input data, and then applies the parameters.
 * stty(fd, struct sgttyb * data):Short version for TIOCSETP ioctl on some systems derived from V7.
 * ioctl(fd, TIOCSETN, struct sgttyb * data):Sets the interface to the provided parameters, but does not wait for drained output and does not clear input data. Depending on the hardware this used to generate some garbage input/output characters.

/********************************************************** * Print out current line configuration *********************************************************/ /* * Map speed constants (not available in all V7-style implementations) * to actual speed value. * Some platforms might offer more constants. Some platforms do allow * to use a simpler mapping, e.g. because of the numbering schema of their * Bx constants. */ long speed2long(int speed) { switch(speed) { case B0:   return 0; case B50:  return 50; case B75:  return 75; case B110: return 110; case B134: return 134; case B150: return 150; case B200: return 200; case B300: return 300; case B600: return 600; case B1200: return 1200; case B1800: return 1800; case B2400: return 2400; case B4800: return 4800; case B9600: return 9600; case EXTA: return 19200; case EXTB: return 38400; /*       * untypical, non V7 constants, better check if defined */      case B19200: return 19200; case B38400: return 38400; case B57600: return 57600; case B115200: return 115200; case B230400: return 230400; case B460800: return 460800; }   return -1; /* unknown, better update the code */ } /* * TODO: implement conversion function to decode flags * * flags are: * flag2str * #ifdef HUPCL *  if(flag & HUPCL) ...; // not original V7  * #endif *  if(flag & TANDEM) ...; *  if(flag & CBREAK) ...; *  if(flag & LCASE) ...; *  if(flag & ECHO) ...; *  if(flag & CRMOD) ...; *  if(flag & RAW) ...; *  if(!(flag & ANYP)) { *     ...; // no parity *  } else if((flag & ANYP) == ANYP) { *      ...;  *   } else *     if(flag & ODDP)  ...; *     if(flag & EVENP) ...; *  }  *   if((flag & ALLDELAY) { delay2str(flag); }  *  * delay2str(flag)  *   flag = flag & ALLDELAY;  *  *   if((flag & BSDELAY) == BS0) ...;  *   if((flag & BSDELAY) == BS1) ...;  *   if((flag & VTDELAY) == FF0) ...;  *   if((flag & VTDELAY) == FF1) ...;  *   if((flag & CRDELAY) == CR0) ...;  *   if((flag & CRDELAY) == CR1) ...;  *   if((flag & CRDELAY) == CR2) ...;  *   if((flag & CRDELAY) == CR3) ...;  *   if((flag & TBDELAY) == TAB0) ...;  *   if((flag & TBDELAY) == TAB1) ...;  *   if((flag & TBDELAY) == TAB2) ...;  * #ifdef TAB3  *   if((flag & TBDELAY) == TAB3) ...; // not original V7, there it was called XTABS  * #endif  * #ifdef XTABS  *   if((flag & TBDELAY) == XTABS) ...;  * #endif  *   if((flag & NLDELAY) == NL0) ...;  *   if((flag & NLDELAY) == NL1) ...;  *   if((flag & NLDELAY) == NL2) ...;  *   if((flag & NLDELAY) == NL3) ...;  */ struct sgttyb tparam; ... fd = open( ... ); ... ioctl(fd, TIOCGETP, &tparam); printf("Input line speed: %ld\n", speed2long(tparam.sg_ispeed)); printf("Output line speed: %ld\n", speed2long(tparam.sg_ospeed)); printf("Erase char: %x\n", tparam.erase); printf("Kill char:  %x\n", tparam.kill); printf("Flags: %x\n", tparam.flags); /* printf("Flags: %s\n", flag2str(tparam.flags));
 * 1) ifdef B19200
 * 1) endif
 * 2) ifdef B38400
 * 1) endif
 * 2) ifdef B57600
 * 1) endif
 * 2) ifdef B115200
 * 1) endif
 * 2) ifdef B230400
 * 1) endif
 * 2) ifdef B460800
 * 1) endif

/********************************************************** * Change line speed to 2400 baud * Keep all other interface parameters as-is. *********************************************************/ struct sgttyb tparam; ... fd = open( ... ); ... ioctl(fd, TIOCGETP, &tparam); /* get current values */ tparam.sg_ispeed = tparam.sg_ospeed = B2400; ioctl(fd, TIOCSETP, &tparam); /* apply changed parameters */

See section below for more details regarding the use of the   structure components.

Exclusive Mode

 * ioctl(fd, TIOCEXCL, NULL):Turn on exclusive mode. No other open is permitted on the device.
 * ioctl(fd, TIOCNXCL, NULL):Turn off exclusive mode. The device might be opened multiple times.

Flush

 * ioctl(fd, TIOCFLUSH, NULL) /* original */:Input and output data is flushed.
 * ioctl(fd, TIOCTSTP, NULL):Other name for
 * ioctl(fd, TIOCFLUSH, int * mode) /* later versions */:Flush input and/or output according to mode. Constants are defined in <tt>sys/file.h</tt>
 * 0 or (FREAD | FWRITE):Flush Input and output.
 * FREAD:Flush input.
 * FWRITE:Flush output.

?

 * ioctl(fd, TIOHMODE, data_p):?

Special Character State

 * ioctl(fd, TIOCGETC, struct tchars * data):Get the terminal state special characters from the device.
 * ioctl(fd, TIOCSETC, struct tchars * data):Set the terminal state special characters.

?

 * ioctl(fd, TIOCSETP, struct tchars * data):?

More Original Unix V7 sgtty.h ioctls
The following ioctls were all defined in the Unix V7 tty interface, but with a few exceptions not properly documented. The D ioctls were probably intended to control dialers (ACUs). The F ioctls are borrowed from file I/O. The M ioctls are actually intended for Unix/V7 special multiplexed (mxp) files - an Unix/V7 mechanism for inter-process communication. Why these ioctls are defined in sgtty.h is unclear, other mpx ioctls are defined in sys/mx.h instead.

 * DIOCLSTN:
 * DIOCNTRL:
 * DIOCMPX:
 * DIOCNMPX:
 * DIOCSCALL:
 * DIOCRCALL:
 * DIOCPGRP:

 * DIOCGETP:Per line-discipline get data.
 * DIOCSETP:Per line-discipline set data.

 * DIOCLOSE:
 * DIOCTIME:
 * DIOCRESET:
 * FIOCLEX:Set the close-on-exec flag for this file descriptor. If the process is spawned (forked/execed), the file descriptor will be closed by the exec system call. That way the spawned process doesn't inherit the open terminal interface.
 * FIONCLEX:Clear the close-on-exec flag for this file descriptor. If the process is spawned (forked/execed), the file descriptor will not be closed by the exec system call. That way the spawned process inherits the open terminal interface.
 * MXLSTN:Place the mpx file in listener mode.
 * MXNBLK:Use non-blocking mode for the mpx file.

Terminal ioctls acquired over time
There are quite some additional I/O controls which have been acquired over time and which enhance the Unix V7 teletype API. The following are the ones which are rather common. Later interfaces like termio and termios also added I/O controls. These are not listed here.

Sending a break signal can be performed with the following two commands:

 * ioctl(fd, TIOCSBRK, NULL):Set the break flag. Sends a break signal over the serial line. A break is an all-zero framing error.
 * ioctl(fd, TIOCCBRK, NULL):Clear the break flag. Stops sending a break signal.

A simplified way to send a one-second break looks as it follows:

ioctl(fd, TIOCSBRK, NULL); /* start break signal */ /* * The following blocks the process for one second. * This is "suboptimal" in real applications. * Using asynchronous I/O and alarm(2)/setitimer(2)/signal(2) * or similar system calls, plus a callback which, when called, * turns the break of, is a better alternative. * Also, the granularity of sleep is to rough, since * breaks of 250 ... 500 milliseconds are typical in * serial communication. */ sleep(1);                 /* wait one second */ ioctl(fd, TIOCCBRK, NULL); /* stop sending break signal */

The following commands can be used to control the RS-232 control lines:

 * ioctl(fd, TIOCSDTR, NULL):Set DTR (Data Terminal Ready) signal.
 * ioctl(fd, TIOCCDTR, NULL):Clear DTR (Data Terminal Ready) signal.

 * ioctl(fd, TIOCMODG, int * state):Get modem state. See below.
 * ioctl(fd, TIOCMODS, int * state):Set modem state. Allows to access all RS-232 control lines. The status of each line is indicated by a bit in the  argument. The bits have the following symbolic names:
 * TIOCM_CAR or TIOCM_CD:DCD . Data Carrier Detect
 * TIOCM_CTS:CTS - Clear to send
 * TIOCM_DTR:DTR - Data terminal ready
 * TIOCM_LE or TIOCM_DSR:DSR - Data set ready
 * TIOCM_RNG or TIOCM_RI:RNG - Ring indicator
 * TIOCM_RTS:RTS - Request to send
 * TIOCM_SR:Secondary RxD
 * TIOCM_ST:Secondary TxD

Depending on which of the above commands is available, DTR can, for example be set as it follows:

ioctl(fd, TIOCSDTR, NULL); or int state; ioctl(fd, TIOCMGET, &state); state |= TIOCM_DTR; ioctl(fd, TIOCMSET, &state);

 * ioctl(fd, TIOCSTOP, NULL):Stop output as if the stop character has been typed.
 * ioctl(fd, TIOCSTART, data_p):Restart output as if the start character has been typed.

 * ioctl(fd, TIOCLGET, int * flags):Get the terminal flags. See element  of   for the details.
 * ioctl(fd, TIOCLBIS, int * flags):Set particular terminal flags. The flags are or-ed with the currently already set flags.
 * ioctl(fd, TIOCLBIC, int * flags):Clear particular terminal flags. The flags are "not-and-ed" with the existing flags.
 * ioctl(fd, TIOCLSET, int * flags):Set the terminal flags.

 * ioctl(fd, TIOCGLTC, struct ltchars * data):Get ltchars data.
 * ioctl(fd, TIOCSLTC, struct ltchars * data):Set ltchars data.

 * ioctl(fd, FIORDCHK, NULL):Return the number of currently available input characters in the input buffer. The number is returned as the return value of the function call.
 * ioctl(fd, FIONREAD, int * nbr):Return the number of currently available input characters in the input buffer. The number is written in to the <tt>*nbt</tt> argument.

title: Serial Programming/Unix V7


text:
Serial Programming/termios

Introduction
termios is the newer (now already a few decades old) Unix API for terminal I/O. The anatomy of a program performing serial I/O with the help of termios is as follows:

 * Open serial device with standard Unix system call open(2)

 * Configure communication parameters and other interface properties (line discipline, etc.) with the help of specific termios functions and data structures.

 * Use standard Unix system calls read(2) and write(2) for reading from, and writing to the serial interface. Related system calls like readv(2) and writev(2) can be used, too. Multiple I/O techniques, like blocking, non-blocking, asynchronous I/O (select(2) or poll(2), or signal-driven I/O (  signal)) are also possible. The selection of the I/O technique is an important part of the application's design. The serial I/O needs to work well with other kinds of I/O performed by the application, like networking, and must not waste CPU cycles.

 * Close device with the standard Unix system call close(2) when done.

An important part when starting a program for serial I/I is to decide on the I/O technique to deploy.

The necessary declarations and constants for termios can be found in the header file. So code for serial or terminal I/O will usually start with

Some additional functions and declarations can also be found in the,  , and   header files.

The termios I/O API supports two different modes: ''doesn't old termio do this too? if yes, move paragraphs up to the general section about serial and terminal I/O in Unix).''

1. Canonical mode. This is most useful when dealing with real terminals, or devices that provide line-by-line communication. The terminal driver returns data line-by-line.

2. Non-canonical mode. In this mode, no special processing is done, and the terminal driver returns individual characters.

On BSD-like systems, there are three modes:

1. Cooked Mode. Input is assembled into lines and special characters are processed.

2. Raw mode. Input is not assembled into lines and special characters are not processed.

3. Cbreak mode. Input is not assembled into lines but some special characters are processed.

Unless set otherwise, canonical (or cooked mode under BSD) is the default. The special characters processed in the corresponding modes are control characters, such as end-of-line or backspace. The full list for a particular Unix flavor can be found in the corresponding termios man page. For serial communication it is often advisable to use non-canonical, (raw or cbreak mode under BSD) to ensure that transmitted data is not interpreted by the terminal driver. Therefore, when setting up the communication parameters, the device should also be configured for raw/non-canonical mode by setting/clearing the corresponding termios flags. It is also possible to enable or disable the processing of the special characters on an individual basis.

This configuration is done by using the  data structure, defined in the   header. This structure is central to both the configuration of a serial device and querying its setup. It contains a minimum of the following fields:

It should be noted that real  declarations are often much more complicated. This stems from the fact that Unix vendors implement termios so that it is backward compatible with termio and integrate termio and termios behavior in the same data structure so they can avoid to have to implement the same code twice. In such a case, an application programmer may be able to intermix termio and termios code.

There are more than 45 different flags that can be set (via ) or got (via  ) with the help of the. The large number of flags, and their sometimes esoteric and pathologic meaning and behavior, is one of the reasons why serial programming under Unix can be hard. In the device configuration, one must be careful not to make a mistake.

open(2)
A few decisions have to be made when opening a serial device. Should the device be opened for reading only, writing only, or both reading and writing? Should the device be opened for blocking or non-blocking I/O (non-blocking is recommended)? And should the device be opened in exclusive mode so other programs cannot access the device once opened?

While open(2) can be called with quite a number of different flags controlling these and other properties, the following as a typical example:

Where:

 * device:The path to the serial port (e.g. /dev/ttyS0)
 * fd:The returned file handle for the device. -1 if an error occurred
 * O_RDWR:Opens the port for reading and writing
 * O_NOCTTY:The port never becomes the controlling terminal of the process.
 * O_NDELAY:Use non-blocking I/O. On some systems this also means the RS232 DCD signal line is ignored.

Note well: if present, the  flag is silently ignored by the kernel when opening a serial device like a modem.

On modern Linux systems programs like ModemManager will sometimes read and write to your device and possibly corrupt your program state. To avoid problems with programs like ModemManager you should set  on the terminal after associating a terminal with the device. You cannot open with  because it is silently ignored.

close(2)
Given an open file handle fd you can close it with the following system call

Serial Device Configuration
After a serial device has been opened you often perform two or three tasks to configure the device. First, you verify the device is indeed a serial device. Second, you configure terminal settings for the specific hardware. This step includes settings like baud rate or line discipline. And third, you optionally set exclusive mode on the terminal. Configuration can be a challenging task because the interface supports many hardware devices and there are over 60 termios flags. The example code below demonstrates the most important flags.

TTY Device
The first step in configuration is verifying a device is a. You can verify a device is a  using   as shown below.

Terminal Configuration
The second step in configuration is settings terminal attributes like baud rate or line discipline. This is done with a rather complex data structure using the tcgetattr(3) and tcsetattr(3) functions.

Exclusive Access
If you wish ensure exclusive access to the serial device then use  to set. If your system includes programs like ModemManager then you should set this attribute.

Note well: once you set  other programs will not be able to open the serial device. If your program architecture includes a separate reader and writer, then you should /  unique instances that inherit the file descriptor.

Line-Control Functions
termios contains a number of line-control functions. These allow a more fine-grained control over the serial line in certain special situations. They all work on a file descriptor fildes, returned by an open(2) call to open the serial device. In the case of an error, the detailed cause can be found in the global  variable (see errno(2)).

tcdrain
Wait until all data previously written to the serial line indicated by  has been sent. This means, the function will return when the UART's send buffer has cleared. If successful, the function returns 0. Otherwise it returns -1, and the global variable  contains the exact reason for the error.

Today's computer are fast, have more cores and code is subject to a lot of optimizations. Together they can cause strange results. In the example below:

You would expect a signal going up, the write and then a signal going down. But that did not happen though the programmer intended it. Perhaps optimization causes the kernel to report success to write before the data are really written.

Now the same code using tcdrain:

Now the code behaves as expected, because the clr_rts; is executed only when data really is written. Several programmers solve the problem by using sleep/usleep what may be not exactly what you want.

tcflow
This function suspends/restarts transmission and/or reception of data on the serial device indicated by fildes. The exact function is controlled by the action argument. action should be one of the following constants:
 * TCOOFF:Suspend output.
 * TCOON:Restarts previously suspended output.
 * TCIOFF:Transmit a   character. Remote devices are supposed to stop transmitting data if they receive this character. This requires the remote device on the other end of the serial line to support this software flow-control.
 * TCION:Transmit a   character. Remote devices should restart transmitting data if they receive this character. This requires the remote device on the other end of the serial line to support this software flow-control.

If successful, the function returns 0. Otherwise it returns -1, and the global variable  contains the exact reason for the error.

tcflush
Flushes (discards) not-sent data (data still in the UART send buffer) and/or flushes (discards) received data (data already in the UART receive buffer). The exact operation is defined by the queue_selector argument. The possible constants for queue_selector are:
 * TCIFLUSH:Flush received, but unread data.
 * TCOFLUSH:Flush written, but not send data.
 * TCIOFLUSH:Flush both.

If successful, the function returns 0. Otherwise it returns -1, and the global variable  contains the exact reason for the error.

tcsendbreak
Sends a break for a certain duration. The duration_flag controls the duration of the break signal:
 * 0:Send a break of at least 0.25 seconds, and not more than 0.5 seconds.
 * any other value:For other values than 0, the behavior is implementation defined. Some implementations interpret the value as some time specifications, others just let the function behave like tcdrain.

A break is a deliberately generated framing (timing) error of the serial data – the signal's timing is violated by sending a series of zero bits, which also encompasses the start/stop bits, so the framing is explicitly gone.

If successful, the function returns 0. Otherwise it returns -1, and the global variable  contains the exact reason for the error.

Reading and Setting Parameters
The Unix and Linux serial interface have more than 60 parameters due to the different hardware supported by the interface. This plethora of parameters and the resulting different interface configuration is what make serial programming in Unix and Linux challenging. Not only are there so many parameters, but their meanings are often rather unknown to contemporary hackers, because they originated at the dawn of computing, where things were done differently and are no longer known or taught in Little-Hacker School.

Nevertheless, most of the parameters of a serial interface in Unix are controlled via just two functions:

and
 * tcgetattr:For reading the current attributes.
 * tcsetattr:For setting serial interface attributes.

All information about the configuration of a serial interface is stored in an instance of the  data type. tcgetattr requires a pointer to a pre-allocated  where it will write to. tcsetattr requires a pointer to a pre-allocated and initialized  where it reads the values from.

Further, speed parameters are set via a separate set of functions:

 * cfgetispeed:Get line-in speed.
 * cfgetospeed:Get line-out speed.
 * cfsetispeed:Set line-in speed.
 * cfsetospeed:Set line-out speed.

The following sub-section explain the mentioned functions in more detail.

Attribute Changes
50+ attributes of a serial interface in Unix can be read with a single function: tcgetattr. Among these parameters are all the option flags and, for example, information about which special character handling is applied. The signature of that function is as it follows:

Where the arguments are:
 * fd:A file handle pointing to an opened terminal device. The device has typically be opened via the open(2) system call. However, there are several more mechanisms in Unix to obtain a legitimate file handle (e.g. by inheriting it over a fork(2)/exec(2) combo). As long as the handle points to an opened terminal device things are fine.
 * *attribs :A pointer to a pre-allocated, where tcgetattr will write to.

tcgetattr returns an integer that either indicates success or failure in the way typical for Unix system calls:

 * 0:Indicates successful completion
 * -1:Indicates failure. Further information about the problem can be found in the global (or thread-local)  variable. See the errno(2), intro(2), and/or perror(3C) man page for information about the meaning of the   values.

 * Note; it is a typical beginner and hacker error to not check the return value and assume everything will always work.

The following is a simple example demonstrating the use of tcgetattr. It assumes that standard input has been redirected to a terminal device:

Once the above program is compiled and linked, let's say under the name, it can be run as it follows:

./example < /dev/ttya

Assuming,  is a valid serial device. One can run stty to verify of the output is correct.

tcsetattr

Sets the termios struct of the file handle fd from the options defined in options. optional_actions specifies when the change will happen:
 * TCSANOW: the configuration is changed immediately.
 * TCSADRAIN: the configuration is changed after all the output written to fd has been transmitted. This prevents the change from corrupting in-transmission data.
 * TCSAFLUSH: same as above but any data received and not read will be discarded.

Baud-Rate Setting
Reading and setting the baud rates (the line speeds) can be done via the tcgetattr and tcsetattr function. This can be done by reading or writing the necessary data into the. The previous example for tcgetattr show how messy it can be when directly accessing the structure members.

Instead of directly accessing the structure members, it is recommended you use one of the following functions:

Which have the following signatures:
 * cfgetispeed:Get line-in speed.
 * cfgetospeed:Get line-out speed.
 * cfsetispeed:Set line-in speed.
 * cfsetospeed:Set line-out speed.

 * speed:The input baud rate.
 * attribs :The  from which to extract the speed.

 * speed:The output baud rate.
 * attribs :The  from which to extract the speed.

 * attribs :The  in which the input baud rate  should be set.
 * speed:The input baud rate that should be set.

The  parameter should be one of the predefined values, like ,  , or.

The function returns
 * 0:If the speed could be set (encoded).
 * -1:If the speed could not be set (e.g. if it is not a valid or supported speed value).

 * attribs :The  in which the output baud rate  should be set.
 * speed:The output baud rate that should be set.

The function returns
 * 0:If the speed could be set (encoded).
 * -1:If the speed could not be set (e.g. if it is not a valid or supported speed value).

Here is a simple example for cfgetispeed. cfgetospeed works very similar:

cfsetispeed and cfsetospeed work straight-forward, too. The following example sets the input speed of stdin to 9600 baud. Note, the setting will not be permanent, since the device might be reset at the end of the program:

Canonical Mode
Everything is stored into a buffer and can be edited until a carriage return or line feed is entered. After the carriage return or line feed is pressed, the buffer is sent.

where:

 * ICANON:Enables canonical input mode

Non-Canonical Mode
This mode will handle a fixed number of characters and allows for a character timer. In this mode input is not assembled into lines and input processing does not occur.Here we have to set two parameters time and minimum number of characters to be received before read is satisfied and these are set by setting VTIME and VMIN characters for example if we have to set Minimum number of characters as 4 and we don't want to use any timer then we can do so as follows-:

Misc.
There are a few C functions that can be useful for terminal and serial I/O programming and are not part of the terminal I/O API. These are

This function returns the device name of the current controlling terminal of the process as a string (e.g. "/dev/tty01"). This is useful for programs who want to open that terminal device directly in order to communicate with it, even if the controlling terminal association is removed later (because, for example, the process forks/execs to become a daemon process). *s can either be  or should point to a character array of at least L_ctermid bytes (the constant is also defined in stdio.h). If *s is, then some internal static char array is used, otherwise the provided array is used. In both cases, a pointer to the first element of the char array is returned

Checks if the provided file descriptor represents a terminal device. This can e.g. be used to figure out if a device will understand the commands send via the terminal I/O API.

This function returns the device name of a terminal device represented by a file descriptor as a string.

These I/O controls allow to get and set the window size of a terminal emulation, e.g. an xterm in pixel and character sizes. Typically the get variant (TIOCGWINSZ) is used in combination with a SIGWINCH signal handler. The signal handler gets called when the size has changed (e.g. because the user has resized the terminal emulation window), and the application uses the I/O control to get the new size.

Modems
Modems are still common for many users, like those people who use dialup connections in Central and South America and the Africas. Additionally, users who integrate with telephone company services will use modems for faxing and call blocking. Modems are also common in more modern applications that manage communications over cellular and other wireless networks as there are several wireless module vendors that offer system developers solutions that allow them to easily add wireless access to their product offerings. Those modules are often controlled via modem APIs. This section will provide configuration and operational information on modems.

Modem Configuration
There are usually two ways to configure a modem, give or take. First, you can modify the existing file descriptor. Second, you can use  and apply fresh configuration flags.

Modify an existing file descriptor would use code similar to below. The example is based on Mike Sweet's Serial Programming Guide for POSIX Operating Systems.

The second way to configure a modem is use  as shown below.

In both cases you should tune the  to your particular modem. You will have to consult the modem's documentation for settings like line discipline, start and stop bits, UART speed, etc.

Ring Count
Software that operates a modem connected to the telephone network often performs tasks like detect ring, collect Caller ID information, answer a call and play a message. The software will often maintain a state machine that depends upon the ring count.

The ring count can be retrieved from the  register by writing   and then reading the response. The response will be similar to the following with.

ATS1? 001 OK

A typical workflow sequence using the ring count is shown below.

RING # unsolicited message from the modem count = read S1 # program reads ring count NAME = JOHN DOE NMBR = 4105551212 DATE = 0101 # month and date TIME = 1345 # hour and minute RING count = read S1 RING count = read S1 RING count = read S1 ...

Some versions US Robotics modems, like the USR5637, have a firmware bug when reading the. The bug is, reading the  register destroys the Caller ID message. If you are using an affected USR modem your program will observe the following.

RING # unsolicited message from the modem count = read S1 # program reads ring count RING # No Caller ID message count = read S1 ...

If you use an affected modem you should not use the  register. Rather, maintain an internal timestamp that resets after 8 seconds. The code would look similar to the following.

Common Problems
Mike Sweet provides the following advice in Serial Programming Guide for POSIX Operating Systems:

 * don't forget to disable input echoing. Input echoing will cause a feedback loop between the MODEM and computer.
 * you must terminate modem commands with a carriage return (CR) and not a newline (NL). The C character constant for CR is.
 * make sure you use a baud that the MODEM supports. While many MODEMs do auto-baud detection, some have limits (19.2kbps is common) that you must observe.

Example terminal program
A simple terminal program with termios.h can look like this:

Warning: In this program the VMIN and VTIME flags are ignored because the O_NONBLOCK flag is set.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Serial Programming/termios


text:
Serial Programming/termio

Introduction
 (note the missing 's') is the older System V terminal I/O API. It has been replaced by  on modern systems. It is still in use on many systems, e.g. on embedded Unix systems or those based on Unix System V. Often modern systems still also provide the old API, too.

All settings to a serial device are done via the ioctl(2) system call, as opposite to the special functions as provided by .

Special Characters

 * INTR (default Ctrl-C or ASCII ETX)
 * QUIT (default Ctrl-\, or ASCII ES)
 * ERASE (default backspace or ASCII BS)
 * KILL (Ctrl-U, or ASCII NAK)
 * EOF (Ctrl-D, or ASCII EOT)
 * NL (ASCII LF)
 * EOL (ASCII LF)
 * STOP (Ctrl-S, or ASCII DC3)
 * START (Ctrl-Q, or ASCII DC1)

Primary commands
The main commands for controlling serial (terminal) I/O with termio all use an ioctl call of the form

ioctl(int fileDescriptor, int termioCommand, struct termio *arg);

The following commands use this ioctl form:

 * TCGETA
 * Get current parameters

ioctl(fileDescriptor, TCGETA, &params);
 * 1) include

 * TCSETA
 * Set parameters immediately

 * TCSETAW
 * Set parameters when output is empty (waits with change until all buffered data has been sent).

 * TCSETAF
 * Wait until output is empty, then flush input, then set parameters.

The struct termio argument as used in all the above ioctl(2) command looks as it follows:

 * struct termio

/* * Classic struct termio. More modern Unix versions * contain additional information. Unix versions who * support termio and termios often use the same * structure for termio and termios, so termio * contains the full termios data on this systems. */ struct termio { int c_iflag;	 /* input modes	 */ int c_oflag;	 /* output modes */ int c_cflag;	 /* control modes */ int c_lflag;	 /* local modes	 */ char c_cc[NCC];	 /* control chars */ };
 * 1) define NCC 8

 * c_cc array in struct termio
 * c_iflag input mode flag in struct termio
 * IGNBRK
 * BRKINT
 * IGNPAR
 * PARMRK
 * INPCK
 * ISTRIP
 * INLCR
 * IGNCR
 * ICRNL
 * IUCLC
 * IXON
 * IXANY
 * IXOFF
 * c_oflag output mode flag in struct termio
 * OPOST
 * OLCUC
 * ONLCR
 * OCRNL
 * ONOCR
 * ONLRET
 * OFILL
 * OFDEL
 * NLDLY
 * NL0
 * NL1
 * CRDLY
 * CR0
 * CR1
 * CR2
 * CR3
 * TABDLY
 * TAB0
 * TAB1
 * TAB2
 * TAB3
 * BSDLY
 * BS0
 * BS1
 * VTDLY
 * VT0
 * VT1
 * FFDLY
 * FF0
 * FF1
 * c_cflag in struct termio
 * B0, B50, B75, B110, B134, B150, B300, B600, B1200, B1800, B2400, B4800, B9600, B19200, B38400 This are to select baud rate
 * CSIZE
 * CS5, CS6, CS7, CS8 These are for setting data bit length, between 5..8
 * CSTOPB
 * CREAD
 * PARENB This is for enabling parity check
 * PARODD This is to select odd parity
 * HUPCL
 * CLOCAL
 * c_lflag in struct termio
 * ISIG
 * ICANON
 * XCASE
 * ECHO
 * ECHOE
 * ECHOK
 * ECHONL
 * NOFLSH

Additional Commands
The additional commands use the following form of ioctl calls:

ioctl(int fileDescriptor, int termioCommand, int arg);

The following termio commands use this form:

 * TCSBRK
 * Wait until output is empty (drain). Optionally, a break can be sent when this happens. In fact, this is the most common application

/* Convenience macros for the waitBreak cmd argument */ /* * Function for waiting until output is empty and opt. sending a break */ tcWaitBreak(int fileDescriptor, int cmd) { ioctl(fileDescriptor, TCSBRK, cmd); } /*  * Send break when output is empty */ tcBreak(int fileDescriptor) { tcWaitBreak(fileDescriptor, WAIT_N_BREAK); }
 * 1) include
 * 1) define WAIT_N_BREAK 0
 * 2) define WAIT_ONLY    1

 * TCXONC
 * Start or stop the output.

/* Convenience macros for the start/stop cmd argument */ /* * Function for starting /stopping output */ tcStartStop(int fileDescriptor, int cmd) { ioctl(fileDescriptor, TCXONC, cmd); } /*  * stop output */ tcStop(int fileDescriptor) { tcStartStop(fileDescriptor, STOP); } /*  * start output */ tcStart(int fileDescriptor) { tcStartStop(fileDescriptor, START); }
 * 1) include
 * 1) define STOP 0
 * 2) define START 1

 * TCFLSH
 * Flush the input, output, or both queues.

/* Convenience macros for the flush cmd argument */ /* * Function for flushing a terminal/serial device */ tcFlush(int fileDescriptor, int cmd) { ioctl(fileDescriptor, TCFLSH, cmd); }
 * 1) include <termio.h>
 * 1) define FLUSH_IN  0
 * 2) define FLUSH_OUT 1
 * 3) define FLUSH_BOTH 2

title: Serial Programming/termio


text: User:Mike.hinson/TestPage

title: User:Mike.hinson/TestPage


text: User:Sean Whitton

title: User:Sean Whitton


text:
User talk:206.45.107.12

Xania talk 22:24, 5 February 2007 (UTC)

title: User talk:206.45.107.12


text:
Chess Opening Theory/1. e4/1...c6/2. d4/2...d5/3. f3

= Caro–Kann Defence: Fantasy Variation =

3. f3
White bolsters their e-pawn and hopes to obtain a full pawn centre and a half-open f-file should Black take on e4. It has been used by Alexander Morozevich, the second-highest ranked player in the world (July 2008), with success. It can lead to original positions or transpose to the Steinitz Variation of the French Defence with the moves 3...e6 4. Nc3 Nf6 5. e5 Nfd7 6. f4 c5. The main independent line is 3...dxe4 4. fxe4 e5 5. Nf3 Bg4 6. Bc4 Nd7. Here Black's sixth move is essential; any move which fails to defend the e5 pawn would be a mistake due to Bxf7+ followed by Nxe5+ and Nxg4. If Black wishes to avoid taking on e4, other independent tries include 3...Qb6 (without or with a delayed ...e6) and 3...g6.


text:
User talk:TheGenius1

Hi TheGenius1,

Welcome to wikibooks, thanks for the work you have been putting into A-level Computing and we hope you enjoy your stay. Please feel free to add your details to A-level_Computing/Authors Pluke 23:24, 5 February 2007 (UTC)

title: User talk:TheGenius1


text:
Talk:MATLAB Programming/An alternative to MATLAB: Octave

The external link contains a number of possible listings of differences between the two languages, should come in handy. Thanks to the anon user for sharing this. Mattb112885 23:47, 5 February 2007 (UTC)

Dead Link
External link to ppt seems to be dead.


text:
Armenian/Grammar

This section deals primarily with the Eastern Armenian dialect, the primary dialect of the country of Armenia. During Armenia's time as part of the Soviet Union, the U.S.S.R. took steps to highly standardize the language. As a result, the grammar may seem rather systematic and tedious at times. However, because of the standarization, exceptions are very rare, and once a grammatical rule is memorized, it is almost universally applicable. Exceptions are so rare, in fact, that the majority of them will be discussed in subsequent sections.

Infinitives
Every Armenian verb consists of a root and one of five possible infinitive suffixes:-ել,-ալ,-անալ, -անել, or -ենալ. The root consists of everything in the word up until the suffix, and, with very few exceptions, will never change, no matter the tense.

Armenian, like many languages in its language-family, requires strict subject-verb agreement, which is usually indicated by the suffix of the conjugated verb, eliminating the need for personal pronouns.

Present Tense
There is only one present tense in Armenian, and though it's structured like English's present continuous tense, it can act as the present continuous (I am walking) or the simple present (I walk).

The Present tense is one of the few tenses in Armenian which has a single suffix, -ում, distributed equally, independent of the subject of the verb. The subject-verb agreement is then manifested through placement of a conjugated "to be" after the verb.

Լինել (to be)

եu եմ-I am (yes em)

դու եu-you(sing.) are (doo es)

նա է-he/she/it is (nah eh)

մենք ենք-we are (menk enk)

դուք եք-you(pl./form.) are (dook ek)

նրանք են-they are (nərank en)

Example: In կարդալ (to read), the suffix -ալ is replaced by the present tense marker -ում, followed by one of the six listed present forms of "to be".

Եu կարդում եմ-I reading am (yes kartoom em)

Դու կարդում եu-you (sing.) reading are (doo kartoom es)

Նա կարդում է-he/she/it reading is (nah kartoom eh)

Մենք կարդում ենք-we reading are (menk kartoom enk)

Դուք կարդում եք-you (pl./form.) reading are (dook kartoom ek)

Նրանք կարդում են-they reading are (nərank kartoom en)

If the verb ending is polysyllabic (-անալ, -անել, -ենալ), then only the final syllable, starting with the second vowel, is replaced by -ում.

Hence, մահանալ (to die) becomes մաhանում, and so on.

Negation

To negate the verb, simply add a չ to the beginning of the present "to be" (for the pronoun նա the present form of "to be" is written as ի) and switch its position to be before the verb.

Example: Նրանք չեն ուտում-They aren't eating (nərank chen ootoom)

Irregulars

Exceptions occur in monosyllabic verbs, such as գալ (to come) and տալ (to give) where the root is only marked by a single consonant. In cases such as these, the verb remains as it is, and the suffix -իu is added onto the end.

Example: Մենք գալիu ենք-we coming are (menk galees enk)

Another exception lies in the verb գիտենալ (to know). This verb is conjugated in the present by simply tacking on the present form of "to be" (for the pronoun նա the present form of "to be" is written as ի) onto the end of the root գիտ.

Example: Ես գիտեմ-I know (yes geetem)

Future Tense
There are two versions of the future tense in Armenian. The first and most common is marked by the prefix կ- added onto the root, as well as the final consonant in the infinitive suffix being replaced by the subject's corresponding end-marker.

Եu -մ

Դու  -u

Նա  -n/a

Մենք -նք

Դուք -ք

Նրանք -ն

Example: Հիանալ (to admire) becomes:

Ես կհիանամ I will admire (yes kәheeyanam)

Դու կհիանաս you (sing.) will admire (doo kәheeyanas)

Նա կհիանա  he/she/it will admire (nah kәheeyanah)

Մենք կհիանանք we will admire (menk kәheeyanank)

Դուք կհիանաք you (pl. form.) will admire (dook kәheeyanak)

Նրանք կհիանան they will admire (nrank kәheeyanan)

If the verb is an -ել or -անել  verb, and the subject is thid-person singular (նա), as usual, the լ  is dropped, but the ե that precedes it is changed to ի. So in the case of, for example, խոսել (to speak), the third-person singular version of it in the future tense would be կխոսի (kәkhosee) rather than կխոսե.

To negate, conjugate the verb as if it were in the third-person singular future, but without the կ, and put the a negated present tense "to be" before the verb.

Example: Դու չես գնա you will not go (doo ches gənah)

Another way to express the future tense would be to simply add an -ու to the end of the infinitive verb and follow it with a present tense "to be".

Example: Մենք հանդիպելու ենք (menk handeepeloo yenk) where the verb is hանդիպել (to meet).

This would be the equivalent to saying "we will be meeting", whereas մենք կհանդիպենք (menk kәhandeepenk) would more accurately be translated as simply "we will meet".

To negate, simply follow the same procedure as negating present tense verbs.

Դու չես գնալու you will not be going (doo ches gənaloo)

Past Tense
Armenian has a number of past tenses, all of which will be discussed in detail.

Preterite (simple past)

Just like English, this tense has the most variation and exceptions (though, generally these variations occur in groups rather than random exceptions, and the number of irregulars is not even close to the amount that exist in English). The bulk of Armenian verbs are conjugated similarly in the preterite tense, as the bulk of Armenian verbs are polysyllabic and end in either -ել or -ալ (as we saw in the present tense, irregulars tend to be entirely monosyllabic, or end with a polysyllabic infinitive stem).

In the case of -ել and -ալ verbs, remove the լ and replace it with the corresponding ending:

Եu -ցի

Դու  -ցիր

Նա  -ց

Մենք -ցինք

Դուք -ցիք

Նրանք -ցին

Example: Ասել (to say)

Եu ասեցի I said (yes ahsetsee)

Դու ասեցիր you (sing.) said (doo ahsetseer)

Նա ասեց he/she/it said (nah ahsets)

Մենք ասեցինք we said (menk ahsetseenk)

Դուք ասեցիք you (pl./form.) said (dook ahsetseek)

Նրանք ասեցին they said (nərank ahsetseen)

Մնալ (to stay/remain)

Եu մնացի I stayed (yes mənahtsee)

Դու մնացիր you (sing.) stayed (doo mənahtseer)

Նա մնաց he/she/it stayed (nah mənahts)

Մենք մնացինք we stayed (menk mənahtseenk)

Դուք մնացիք you (pl./form.) stayed (dook mənahtseek)

Նրանք մնացին they stayed (nərank mənahtseen)

Verbs which end with -անալ, -անել, or -ենալ are conjugated by replacing the նալ in the suffix with the corresponding stem:

Եu -ցա

Դու  -ցար

Նա  -ցավ

Մենք -ցանք

Դուք -ցաք

Նրանք -ցան

Example: Ստանալ (to receive)

Եu ստացա I received (yes stahtsah)

Դու ստացար you (sing.) received (doo stahtsar)

Նա ստացավ he/she/it received (nah stahtsav)

Մենք ստացանք we received (menk stahtsank)

Դուք ստացաք you (pl./form.) received (dook stahtsak)

Նրանք ստացան they received (nərank stahtsahn)

Many verbs which end in -նել (but not -անել) are conjugated similarly to -անալ verbs, but without the աց.

Example: Հասնել (to arrive)

Եu hասա

Դու hասար

Նա hասավ

Մենք hասանք

Դուք hասաք

Նրանք hասան

There is also a family of verbs in Armenian which end in -ցնել. These verbs in all other tenses are treated the same as normal -ել verbs (the ցն simply being treated as part of the root). These verbs indicate a caused action. For example, where սովորել (sovorel) means "to learn", սովորեցնել (sovoretsnel) means "to cause to learn" or in other words "to teach".

In the preterite tense, the ն in the stem becomes ր and from there it is treated like a normal -ել verb. So the first-person preterite of սովորեցնել becomes սովորեցրեցի.

Irregulars

Just as in the present tense, monosyllabic verbs tend to function under different rules. Գալ (to come) and տալ (to give) are the only two widely used monosyllabic verbs. There conjugations in the preterite are as follows:

Գալ (to come)

Եu եկա I came (yes yekah)

Դու եկար you (sing.) came (doo yekar)

Նա եկավ he/she/it came (nah yekav)

Մենք եկանք we came (menk yekank)

Դուք եկաք you (pl./form.) came (dook yekak)

Նրանք եկան they came (nərank yekan)

Տալ (to give)

Եu տվեցի I gave (yes təvetsee)

Դու տվեցիր you (sing.) gave (doo təvetseer)

Նա տվեց he/she/it gave (nah təvets)

Մենք տվեցինք we gave (menk təvetseenk)

Դուք տվեցիք you (pl./form.) gave (dook təvetseek)

Նրանք տվեցին they gave (nərank təvetseen)

Ուտել is also conjugated irregularly.

Եu կերա

Դու կերար

Նա կերավ

Մենք կերանք

Դուք կերաք

Նրանք կերան

The verb լինել (to be) can also be used to mean "to happen". When used in that context, it is conjugated as a normal verb, but an irregular one. The root turns into եղ- and it is conjugated the same as the preterite of գալ . Generally, the only practical sense in which the word would ever be used in this context is in the third-person singular: եղավ (yeghav), which literally means "it happened", as in "consider it done." Armenian speakers often say it in the same context as the English expression "okay" or "whatever".

Imperfect Past
To express the imperfect past tense, one would need to know the past conjugations of "to be".

եu էի-I was (yes eyee)

դու էիր-you(sing.) were (doo eyeer)

նա էր-he/she/it was (nah ehr)

մենք էինք-we were (menk eyeenk)

դուք էիք-you(pl./form.) were (dook eyeek)

նրանք էին-they were (nərank eyeen)

This is the tense through which one expresses continuous action in the past, such as "I was walking" or "we were talking". The rule is the same as in English. The verb is conjugated the same way as it is in the present tense (replacing the stem with -ում) and followed then followed by the past conjugation of "to be".

So whereas ես խմում եմ (yes khəmoom em) means I drinking am, ես խմում էի (yes khəmoom eyee) means I drinking was.

Negation follows exactly the same rule as in the present tense.

Ես բամբասում էի (yes bambasoom eyee) I was gossipping becomes ես չէի բամբասում (yes cheyee bambasoom) I wasn't gossipping.

Perfect Tense
The perfect tense is a way to express the past which is almost as widely used as the preterite. It sees a much more frequent distribution than its English equivalent.

If the verb is a standard -ել verb (no ն or ցն preceding it), then it does not change from its infinitive form and either a present or a past form of "to be" is placed after it.

Մենք ընտրել ենք (menk untrel enk) we have chosen

or

Մենք ընտրել էինք (menk untrel eyeenk) we had chosen

To negate, add չ to the beginning of the "to be" conjugation and place the word before the verb.

Նրանք չէին սկսել (nərank cheyeen skəsel) they hadn't started

If a ն precedes the -ել stem, such as in hասնել (to arrive), the ն is simply removed from the verb, becoming

Դու hասել ես (doo hahsel es) you (sing.) have arrived

The stem in all -ալ, -անալ, and -անել verbs becomes -ացել.

Example: Կշտանալ (to become full from eating) becomes կշտացել

Just as in the preterite tense, the ն in any -ցնել verb simply changes to a ր.

Example: Հեշտացնել (to simplify/make something easier) becomes հեշտացրել.

The stem in any -ենալ verb becomes -եցել.

Irregulars

The most commonly used irregulars are գալ  (to come), տալ (to give), լինել (to be), and ուտել (to eat).

գալ  becomes եկել

տալ becomes տվել

լինել becomes եղել

ուտել becomes կերել

Conditional
This tense can be used to express "would", and it can be used to denote future or past conditions, such as "I would go" or "I would have gone".

The conditional tense is expressed similarly to the future tense. The կ prefix is still tacked on to the beginning of the root, and the final լ is replaced the corresponding end marker.

For -ել and -անել verbs:

Եu -ի

Դու  -իր

Նա  -ր

Մենք -ինք

Դուք -իք

Նրանք -ին

Example: Ուղարկել (to send)

Եu կուղարկեի (yes k'ooghark'eyee) I would send/would have sent

Դու կուղարկեիր (doo k'ooghark'eyeer) you (sing.) would send/would have sent

Նա կուղարկեր (nah k'ooghark'er) he/she/it would send/would have sent

Մենք կուղարկեինք (menk k'ooghark'eyeenk) we would send/would have sent

Դուք կուղարկեիք (dook k'ooghark'eyeek) you (pl./form.) would send/would have sent

Նրանք կուղարկեին (nərank k'ooghark'eyeen) they would send/would have sent

For -ալ, -անալ, and -ենալ verbs, use the same endings, but precede them with յ, as Armenian phonetics does not allow for a shift from ա to ե without a semi-vowel between them (the exception being the third-person singular, as its conjugation does not contain ի).

Example: Ուշանալ (to be late)

Եu կուշանայի

Դու  կուշանայիր

Նա  կուշանար

Մենք կուշանայինք

Դուք կուշանայիք

Նրանք կուշանային

Passive
To express a passive action (I was understood rather than I understood), a վ is inserted into the verb, in most cases just before the suffix. Provided below are examples from all verb families.

Հիշել (to remember)

Հիշվել (to be remembered)

Present: Դու հիշվում ես doo heeshvoom es You are remembered (lit. you are being remembered)

Preterite: Նա հիշվեց nah heeshvets he/she/it was remembered

Future: Մենք կհիշվենք menk kəheeshvenk We will be remembered

Perfect: Նրանք hիշվել են nərank heeshvel en They have been remembered

Կարդալ (to read)

Կարդացվել (to be read)

Present: Գիրքը կարդացվում է geerkə k'artatsvoom eh The book is read (lit. the book is being read)

Preterite: Գիրքը կարդացվեց geerkə k'artatsvets The book was read

Future: Գիրքը կկարդացվի geerkə kək'artatsvee The book will be read

Perfect: Գիրքը կարդացվել է geerkə k'artatsvel eh The book has been read

Դժվարացնել (to make difficult)

Դժվարացվել (to be made difficult)

Present: Սրանք դժվարացվում են sərank dəzhvaratsvoom en These are being made difficult

Preterite: Սրանք դժվարացվեցին sərank dəzhvaratsvetseen These were made difficult

Future: Սրանք կդժվարացվեն sərank kədəzhvaratsven These will be made difficult

Perfect: Սրանք դժվարացվել են sərank dəzhvaratsvel en These have been made difficult

Խոստանալ (to promise)

Խոստացվել (to be promised)

Present: Դա խոստացվում է dah khostatsvoom eh That is being promised

Preterite: Դա խոստացվեց dah khostatsvets That was promised

Future: Դա կխոստացվի dah kəkhostatsvee That will be promised

Perfect: Դա խոստացվել է dah khostatsvel eh That has been promised

Խոստովանել (to confess/admit)

Խոստովացվել (to be confessed/admitted)

Present: Նրա մեղքերը խոստովացվում են nərah meghkerə khostovatsvoom en His sins are being confessed

Preterite: Նրա մեղքերը խոստովացվեցին nərah meghkerə khostovatsvetseen His sins were confessed

Future: Նրա մեղքերը կխոստովացվեն nərah meghkerə kəkhostovatsven His sins will be confessed

Perfect: Նրա մեղքերը խոստովացվել են nərah meghkerə khostovatsvel en His sins have been confessed

Կամենալ (to will/desire that something happen)

Կամեցվել (to be willed/desired)

Cases
Armenian has seven grammatical cases: nominative, dative, accusative, locative, ablative, genitive, and instrumental.

աԱբԲգԳդԴեԵզԶէԷըԸթԹժԺիԻլԼխԽծԾկԿհՀձՁղՂճՃմՄյՅնՆշՇոՈչՉպՊջՋռՌսՍվՎտՏրՐցՑւՒփՓքՔօՕՖև

title: Armenian/Grammar


text:
Category:Surinamese recipes

Recipes from Suriname.

title: Category:Surinamese recipes


text:
User talk:SweetSteffie

Hello and welcome to Wikibooks!

Here are some tips to help you get started:
 * You should sign your name on Talk and vote pages using four tildes, like this: ~~~~.
 * Remember to conduct any editing experiments in the sandbox.
 * If you're a Wikipedian, see Wikibooks for Wikipedians for a primer on how things work here (it's a little different).
 * If you want to base your work here on materials from Wikipedia, please use WB:RFI to bring the material over in compliance with the GFDL.
 * If you're an instructor and plan on using wikibooks for a class project, see Guidelines for class projects
 * Please say hello at the Staff Lounge with any questions or ideas.
 * Eventually, you might want to read the Manual of Style and Policies and Guidelines.
 * Please take a look at Naming policy before starting a new book.
 * Remember to maintain a Neutral point of view.
 * Explore, be bold in editing pages, and have fun!

You will find more resources in Community Portal. If you want to ask a question, visit the Study help desk, the Staff lounge, IRC channel or ask me personally on my talk page. For site news, see the Bulletin board. It might be an idea if you add this page to your "watchlist" so that you can see when any new information is posted there.

Good luck! You may also like to look at the Cookbook policy. I've taken the liberty of editing your Bojo recipe a little already, I hope you don't mind! Webaware talk 01:50, 6 February 2007 (UTC)

title: User talk:SweetSteffie


text:
Wikibooks:What is Wikijunior

The aim of Wikijunior is to produce non-fiction books for children from birth to age twelve. These books could take the form of macropedias, textbooks, or primers.

Wikijunior is a source of books for children written by an international community of volunteers. It is built on certain core values. Wikijunior is:
 * kid friendly. Our books are written with children in mind. The subjects of our books are chosen because they are appealing to kids. These books are richly illustrated with photographs, diagrams, sketches, and original drawings.
 * collaborative. Wikijunior books do not have just one author, instead they are the product of many interested people working together.
 * fun. We write books that are easy to understand and age-appropriate. The writing style is light and friendly.
 * reliable. Books present factual information that is verifiable and avoid opinion, original research, and fiction.
 * open. The world is invited to join in and write, edit, and rewrite each article and book to improve its content. Our books are distributed free of charge under the terms of the Creative Commons Share-Alike License.

If you discover a book or article that doesn't meet these standards, please be bold and fix it!

Development will happen online here at Wikibooks, and some of the finished books will go into print. In the future, a static online version of Wikijunior will be set up as a new project and "completed" versions will go there. However, even the "completed" versions will be updated from time to time with changes posted to Wikibooks.

Relationship with Wikibooks
Wikijunior is a part of the Wikimedia Foundation and Wikibooks and is subject to their rules and policies. Wikijunior also has its own set of guidelines in addition to those. Sometimes Wikijunior policy differs from policy on the rest of Wikibooks—for example, a macropedia (an in-depth encyclopedia on a specific topic) is allowed on Wikijunior even though it is not generally allowed on the rest of Wikibooks.

ja:Wikijunior:ウィキジュニアについて tr:Vikikitap:Vikiçocuk nedir?

title: Wikibooks:What is Wikijunior


text:
Orthopaedic Surgery/Fractures and Dislocations:Forearm and Wrist

A fracture of the distal radius is the most common skeletal injury which is referred for acute orthopedic management. Recently volar locking plates as well as more comprehensive plating systems have come to effect the mode of treatment for this injury and in typical fashion have been adopted rather broadly to the treatment of an injury which can often be well managed by closed manipulation and immobilization. Decision making regarding choice of treatment is governed by context, ease of care, risk and benefit and expectation of outcome. What may have been an acceptable result allowing for deformity may no longer be considered acceptable. Traditionally the treatment goal is a pain free wrist achieved within a predictable and reasonable time frame allowing for return of strong grip, range of motion of the wrist and fingers. This result is still readily achievable by closed means for the majority of fractures of the distal radius, especially those which result from what is the most common mechanism, that being low energy trauma from a fall.

Patient expectation tends to shift. They will expect to hear about an operative alternative which offers early motion in a removable splint and a more predictable restoration of anatomical relationships and perhaps and enhanced prospect for a return to full function. They will increasingly be familiar with friends and family similarly treated. Other patients will remain pleased to hear that surgery may be avoidable and will be quite willing to put up with some short term inconvenience and even the prospect of residual deformity in order to avoid the cost and risk of surgery.

The process of informed consent will reveal which sentiment will hold sway in the patients decision making and thus skill in achieving the desired result by either operative or closed means will continue. The artful orthopedist will acquire a sense of which direction is best to advise weighing many factors in a calculus he or she will be at a loss to explain. Sometimes the wrong choice will be made and the patient will experience difficulties despite the best assessment that can be offered. An unexpectedly poor outcome will likely effect the subsequent treatment advise of the orthopedist and in this way his or her practice pattern will evolve. A ruptured tendon or infection subsequent to plating, or a malunion and stiff fingers following closed management.


text:
This Quantum World/Appendix/Vectors

Vectors (spatial)
A vector is a quantity that has both a magnitude and a direction. Vectors can be visualized as arrows. The following figure shows what we mean by the components $$(a_x,a_y,a_z)$$ of a vector $$\mathbf{a}.$$

The sum $$\mathbf{a}+\mathbf{b}$$ of two vectors has the components $$(a_x+b_x,a_y+b_y,a_z+b_z).$$

 * Explain the addition of vectors in terms of arrows.

The dot product of two vectors is the number

 * $$\mathbf{a}\cdot\mathbf{b}=a_xb_x+a_yb_y+a_zb_z.$$

Its importance arises from the fact that it is invariant under rotations. To see this, we calculate

 * $$(\mathbf{a}+\mathbf{b})\cdot(\mathbf{a}+\mathbf{b})=

(a_x+b_x)^2+(a_y+b_y)^2+(a_z+b_z)^2=$$
 * $$a_x^2+a_y^2+a_z^2+b_x^2+b_y^2+b_z^2+2\,(a_xb_x+a_yb_y+a_zb_z)=

\mathbf{a}\cdot\mathbf{a}+\mathbf{b}\cdot\mathbf{b}+2\,\mathbf{a}\cdot\mathbf{b}.$$

According to Pythagoras, the magnitude of $$\mathbf{a}$$ is $$a=\sqrt{a_x^2+a_y^2+a_z^2}.$$ If we use a different coordinate system, the components of $$\mathbf{a}$$ will be different: $$(a_x,a_y,a_z)\rightarrow(a'_x,a'_y,a'_z).$$ But if the new system of axes differs only by a rotation and/or translation of the axes, the magnitude of $$ \mathbf{a}$$ will remain the same:

\sqrt{a_x^2+a_y^2+a_z^2}=\sqrt{(a'_x)^2+(a'_y)^2+(a'_z)^2}.$$

The squared magnitudes $$\mathbf{a}\cdot\mathbf{a},$$ $$\mathbf{b}\cdot\mathbf{b},$$ and $$(\mathbf{a}+\mathbf{b})\cdot(\mathbf{a}+\mathbf{b})$$ are invariant under rotations, and so, therefore, is the product $$ \mathbf{a}\cdot\mathbf{b}.$$

 * Show that the dot product is also invariant under translations.

Since by a scalar we mean a number that is invariant under certain transformations (in this case rotations and/or translations of the coordinate axes), the dot product is also known as (a) scalar product. Let us prove that

\mathbf{a}\cdot\mathbf{b}=ab\cos\theta,$$

where $$\theta$$ is the angle between $$\mathbf{a}$$ and $$\mathbf{b}.$$ To do so, we pick a coordinate system $$\mathcal{F}$$ in which $$\mathbf{a}=(a,0,0).$$ In this coordinate system $$\mathbf{a}\cdot\mathbf{b}=ab_x$$ with $$b_x=b\cos\theta.$$ Since $$\mathbf{a}\cdot\mathbf{b}$$ is a scalar, and since scalars are invariant under rotations and translations, the result $$\mathbf{a}\cdot\mathbf{b}=ab\cos\theta$$ (which makes no reference to any particular frame) holds in all frames that are rotated and/or translated relative to $$\mathcal{F}.$$

We now introduce the unit vectors $$\mathbf{\hat x},\mathbf{\hat y},\mathbf{\hat z},$$ whose directions are defined by the coordinate axes. They are said to form an orthonormal basis. Ortho because they are mutually orthogonal:

\mathbf{\hat x}\cdot\mathbf{\hat y}=\mathbf{\hat x}\cdot\mathbf{\hat z}=\mathbf{\hat y}\cdot\mathbf{\hat z}=0.$$

Normal because they are unit vectors:

\mathbf{\hat x}\cdot\mathbf{\hat x}=\mathbf{\hat y}\cdot\mathbf{\hat y}= \mathbf{\hat z}\cdot\mathbf{\hat z}=1.$$

And basis because every vector $$\mathbf{v}$$ can be written as a linear combination of these three vectors — that is, a sum in which each basis vector appears once, multiplied by the corresponding component of $$\mathbf{v}$$ (which may be 0):

\mathbf{v}=v_x\mathbf{\hat x}+v_y\mathbf{\hat y}+v_z\mathbf{\hat z}.$$

It is readily seen that $$v_x=\mathbf{\hat x}\cdot\mathbf{v},$$ $$v_y=\mathbf{\hat y}\cdot\mathbf{v},$$ $$v_z=\mathbf{\hat z}\cdot\mathbf{v},$$ which is why we have that

\mathbf{v}=\mathbf{\hat x}\,(\mathbf{\hat x}\cdot\mathbf{v})+\mathbf{\hat y}\,(\mathbf{\hat y}\cdot\mathbf{v})+\mathbf{\hat z}\,(\mathbf{\hat z}\cdot\mathbf{v}).$$

Another definition that is useful (albeit only in a 3-dimensional space) is the cross product of two vectors:

\mathbf{a}\times\mathbf{b}=(a_yb_z-a_zb_y)\,\mathbf{\hat x}+(a_zb_x-a_xb_z)\,\mathbf{\hat y}+(a_xb_y-a_yb_x)\,\mathbf{\hat z}.$$

 * Show that the cross product is antisymmetric: $$\mathbf{a}\times\mathbf{b}=-\mathbf{b}\times\mathbf{a}.$$

As a consequence, $$\mathbf{a}\times\mathbf{a}=0.$$

 * Show that $$\mathbf{a}\cdot(\mathbf{a}\times\mathbf{b})=\mathbf{b}\cdot(\mathbf{a}\times\mathbf{b})=0.$$

Thus $$\mathbf{a}\times\mathbf{b}$$ is perpendicular to both $$\mathbf{a}$$ and $$\mathbf{b}.$$

 * Show that the magnitude of $$\mathbf{a}\times\mathbf{b}$$ equals $$ab\sin\alpha,$$ where $$\alpha$$ is the angle between $$\mathbf{a}$$ and $$\mathbf{b}.$$ Hint: use a coordinate system in which $$\mathbf{a}=(a,0,0)$$ and $$\mathbf{b}= (b\cos\alpha,b\sin\alpha,0).$$

Since $$ab\sin\alpha$$ is also the area $$A$$ of the parallelogram $$P$$ spanned by $$\mathbf{a}$$ and $$\mathbf{b},$$ we can think of $$\mathbf{a}\times\mathbf{b}$$ as a vector of magnitude $$A$$ perpendicular to $$P.$$ Since the cross product yields a vector, it is also known as vector product.

(We save ourselves the trouble of showing that the cross product is invariant under translations and rotations of the coordinate axes, as is required of a vector. Let us however note in passing that if $$\mathbf{a}$$ and $$\mathbf{b}$$ are polar vectors, then $$\mathbf{a}\times\mathbf{b}$$ is an axial vector. Under a reflection (for instance, the inversion of a coordinate axis) an ordinary (or polar) vector is invariant, whereas an axial vector changes its sign.)

Here is a useful relation involving both scalar and vector products:

\mathbf{a}\times(\mathbf{b}\times\mathbf{c})=\mathbf{b}(\mathbf{c}\cdot\mathbf{a})-(\mathbf{a}\cdot\mathbf{b})\mathbf{c}.$$

title: This Quantum World/Appendix/Vectors


text:
Miskito/Discussion

If you have any feedback, questions, comments or suggestions about Miskitu Aisas!, this is the place! Please bring this project to life with your comments and participation. Tingki pali! (thank you)

i=I am Very Impressive ==

Wow, this is an amazing wikibook! I think it's the best one I've seen on the whole of Wikiboks! I am trying to add you to the languages bookshelf to make it more visible. Poppy 20:17, 11 March 2007 (UTC)

 * Thank you for your comment (which I didn't see until today, unfortunately). Cheers, Alan --A R King 11:54, 25 August 2007 (UTC)

 * I am trying to learn miskito as part of a plan to go there and help.

This is a tremendous help because learning resources are scarce. I have learned how to express wanting something, but not how to express need separately from wanting. If I try to teach people to use self discipline in managing their affairs, this is a critical concept. Can anyone help with this?

Navigation
I must also agree with the above statement, this is probobly the best language wikibook. Anyway, it would be helpful if at the bottom of each lesson page there was a navigation templete to go to the next lesson. It is a little inconvenient to have to scroll up to the top of the page. Thanks!--122.164.151.90 06:34, 23 August 2007 (UTC)

 * Thanks for the praise and the suggestions! Alan --A R King 11:50, 25 August 2007 (UTC)

 * Okay, I've implemented your suggestion: what do you think? --A R King 14:55, 25 August 2007 (UTC)

Exercises
This is certainly the best language wikibook I've seen so far. I have no background in language teaching apart from learning English, some Latin and currently Spanish (apart from failed attempts to learn French and Italian); however, I'm currently working on a "wikibooklet" for a Spanish audio course under a creative commons license, i.e., I'm writing transcripts of the Spanish dialogues, vocabulary lists, and exercises for each lesson. I have some questions about how to do this:
 * I noticed that many of the templates of the Miskitu wikibook, which reveal answers/translations etc. by clicking, always reveal a bunch of answers at the same time. Is this done on purpose? Wouldn't it be better to reveal the answers individually in order to give the learner an immediate feedback for each question without revealing the answers of all questions?
 * In Miskito/Method there is a list of nine exercise types:
 * True or false: You give Miskito sentences, the learner says if what they say is write or wrong.
 * Order the sentences: You give a series of Miskito sentences out of order, the learner puts them into the right order to form a coherent text.
 * Miskito-English translation: You give the Miskito, the learner gives the English.
 * Order the words: You give a Miskito sentence with the words in the wrong order, the learner puts them in the right order to form a sentence.
 * Sentence transformation: You give a sentence, the learner changes it in the way you specify (e.g. changing singular to plural).
 * Filling in blanks: You give Miskito sentences with a part missing, the learner provides the missing part and completes the sentence.
 * Combining: You give one or more elements of a Miskito sentence (but not the whole sentence), the learner gives the whole sentence combining or manipulating the elements in the way you have specified.
 * English-Miskito translation: You give the English, the learner gives the Miskito.
 * Answering questions: You ask questions (in Miskito), the learner answers them (in Miskito).
 * I've ordered the types of exercises according to their difficulty (does everyone agree on the order?). My first question would be: does it make sense to have many different types of exercises just for the sake of variation? I recently worked through a Spanish audio course, which had the same four kinds of exercises for each lesson in a fixed order (1. translation of English words to Spanish words, 2. translation of sentences from English to Spanish, 3. role play (similar to asking and answering question in the foreign language), and 4. multiple-choice answers about the text) and my impression was that this fixed scheme of exercises establishes a certain routine, which I liked as a learner because after three lessons I knew exactly how the exercises work.

 * My second question would be, which exercises are the most important ones if I have limited resources to create them? If the goal of the exercises is to give users feed back on their abilities, I would think that English-foreign language translation and answering questions in the foreign language are the two most important exercises. If users can do this, they almost certainly are able to do all the other exercises. Or am I missing something?
 * In my experience a problem with answering questions in the foreign language is that I'm often missing vocabulary to express what I want to say and I need someone to check my answer because it is very often too different from the one or two possible answers that are proposed in a textbook. Thus, I would think that this type of exercise is more appropriate for a class room situation with a teacher than for a self-studying course.
 * Thus, I'm currently planning to have only translations from English to the foreign language. However, I realize that this might be rather difficult for users and therefore a bit frustrating. Therefore, the exercises come in three flavors of different difficulty: 1. given the English translation of one sentence of the lesson text, the user only has to remember the original sentence of the lesson text in the foreign language, 2. same as 1. with variations of the lesson text (but using the same vocabulary and exactly the same verb forms), 3. same as 1. but varying the person and gender (singular and plural, formal and informal, masculine and feminine). I think these restrictions simplify these translation exercises to a very manageable level while still practicing and testing the important ability to translate from English to the foreign language. (I should mention that the whole course I'm working on is for beginners; a more advanced course should probably provide more difficult translation exercises.) An important feature of this choice is that the creation of these kinds of exercises appears to be quite manageable even for a non-native speaker of the language taught by a text book. Any comments on this choice would be very welcome! --Martin Kraus (talk) 13:18, 29 September 2008 (UTC)

Sound?
This is an interesting featured book. But it would be really nice if at some point you can arrange to collect matching sound files for the exercises from a native speaker. Personally I'd just be curious how the sound changes in a non-European language with different word order when people say things with different meanings but the same text, e.g. "Good job!" honestly vs. sarcastically, or how questions are asked with perhaps non-rising tone endings (e.g. English "Would you like me to put it there?" when "there" is already a known location and stress goes on "like" or "put"). Wnt (talk) 02:25, 24 March 2009 (UTC)

title: Miskito/Discussion


text:
JET Database/Object names and constants

Naming objects in the database
As with most other SQL databases, care is recommended when naming database objects such as tables, columns, indexes, views and stored procedures. Using names outside the normal naming conventions can cause problems when writing SQL code to handle those objects, requiring such names to be qualified in SQL code. The conventions in JET are:

 * names must begin with an alphabetic character (a-z or A-Z)
 * names must contain only alpha-numeric characters or the underscore
 * names must not be reserved words

Qualifying special names
There are occasions when objects are given names that cause problems in SQL statements, either by including special characters like spaces, or by using reserved words. Sometimes this is legitimate, other times it isn't, but either way the situation needs to be handled.

In such circumstances, the object names can be qualified in one of the following ways:
 * wrapping the name in (square) brackets,
 * wrapping the name in left single quotes (grave accents),

Here are some examples:

Complex Column Name a/b % Output Complex Text Name - 1.45                     First attempt

Text constants
Text constants can either be written with single quote (apostrophe) delimiters or double quote delimiters. Any instances of the delimiters used within the text constant need to be doubled.

T1                            T2 -- -- Eat the "food" at O'Malley's  Eat the "food" at O'Malley's

Numeric constants
Numeric constants can take the form of:

 * plain integers –
 * decimal numbers –
 * decimal numbers in scientific notation –  (equates to 12,345,000)

Numeric constants cannot have commas, dollar signs or other non-numeric characters other than the decimal point or the E in scientific notation.

Date/time constants
Date and time constants are best written as hash-delimited strings, either in long textual format, US date format or in ODBC date format.

Select #26 October 2007 6:43pm# As D_Long_Format, go
 * 1) 10/26/2007 18:43:00# As D_US_Format,
 * 2) 2007-10-26 18:43:00# As D_ODBC_Format

D_Long_Format          D_US_Format             D_ODBC_Format --- --- --- 26/10/2007 18:43:00    26/10/2007 18:43:00     26/10/2007 18:43:00

NB: JET does not unambiguously accept dates in other formats! Specifying a date in, for example, will appear to work correctly when there is no possibility of interpreting that date in US date format, otherwise it will be interpreted incorrectly, no matter what regional settings are in use. To remove ambiguity, it is best to specify dates in ODBC format.

Reserved words
This is a list of the reserved words in JET. Not all of these words will cause problems when used as object names, as at JET 4.0, but may in a future version of JET.

title: JET Database/Object names and constants


text:
Talk:QBasic/What Next

Notes on the Websites
These are websites that I am recommending and that have helped me in programming with QBasic. If anyone wants to help by recommending more, please do so. --Grich 08:20, 6 February 2007 (UTC)

title: Talk:QBasic/What Next


text: Miskito/Lesson 9

title: Miskito/Lesson 9


text:
Cookbook:Polvorones (Spanish Shortbread)

| Spanish cuisine

Polvorones are a type of Spanish shortbread quite popular in Latin America.

Ingredients

 * 1 cup margarine
 * 1 cup white sugar
 * ½ tsp salt
 * 4 cups all-purpose flour
 * 2 eggs
 * 1 tsp vanilla extract

Procedure

 * 1) Preheat oven to 350°F (180°C)
 * 2) Mix the margarine and the sugar in a mixing bowl until it reaches a creamy consistency.
 * 3) Mix in the vanilla extract, salt, and eggs.
 * 4) While mixing the ingredients, add the flour and stir until it becomes hard to stir the mix.
 * 5) Make small balls and place on a flat baking sheet without grease.
 * 6) Bake for 15–20 minutes in the preheated oven, or until golden.
 * 7) Let cool.


text:
User talk:82.47.165.150

Hi Thanks for the Risk Assessment on the Titration page. I made it into a table. Ewen 13:17, 6 February 2007 (UTC)

title: User talk:82.47.165.150


text:
Wikibooks:WikiProject Bartending/To do

 When one of these tasks is completed, please remove it from the list and add your achievement to the project log.

Our more experienced WikiProject editors are working on the project infrastructure and classifying pages. Your assistance is welcome.

 * Critical improvements needed:

To Merge
 * Feel free to add some to this list.

To Merge or Delete - Either merge into an existing, related page or delete as appropriate. Transwikiing to List of cocktails or some other Wikipedia article might be a good idea, too.
 * Feel free to add some to this list.

To De-orphan
 * No known orphans at this time.

To De-stub - (see also )
 * Feel free to add some to this list.

To Create
 * Feel free to add some to this list.

 * Collaboration needed:

To Clean up - please add articles needing cleanup to this list.
 * Feel free to add some to this list.

To Expand
 * Feel free to add some to this list.

Images Wanted
 * Feel free to add some to this list.

Lists to complete
 * Feel free to add some to this list.

 * Special projects

 * Once created, add WPBARInfobox to appropriate detail pages.
 * Add WPMIX to the talk pages of all pages within the scope of the Project.
 * Send a newsletter to Participants, canvas for new Participants, and coordinate tasks.

title: Wikibooks:WikiProject Bartending/To do


text: Category:WikiProject Bartending

title: Category:WikiProject Bartending


text:
Wikibooks talk:WikiProject Bartending/Participants

Welcome
Hello. This page is for Project Participants to introduce themselves and tell a little about their background and interests in bartending and mixology. If you are a Participant, please add a new section with your WikiBooks name for the topic and describe yourself and your reasons for participating in and goals to achieve through this WikiProject. Thanks!

Willscrlt
Hello. I got involved with the related Wikipedia Mixed Drinks WikiProject in late November 2006. At the time, the List of cocktails was in very bad shape. A few edits turned into well over a thousand edits in that article and the articles linked from that page. I quickly realized that this was too big of a job for one person, and I worked to revive the WikiProject responsible for overseeing these articles.

Along the way, I encountered the WikiBooks Bartending Guide. I think it holds great potential, but, sadly, it seems to often just be a dumping ground for bits of rejected information from Wikipedia that had nowhere else to go. I hope that this Project can help to change that. Whether or not the Bartending Guide becomes a true text book book for student mixologists or just a great reference for enthusiast home bartenders, I think the Guide, good as it is already, can be improved. And it will help if there is plenty of open communication between Wikipedia and Wikibooks so WikiBooks can cease being Wikipedia's dumping grounds.

I have made several goofs along the way, but all with the best of intentions. :-) Fortunately there are a lot of great people both here and at Wikipedia who offer help when you need it. I have found that even when I think my way is best, there is usually a better way to do things. Therefore, I am a pretty open-minded person, even if I seem a bit hesitant at first. I have invested a lot of time and effort into improving the topics related to these WikiProjects.

This is rather ironic, considering that I rarely drink mixed drinks, alcoholic or otherwise. My knowledge on the subject has increased dramatically, but I am still far from an expert when it comes to details about the various drinks. I am a quick learner, an effective researcher, a decent copy editor, and a good organizer. These are all talents that have been put to the test since getting involved in this WikiProject.

My favorite alcoholic drinks: Mai Tai (if a blender is available) or a Rum & Coke if not. Favorite non-alcoholic drinks: water and tea.

--Willscrlt (Talk·Cntrb ) 14:40, 25 January 2007 (UTC)


text: Category:WikiProject Bartending talk pages


text:
Programmable Logic/Verilog Control Structures

Procedural Code
Verilog has a number of high-level control structures that can be used to perform complicated tasks with some level of abstraction. These control structures should be familiar to people who have experience programming in high-level computer software languages, such as C or Java.

It is important to note that not all constructs in verilog are compatible with these high-level control structures. Wires and continuous assignments are not generally compatible with these structures, and trying to combine them may either lead to compiler errors or synthesis errors.

If-Else
IF structures test a particular condition, and execute the following code statement if that condition is true. Following an IF block can be an optional ELSE block, that will be executed if the condition is not true.

IF-ELSE structures can be expanded to account for more than two possibilities by nesting. The pseudocode example below demonstrates this:

if else if else if ... else

It is worth noting that additional resources will be generated to handle conditions that aren't accounted for in the IF-ELSE chain. This means that it is typically more efficient to account for all possibilities than to ignore some.

While
A WHILE loop executes repeatedly, so long as the condition is true. The condition is tested before each execution of the loop.

Switch-Case
SWITCH-CASE structures are similar to nested IF-ELSE structures, except they tend to reduce to more efficient hardware structures.

 * SWITCH:
 * CASE:
 * CASEX:
 * CASEZ:

Code Blocks
Code blocks are designated through use of the keywords begin and end. Code blocks can be put anywhere that a single statement is valid, but where more than one statement needs to be executed.

Code blocks can be nested.

Variables declared in a code block are lexically scoped to that block.

Naming and leaving Code Blocks
Above described blocks of code can be named, like begin : somename .... end In combination with the prior described loop constructs, a superior equivalence of Verilog to the break command in C is disable, which receives the name of the block to leave as an argument: while(1) begin : infiniteLoop <... statements ...> if (somecondition) disable infiniteLoop; <... statements ...> end In testbeds, one may also decide to use $finish or $stop to break from an execution.


text:
General Astronomy/Fusion in the Sun

Fusion is the energy process in the Sun. Fusion means "putting together" to form something different. In this case it is hydrogen nuclei, which are simply protons, coming together to form a somewhat more complex helium nucleus. The specific process in the Sun is called the Proton-proton chain because it involves a series of interactions in which protons build up the helium nucleus, leaving additional leftover protons that can start the process over again, hence a "chain."

This process is sometimes referred to as thermonuclear fusion. "Thermo" because it occurs only at very high temperatures, and "nuclear" because unlike everyday energy processes such as burning gasoline, it directly involves only the nuclei of atoms.

In order for positively charged protons to come together to form a helium nucleus, they must overcome their natural electrical repulsion of each other. This repulsion is known as the Coulomb Barrier. The only way this can happen is if the protons are packed tightly together and are moving very rapidly. Basically this means that they must be in a highly compressed and extremely hot gas. In fact, at such high pressures and temperatures, it is too hot and energetic for electrons to stay connected to the protons to form normal atoms. Instead, there is a mixture of free electrons and protons in a kind of particle soup. This kind of particle (rather than molecular) gas is called a plasma and is the situation in the core of the Sun. Here the protons are moving so fast that—aided by properties of quantum physics—they sometimes slam into each other with enough force that they overcome the Coulomb Barrier and touch. At that point, nuclear forces come into play to "glue" the protons together in spite of their electrical repulsion. Through a series of such events, attended by the creation of exotic particles such as the neutrino and positron, a helium nucleus with two protons and two neutrons is produced. Two additional protons are left over and can continue the chain.

Physicists have measured the mass of a helium nucleus such as is produced in the core of the Sun. It turns out that it is a little less than 4 times the mass of the 4 protons that created it. This "mass deficit" is partly due to the positrons and neutrinos produced in the process. But even considering that, there is still a little of the mass that is missing. That mass was converted into energy by Einstein's famous equation, E=MC^2 ("Energy equals mass times the speed of light squared."). This is how the Sun produces energy.

At the Sun's core roughly 600 million tons of hydrogen (protons) is converted into about 596 million tons of helium each second. The mass deficit of about 4 or 5 million tons is converted directly into energy as per the paragraph above.

All of the Sun's energy is produced in this manner at the core of the Sun. The energy is vibrational (heat) as well as in the form of high energy gamma rays. The energy from the gamma rays slowly works its way out from the core of the Sun, changing many, many times into longer wavelength radiation. By they time it reaches the surface, it consists mostly of visible light photons.

[We should point out that because it involves only atomic nuclei, fusion is fundamentally different from any process normally encountered on Earth. Ordinary chemical reactions do not involve nuclei, but rather the electrons in the outer shells of atoms. Although the production of energy in "ordinary" situations do not involve the nuclei (and so do not change the elemental nature of matter), they still operate via Einstein's equation and there still is a tiny loss of mass when any energy is produced. However, it is much less than in nuclear reactions and is not normally even measurable.]

title: General Astronomy/Fusion in the Sun