GROFFER(1) GROFFER(1) NAME groffer - display groff files and man pages on X and tty SYNOPSIS groffer [option ...] [--] [filespec ...] groffer -h|--help groffer -v|--version DESCRIPTION The groffer program is the easiest way to use groff(1). It can display arbitrary documents written in the groff language, see groff(7), or other roff languages, see roff(7), that are compatible to the original troff language. It finds and runs all necessary groff preprocessors, such as chem. The groffer program also includes many of the features for finding and displaying the Unix manual pages (man pages), such that it can be used as a replacement for a man(1) program. Moreover, compressed files that can be handled by gzip(1) or bzip2(1) are decompressed on-the-fly. The normal usage is quite simple by supplying a file name or name of a man page without further options. But the option handling has many pos‐ sibilities for creating special behaviors. This can be done either in configuration files, with the shell environment variable $GROFFER_OPT, or on the command line. The output can be generated and viewed in several different ways avail‐ able for groff. This includes the groff native X Window viewer gxditview(1), each Postcript, pdf, or dvi display program, a web browser by generating html in www mode, or several text modes in text terminals. Most of the options that must be named when running groff directly are determined automatically for groffer, due to the internal usage of the grog(1) program. But all parts can also be controlled manually by argu‐ ments. Several file names can be specified on the command line arguments. They are transformed into a single document in the normal way of groff. Option handling is done in GNU style. Options and file names can be mixed freely. The option `--' closes the option handling, all following arguments are treated as file names. Long options can be abbreviated in several ways. OPTION OVERVIEW breaking options [-h~| --help] [-v~| --version] groffer mode options [--auto] [--default] [--default-modes mode1,mode2,...] [--dvi] [--dvi-viewer prog] [--groff] [--html] [--html-viewer prog] [--mode display_mode] [--pdf] [--pdf-viewer prog] [--ps] [--ps-viewer prog] [--source] [--text] [--to-stdout] [--tty] [--tty-viewer prog] [--www] [--www-viewer prog] [--x --X] [--x-viewer --X-viewer] options related to groff [-T~| --device device] [-Z~| --intermediate-output~| --ditroff] All further groff short options are accepted. options for man pages [--apropos] [--apropos-data] [--apropos-devel] [--apropos-progs] [--man] [--no-man] [--no-special] [--whatis] long options taken over from GNU man [--all] [--ascii] [--ditroff] [--extension suffix] [--locale language] [--local-file] [--location~| --where] [--manpath dir1:dir2:...] [--no- location] [--pager program] [--sections sec1:sec2:...] [--systems sys1,sys2,...] [--troff-device device] Further long options of GNU man are accepted as well. X Window Toolkit options [--bd~| --bordercolor pixels] [--bg~| --background color] [--bw~| --borderwidth pixels] [--display X-display] [--fg~| --foreground color] [--fn~| --ft~| --font font_name] [--geometry size_pos] [--resolution value] [--rv] [--title string] [--xrm X-resource] options for development [--debug] [--debug-filenames] [--debug-grog] [--debug-keep] [--debug-params] [--debug-tmpdir] [--do-nothing] [--print text] [-V] filespec arguments The filespec parameters are all arguments that are neither an option nor an option argument. They usually mean a file name or a man page search‐ ing scheme. In the following, the term section_extension is used. It means a word that consists of a man section that is optionally followed by an exten‐ sion. The name of a man section is a single character from [1-9on], the extension is some word. The extension is mostly lacking. No filespec parameters means standard input. - stands for standard input (can occur several times). filename the path name of an existing file. man:name(section_extension) man:name.section_extension name(section_extension) name.section_extension section_extension name search the man page name in the section with optional exten‐ sion section_extension. man:name man page in the lowest man section that has name. name if name is not an existing file search for the man page name in the lowest man section. OPTION DETAILS The groffer program can usually be run with very few options. But for special purposes, it supports many options. These can be classified in 5 option classes. All short options of groffer are compatible with the short options of groff(1). All long options of groffer are compatible with the long options of man(1). Arguments for long option names can be abbreviated in several ways. First, the argument is checked whether it can be prolonged as is. Fur‐ thermore, each minus sign - is considered as a starting point for a new abbreviation. This leads to a set of multiple abbreviations for a single argument. For example, --de-n-f can be used as an abbreviation for --debug-not-func, but --de-n works as well. If the abbreviation of the argument leads to several resulting options an error is raised. These abbreviations are only allowed in the environment variable $GROFFER_OPT, but not in the configuration files. In configuration, all long options must be exact. groffer breaking Options As soon as one of these options is found on the command line it is exe‐ cuted, printed to standard output, and the running groffer is terminated thereafter. All other arguments are ignored. [-h|--help] Print a helping information with a short explanation of option sto standard output. [-v--version] Print version information to standard output. groffer Mode Options The display mode and the viewer programs are determined by these options. If none of these mode and viewer options is specified groffer tries to find a suitable display mode automatically. The default modes are mode pdf, mode ps, mode html, mode x, and mode dvi in X Window with different viewers and mode tty with device latin1 under less on a terminal; other modes are tested if the programs for the main default mode do not exist. In X Window, many programs create their own window when called. groffer can run these viewers as an independent program in the background. As this does not work in text mode on a terminal (tty) there must be a way to know which viewers are X Window graphical programs. The groffer script has a small set of information on some viewer names. If a viewer argument of the command-line chooses an element that is kept as X Window program in this list it is treated as a viewer that can run in the back‐ ground. All other, unknown viewer calls are not run in the background. For each mode, you are free to choose whatever viewer you want. That need not be some graphical viewer suitable for this mode. There is a chance to view the output source; for example, the combination of the op‐ tions --mode=ps and --ps-viewer=less shows the content of the Postscript output, the source code, with the pager less. --auto Equivalent to --mode=auto. --default Reset all configuration from previously processed command line op‐ tions to the default values. This is useful to wipe out all for‐ mer options of the configuration, in $GROFFER_OPT, and restart op‐ tion processing using only the rest of the command line. --default-modes mode1,mode2,... Set the sequence of modes for auto mode to the comma separated list given in the argument. See --mode for details on modes. Display in the default manner; actually, this means to try the modes x, ps, and tty in this sequence. --dvi Equivalent to --mode=dvi. --dvi-viewer prog Choose a viewer program for dvi mode. This can be a file name or a program to be searched in $PATH. Known X Window dvi viewers in‐ clude xdvi(1) and dvilx(1) In each case, arguments can be provided additionally. --groff Equivalent to --mode=groff. --html Equivalent to --mode=html. --html-viewer Choose a web browser program for viewing in html mode. It can be the path name of an executable file or a program in $PATH. In each case, arguments can be provided additionally. --modevalue Set the display mode. The following mode values are recognized: auto Select the automatic determination of the display mode. The sequence of modes that are tried can be set with the --default-modes option. Useful for restoring the default mode when a different mode was specified before. dvi Display formatted input in a dvi viewer program. By de‐ fault, the formatted input is displayed with the xdvi(1) program. --dvi. groff After the file determination, switch groffer to process the input like groff(1) would do. This disables the groffer viewing features. html Translate the input into html format and display the result in a web browser program. By default, the existence of a sequence of standard web browsers is tested, starting with konqueror(1) and mozilla(1). The text html viewer is lynx(1). pdf Display formatted input in a PDF (Portable Document Format) viewer program. By default, the input is formatted by groff using the Postscript device, then it is transformed into the PDF file format using gs(1), or ps2pdf(1). If that's not possible, the Postscript mode (ps) is used in‐ stead. Finally it is displayed using different viewer pro‐ grams. pdf has a big advantage because the text is dis‐ played graphically and is searchable as well. ps Display formatted input in a Postscript viewer program. By default, the formatted input is displayed in one of many viewer programs. text Format in a groff text mode and write the result to stan‐ dard output without a pager or viewer program. The text device, latin1 by default, can be chosen with option -T. tty Format in a groff text mode and write the result to stan‐ dard output using a text pager program, even when in X Window. www Equivalent to --mode=html. x Display the formatted input in a native roff viewer. By default, the formatted input is displayed with the gxditview(1) program being distributed together with groff. But the standard X Window tool xditview(1) can also be cho‐ sen with the option --x-viewer . The default resolution is 75 dpi, but 100 dpi are also possible. The default groff device for the resolution of 75 dpi is X75-12, for 100 dpi it is X100. The corresponding groff intermediate output for the actual device is generated and the result is dis‐ played. For a resolution of 100 dpi, the default width of the geometry of the display program is chosen to 850 dpi. X Equivalent to --mode=x. The following modes do not use the groffer viewing features. They are only interesting for advanced applications. groff Generate device output with plain groff without using the special viewing features of groffer. If no device was specified by option -T the groff default ps is assumed. source Output the roff source code of the input files without fur‐ ther processing. --pdf Equivalent to --mode=pdf. --pdf-viewer prog Choose a viewer program for pdf mode. This can be a file name or a program to be searched in $PATH; arguments can be provided addi‐ tionally. --ps Equivalent to --mode=ps. --ps-viewer prog Choose a viewer program for ps mode. This can be a file name or a program to be searched in $PATH. Common Postscript viewers inlude gv(1), ghostview(1), and gs(1), In each case, arguments can be provided additionally. --source Equivalent --mode=source. --text Equivalent to --mode=text. --to-stdout The file for the chosen mode is generated and its content is printed to standard output. It will not be displayed in graphical mode. --tty Equivalent to --mode=tty. --tty-viewer prog Choose a text pager for mode tty. The standard pager is less(1). This option is eqivalent to man option --pager=prog. The option argument can be a file name or a program to be searched in $PATH; arguments can be provided additionally. --www Equivalent to --mode=html. --www-viewer prog Equivalent to --html-viewer . --X~| --x Equivalent to --mode=x. --X-viewer -- x-viewer prog Choose a viewer program for x mode. Suitable viewer programs are gxditview(1) which is the default and xditview(1). The argument can be any executable file or a program in $PATH; arguments can be provided additionally. -- Signals the end of option processing; all remaining arguments are interpreted as filespec parameters. Besides these, groffer accepts all short options that are valid for the groff(1) program. All non-groffer options are sent unmodified via grog to groff. So postprocessors, macro packages, compatibility with classi‐ cal troff, and much more can be manually specified. Options related to groff All short options of groffer are compatible with the short options of groff(1). The following of groff options have either an additional spe‐ cial meaning within groffer or make sense for normal usage. Because of the special outputting behavior of the groff option -Z groffer was designed to be switched into groff mode ; the groffer viewing fea‐ tures are disabled there. The other groff options do not switch the mode, but allow to customize the formatting process. --a This generates an ascii approximation of output in the text modes. That could be important when the text pager has problems with con‐ trol sequences in tty mode. --mfile Add file as a groff macro file. This is useful in case it cannot be recognized automatically. --Popt_or_arg Send the argument opt_or_arg as an option or option argument to the actual groff postprocessor. --T devname ~| --device devname This option determines groff's output device. The most important devices are the text output devices for referring to the different character sets, such as ascii, utf8, latin1, and others. Each of these arguments switches groffer into a text mode using this de‐ vice, to mode tty if the actual mode is not a text mode. The fol‐ lowing devname arguments are mapped to the corresponding groffer --mode=devname option: dvi, html, and ps. All X* arguments are mapped to mode x. Each other devname argument switches to mode groff using this device. --X is equivalent to groff -X. It displays the groff intermediate output with gxditview. As the quality is relatively bad this op‐ tion is deprecated; use --X instead because the x mode uses an X* device for a better display. -Z~| --intermediate-output~| --ditroff Switch into groff mode and format the input with the groff inter‐ mediate output without postprocessing; see groff_out(5). This is equivalent to option --ditroff of man, which can be used as well. All other groff options are supported by groffer, but they are just transparently transferred to groff without any intervention. The options that are not explicitly handled by groffer are transparently passed to groff. Therefore these transparent options are not documented here, but in groff(1). Due to the automatism in groffer, none of these groff op‐ tions should be needed, except for advanced usage. Options for man pages --apropos Start the apropos(1) command or facility of man(1) for searching the filespec arguments within all man page descriptions. Each filespec argument is taken for search as it is; section specific parts are not handled, such that 7 groff searches for the two ar‐ guments 7 and groff, with a large result; for the filespec groff.7 nothing will be found. The language locale is handled only when the called programs do support this; the GNU apropos and man -k do not. The display differs from the apropos program by the follow‐ ing concepts: · Construct a groff frame similar to a man page to the output of apropos, · each filespec argument is searched on its own. · The restriction by --sections is handled as well, · wildcard characters are allowed and handled without a further option. --apropos-data Show only the apropos descriptions for data documents, these are the man(7) sections 4, 5, and 7. Direct section declarations are ignored, wildcards are accepted. --apropos-devel Show only the apropos descriptions for development documents, these are the man(7) sections 2, 3, and 9. Direct section decla‐ rations are ignored, wildcards are accepted. --apropos-progs Show only the apropos descriptions for documents on programs, these are the man(7) sections 1, 6, and 8. Direct section decla‐ rations are ignored, wildcards are accepted. --whatis For each filespec argument search all man pages and display their description — or say that it is not a man page. This is written from anew, so it differs from man's whatis output by the following concepts · each retrieved file name is added, · local files are handled as well, · the language and system locale is supported, · the display is framed by a groff output format similar to a man page, · wildcard characters are allowed without a further option. The following options were added to groffer for choosing whether the file name arguments are interpreted as names for local files or as a search pattern for man pages. The default is looking up for local files. --man Check the non-option command line arguments (filespecs) first on being man pages, then whether they represent an existing file. By default, a filespec is first tested whether it is an existing file. --no-man~| --local-file Do not check for man pages. --local-file is the corresponding man option. --no-special Disable former calls of --all , --apropos* , and --whatis . Long options taken over from GNU man The long options of groffer were synchronized with the long options of GNU man. All long options of GNU man are recognized, but not all of these options are important to groffer, so most of them are just ignored. These ignored man options are --catman , --troff , and --update . In the following, the man options that have a special meaning for groffer are documented. If your system has GNU man installed the full set of long and short op‐ tions of the GNU man program can be passed via the environment variable $MANOPT; see man(1). --all In searching man pages, retrieve all suitable documents instead of only one. -7--ascii In text modes, display ASCII translation of special characters for critical environment. This is equivalent to groff -mtty_char; see groff_tmac(5). --ditroff Produce groff intermediate output. This is equivalent to groffer -Z . --extensionsuffix Restrict man page search to file names that have suffix appended to their section element. For example, in the file name /usr/share/man/man3/terminfo.3ncurses.gz the man page extension is ncurses. --localelanguage Set the language for man pages. This has the same effect, but overwrites $LANG --location Print the location of the retrieved files to standard error. --no-location Do not display the location of retrieved files; this resets a for‐ mer call to --location . This was added by groffer. --manpath'dir1:dir2:...' Use the specified search path for retrieving man pages instead of the program defaults. If the argument is set to the empty string "" the search for man page is disabled. --pager Set the pager program in tty mode; default is less. This is equivalent to --tty-viewer . --sections'sec1:sec2:...' Restrict searching for man pages to the given sections, a colon- separated list. --systems'sys1,sys2,...' Search for man pages for the given operating systems; the argument systems is a comma-separated list. --where Eqivalent to --location . X Window Toolkit Options The following long options were adapted from the corresponding X Window Toolkit options. groffer will pass them to the actual viewer program if it is an X Window program. Otherwise these options are ig‐ nored. Unfortunately these options use the old style of a single minus for long options. For groffer that was changed to the standard with using a dou‐ ble minus for long options, for example, groffer uses the option --font for the X Window option -font . See X(7) and the documentation on the X Window Toolkit options for more details on these options and their arguments. --backgroundcolor Set the background color of the viewer window. --bdpixels This is equivalent to --bordercolor . --bgcolor This is equivalent to --background . --bw pixels This is equivalent to --borderwidth . --bordercolorpixels Specifies the color of the border surrounding the viewer window. --borderwidthpixels Specifies the width in pixels of the border surrounding the viewer window. --displayX-display Set the X Window display on which the viewer program shall be started, see the X Window documentation for the syntax of the ar‐ gument. --foregroundcolor Set the foreground color of the viewer window. --fgcolor This is equivalent to -foreground . --fn font_name This is equivalent to --font . --fontfont_name Set the font used by the viewer window. The argument is an X Window font name. --ftfont_name This is equivalent to --font . --geometrysize_pos Set the geometry of the display window, that means its size and its starting position. See X(7) for the syntax of the argument. --resolutionvalue Set X Window resolution in dpi (dots per inch) in some viewer pro‐ grams. The only supported dpi values are 75 and 100. Actually, the default resolution for groffer is set to 75 dpi. The resolu‐ tion also sets the default device in mode x. --rv Reverse foreground and background color of the viewer window. --title'some text' Set the title for the viewer window. --xrm'resource' Set X Window resource. Options for Development --debug Enable all debugging options --debug-type . The temporary files are kept and not deleted, the grog output is printed, the name of the temporary directory is printed, the displayed file names are printed, and the parameters are printed. --debug-filenames Print the names of the files and man pages that are displayed by groffer. --debug-grog Print the output of all grog commands. --debug-keep Enable two debugging informations. Print the name of the tempo‐ rary directory and keep the temporary files, do not delete them during the run of groffer. --debug-params Print the parameters, as obtained from the configuration files, from GROFFER_OPT, and the command line arguments. --debug-tmpdir Print the name of the temporary directory. --do-nothing This is like --version , but without the output; no viewer is started. This makes only sense in development. --print=text Just print the argument to standard error. This is good for pa‐ rameter check. -V This is an advanced option for debugging only. Instead of dis‐ playing the formatted input, a lot of groffer specific information is printed to standard output: · the output file name in the temporary directory, · the display mode of the actual groffer run, · the display program for viewing the output with its arguments, · the active parameters from the config files, the arguments in $GROFFER_OPT, and the arguments of the command line, · the pipeline that would be run by the groff program, but without executing it. Other useful debugging options are the groff option -Z and --mode=groff. Filespec Arguments A filespec parameter is an argument that is not an option or option argu‐ ment. In groffer, filespec parameters are a file name or a template for searching man pages. These input sources are collected and composed into a single output file such as groff does. The strange POSIX behavior to regard all arguments behind the first non- option argument as filespec arguments is ignored. The GNU behavior to recognize options even when mixed with filespec arguments is used througout. But, as usual, the double minus argument -- ends the option handling and interprets all following arguments as filespec arguments; so the POSIX behavior can be easily adopted. The options --apropos* have a special handling of filespec arguments. Each argument is taken as a search scheme of its own. Also a regexp (regular expression) can be used in the filespec. For example, groffer --apropos '^gro.f$' searches groff in the man page name, while groffer --apropos groff searches groff somewhere in the name or description of the man pages. All other parts of groffer, such as the normal display or the output with --whatis have a different scheme for filespecs. No regular expressions are used for the arguments. The filespec arguments are handled by the following scheme. It is necessary to know that on each system the man pages are sorted ac‐ cording to their content into several sections. The classical man sec‐ tions have a single-character name, either a digit from 1 to 9 or one of the characters n or o. This can optionally be followed by a string, the so-called extension. The extension allows to store several man pages with the same name in the same section. But the extension is only rarely used, usually it is omit‐ ted. Then the extensions are searched automatically by alphabet. In the following, we use the name section_extension for a word that con‐ sists of a single character section name or a section character that is followed by an extension. Each filespec parameter can have one of the following forms in decreasing sequence. · No filespec parameters means that groffer waits for standard input. The minus option - always stands for standard input; it can occur sev‐ eral times. If you want to look up a man page called - use the argu‐ ment man:-. · Next a filespec is tested whether it is the path name of an existing file. Otherwise it is assumed to be a searching pattern for a man page. · man:name(section_extension), man:name.section_extension, name(section_extension), or name.section_extension search the man page name in man section and possibly extension of section_extension. · Now man:name searches for a man page in the lowest man section that has a document called name. · section_extension name is a pattern of 2 arguments that originates from a strange argument parsing of the man program. Again, this searches the man page name with section_extension, a combination of a section character optionally followed by an extension. · We are left with the argument name which is not an existing file. So this searches for the man page called name in the lowest man section that has a document for this name. Several file name arguments can be supplied. They are mixed by groff in‐ to a single document. Note that the set of option arguments must fit to all of these file arguments. So they should have at least the same style of the groff language. OUTPUT MODES By default, the groffer program collects all input into a single file, formats it with the groff program for a certain device, and then chooses a suitable viewer program. The device and viewer process in groffer is called a mode. The mode and viewer of a running groffer program is se‐ lected automatically, but the user can also choose it with options. The modes are selected by option the arguments of --mode=anymode. Addition‐ ally, each of this argument can be specified as an option of its own, such as anymode. Most of these modes have a viewer program, which can be chosen by an option that is constructed like --anymode-viewer. Several different modes are offered, graphical modes for X Window, text modes, and some direct groff modes for debugging and development. By default, groffer first tries whether x mode is possible, then ps mode, and finally tty mode. This mode testing sequence for auto mode can be changed by specifying a comma separated list of modes with the option --default-modes. The searching for man pages and the decompression of the input are active in every mode. Graphical Display Modes The graphical display modes work mostly in the X Window environment (or similar implementations within other windowing environments). The envi‐ ronment variable $DISPLAY and the option --display are used for specify‐ ing the X Window display to be used. If this environment variable is empty groffer assumes that no X Window is running and changes to a text mode. You can change this automatic behavior by the option --de‐ fault-modes. Known viewers for the graphical display modes and their standard X Window viewer progams are · in a PDF viewer (pdf mode), · in a web browser (html or www mode). · in a Postscript viewer (ps mode), · X Window roff viewers such as gxditview(1) or xditview(1) (in x mode), · in a dvi viewer program (dvi mode), The pdf mode has a major advantage — it is the only graphical diplay mode that allows to search for text within the viewer; this can be a really important feature. Unfortunately, it takes some time to transform the input into the PDF format, so it was not chosen as the major mode. These graphical viewers can be customized by options of the X Window Toolkit. But the groffer options use a leading double minus in‐ stead of the single minus used by the X Window Toolkit. Text modes There are two modes for text output, mode text for plain output without a pager and mode tty for a text output on a text terminal using some pager program. If the variable $DISPLAY is not set or empty, groffer assumes that it should use tty mode. In the actual implementation, the groff output device latin1 is chosen for text modes. This can be changed by specifying option -T or --device. The pager to be used can be specified by one of the options --pager and --tty-viewer, or by the environment variable $PAGER. If all of this is not used the less(1) program with the option -r for correctly displaying control sequences is used as the default pager. Special Modes for Debugging and Development These modes use the groffer file determination and decompression. This is combined into a single input file that is fed directly into groff with different strategy without the groffer viewing facilities. These modes are regarded as advanced, they are useful for debugging and development purposes. The source mode with option --source just displays the decompressed in‐ put. Otion --to-stdout does not display in a graphical mode. It just gener‐ ates the file for the chosen mode and then prints its content to standard output. The groff mode passes the input to groff using only some suitable options provided to groffer. This enables the user to save the generated output into a file or pipe it into another program. In groff mode, the option -Z disables post-processing, thus producing the groff intermediate output. In this mode, the input is formatted, but not postprocessed; see groff_out(5) for details. All groff short options are supported by groffer. MAN PAGE SEARCHING The default behavior of groffer is to first test whether a file parameter represents a local file; if it is not an existing file name, it is as‐ sumed to represent the name of a man page. The following options can be used to determine whether the arguments should be handled as file name or man page arguments. --man forces to interpret all file parameters as filespecs for searching man pages. --no-man --local-file disable the man searching; so only local files are displayed. If neither a local file nor a man page was retrieved for some file param‐ eter a warning is issued on standard error, but processing is continued. Search Algoritm Let us now assume that a man page should be searched. The groffer pro‐ gram provides a search facility for man pages. All long options, all en‐ vironment variables, and most of the functionality of the GNU man(1) pro‐ gram were implemented. The search algorithm shall determine which file is displayed for a given man page. The process can be modified by op‐ tions and environment variables. The only man action that is omitted in groffer are the preformatted man pages, also called cat pages. With the excellent performance of the actual computers, the preformatted man pages aren't necessary any longer. Additionally, groffer is a roff program; it wants to read roff source files and format them itself. The algorithm for retrieving the file for a man page needs first a set of directories. This set starts with the so-called man path that is modi‐ fied later on by adding names of operating system and language. This arising set is used for adding the section directories which contain the man page files. The man path is a list of directories that are separated by colon. It is generated by the following methods. · The environment variable $MANPATH can be set. · It can be read from the arguments of the environment variable $MANOPT. · The man path can be manually specified by using the option --manpath. An empty argument disables the man page searching. · When no man path was set the manpath(1) program is tried to determine one. · If this does not work a reasonable default path from $PATH is deter‐ mined. We now have a starting set of directories. The first way to change this set is by adding names of operating systems. This assumes that man pages for several operating systems are installed. This is not always true. The names of such operating systems can be provided by 3 methods. · The environment variable $SYSTEM has the lowest precedence. · This can be overridden by an option in $MANOPT. · This again is overridden by the command line option --systems. Several names of operating systems can be given by appending their names, separated by a comma. The man path is changed by appending each system name as subdirectory at the end of each directory of the set. No directory of the man path set is kept. But if no system name is specified the man path is left un‐ changed. After this, the actual set of directories can be changed by language in‐ formation. This assumes that there exist man pages in different lan‐ guages. The wanted language can be chosen by several methods. · Enviroment variable $LANG. · This is overridden by $LC_MESSAGES. · This is overridden by $LC_ALL. · This can be overridden by providing an option in $MANOPT. · All these environment variables are overridden by the command line op‐ tion --locale. The default language can be specified by specifying one of the pseudo- language parameters C or POSIX. This is like deleting a formerly given language information. The man pages in the default language are usually in English. Of course, the language name is determined by man. In GNU man, it is specified in the POSIX 1003.1 based format: <language>[_<territory>[.<character-set>[,<version>]]], but the two-letter code in <language> is sufficient for most purposes. If for a complicated language formulation no man pages are found groffer searches the country part consisting of these first two characters as well. The actual directory set is copied thrice. The language name is appended as subdirectory to each directory in the first copy of the actual direc‐ tory set (this is only done when a language information is given). Then the 2-letter abbreviation of the language name is appended as subdirecto‐ ries to the second copy of the directory set (this is only done when the given language name has more than 2 letters). The third copy of the di‐ rectory set is kept unchanged (if no language information is given this is the kept directory set). These maximally 3 copies are appended to get the new directory set. We now have a complete set of directories to work with. In each of these directories, the man files are separated in sections. The name of a sec‐ tion is represented by a single character, a digit between 1 and 9, or the character o or n, in this order. For each available section, a subdirectory man<section> exists containing all man files for this section, where <section> is a single character as described before. Each man file in a section directory has the form man<section>/<name>.<section>[<extension>][.<compression>], where <extension> and <compression> are optional. <name> is the name of the man page that is also specified as filespec argument on the command line. The extension is an addition to the section. This postfix acts like a subsection. An extension occurs only in the file name, not in name of the section subdirectory. It can be specified on the command line. On the other hand, the compression is just an information on how the file is compressed. This is not important for the user, such that it cannot be specified on the command line. There are 4 methods to specify a section on the command line: · Environment variable $MANSECT · Command line option --sections · Appendix to the name argument in the form <name>.<section> · Preargument before the name argument in the form <section> <name> It is also possible to specify several sections by appending the single characters separated by colons. One can imagine that this means to re‐ strict the man page search to only some sections. The multiple sections are only possible for $MANSECT and --sections. If no section is specified all sections are searched one after the other in the given order, starting with section 1, until a suitable file is found. There are 4 methods to specify an extension on the command line. But it is not necessary to provide the whole extension name, some abbreviation is good enough in most cases. · Environment variable $EXTENSION · Command line option --extension · Appendix to the <name>.<section> argument in the form <name>.<sec‐ tion><extension> · Preargument before the name argument in the form <section><extension> <name> For further details on man page searching, see man(1). Examples of man files /usr/share/man/man1/groff.1 This is an uncompressed file for the man page groff in section 1. It can be called by sh# groffer groff No section is specified here, so all sections should be searched, but as section 1 is searched first this file will be found first. The file name is composed of the following components. /usr/share/man must be part of the man path; the subdirectory man1/ and the part .1 stand for the section; groff is the name of the man page. /usr/local/share/man/man7/groff.7.gz The file name is composed of the following components. /usr/local/share/man must be part of the man path; the subdirecto‐ ry man7/ and the part .7 stand for the section; groff is the name of the man page; the final part .gz stands for a compression with gzip(1). As the section is not the first one it must be specified as well. This can be done by one of the following commands. sh# groffer groff.7 sh# groffer 7 groff sh# groffer --sections=7 groff /usr/local/man/man1/ctags.1emacs21.bz2 Here /usr/local/man must be in man path; the subdirectory man1/ and the file name part .1 stand for section 1; the name of the man page is ctags; the section has an extension emacs21; and the file is compressed as .bz2 with bzip2(1). The file can be viewed with one of the following commands sh# groffer ctags.1e sh# groffer 1e ctags sh# groffer --extension=e --sections=1 ctags where e works as an abbreviation for the extension emacs21. /usr/man/linux/de/man7/man.7.Z The directory /usr/man is now part of the man path; then there is a subdirectory for an operating system name linux/; next comes a subdirectory de/ for the German language; the section names man7 and .7 are known so far; man is the name of the man page; and .Z signifies the compression that can be handled by gzip(1). We want now show how to provide several values for some options. That is possible for sections and operating system names. So we use as sections 5 and 7 and as system names linux and aix. The command is then sh# groffer --locale=de --sections=5:7 --systems=linux,aix man sh# LANG=de MANSECT=5:7 SYSTEM=linux,aix groffer man DECOMPRESSION The program has a decompression facility. If standard input or a file that was retrieved from the command line parameters is compressed with a format that is supported by either gzip(1) or bzip2(1) it is decompressed on-the-fly. This includes the GNU .gz, .bz2, and the traditional .Z com‐ pression. The program displays the concatenation of all decompressed input in the sequence that was specified on the command line. ENVIRONMENT The groffer program supports many system variables, most of them by cour‐ tesy of other programs. All environment variables of groff(1) and GNU man(1) and some standard system variables are honored. Native groffer Variables $GROFFER_OPT Store options for a run of groffer. The options specified in this variable are overridden by the options given on the command line. The content of this variable is run through the shell builtin `eval'; so arguments containing white-space or special shell char‐ acters should be quoted. Do not forget to export this variable, otherwise it does not exist during the run of groffer. System Variables The following variables have a special meaning for groffer. $DISPLAY If this variable is set this indicates that the X Window system is running. Testing this variable decides on whether graphical or text output is generated. This variable should not be changed by the user carelessly, but it can be used to start the graphical groffer on a remote X Window terminal. For example, depending on your system, groffer can be started on the second monitor by the command sh# DISPLAY=:0.1 groffer what.ever & $LC_ALL $LC_MESSAGES $LANG If one of these variables is set (in the above sequence), its con‐ tent is interpreted as the locale, the language to be used, espe‐ cially when retrieving man pages. A locale name is typically of the form language[_territory[.codeset[@modifier]]], where language is an ISO 639 language code, territory is an ISO 3166 country code, and codeset is a character set or encoding identifier like ISO-8859-1 or UTF-8; see setlocale(3). The locale values C and POSIX stand for the default, i.e. the man page directories without a language prefix. This is the same behavior as when all 3 vari‐ ables are unset. $PAGER This variable can be used to set the pager for the tty output. For example, to disable the use of a pager completely set this variable to the cat(1) program sh# PAGER=cat groffer anything $PATH All programs within the groffer script are called without a fixed path. Thus this environment variable determines the set of pro‐ grams used within the run of groffer. Groff Variables The groffer program internally calls groff, so all environment variables documented in groff(1) are internally used within groffer as well. The following variable has a direct meaning for the groffer program. $GROFF_TMPDIR If the value of this variable is an existing, writable directory, groffer uses it for storing its temporary files, just as groff does. See the groff(1) man page for more details on the location of temporary files. Man Variables Parts of the functionality of the man program were implemented in groffer; support for all environment variables documented in man(1) was added to groffer, but the meaning was slightly modified due to the dif‐ ferent approach in groffer; but the user interface is the same. The man environment variables can be overwritten by options provided with $MANOPT, which in turn is overwritten by the command line. $EXTENSION Restrict the search for man pages to files having this extension. This is overridden by option --extension; see there for details. $MANOPT This variable contains options as a preset for man(1). As not all of these are relevant for groffer only the essential parts of its value are extracted. The options specified in this variable over‐ write the values of the other environment variables that are spe‐ cific to man. All options specified in this variable are overrid‐ den by the options given on the command line. $MANPATH If set, this variable contains the directories in which the man page trees are stored. This is overridden by option --man‐ path. $MANSECT If this is a colon separated list of section names, the search for man pages is restricted to those manual sections in that order. This is overridden by option --sections. $SYSTEM If this is set to a comma separated list of names these are inter‐ preted as man page trees for different operating systems. This variable can be overwritten by option --systems; see there for de‐ tails. The environment variable $MANROFFSEQ is ignored by groffer because the necessary preprocessors are determined automatically. CONFIGURATION FILES The groffer program can be preconfigured by two configuration files. /etc/groff/groffer.conf System-wide configuration file for groffer. $HOME/.groff/groffer.conf User-specific configuration file for groffer, where $HOME denotes the user's home directory. This file is called after the system- wide configuration file to enable overriding by the user. Both files are handled for the configuration, but the configuration file in /etc comes first; it is overwritten by the configuration file in the home directory; both configuration files are overwritten by the environ‐ ment variable $GROFFER_OPT; everything is overwritten by the command line arguments. The configuration files contain options that should be called as default for every groffer run. These options are written in lines such that each contains either a long option, a short option, or a short option cluster; each with or without an argument. So each line with configuration infor‐ mation starts with a minus character `-'; a line with a long option starts with two minus characters `--', a line with a short option or short option cluster starts with a single minus `-'. The option names in the configuration files may not be abbreviated, they must be exact. The argument for a long option can be separated from the option name ei‐ ther by an equal sign `=' or by whitespace, i.e. one or several space or tab characters. An argument for a short option or short option cluster can be directly appended to the option name or separated by whitespace. The end of an argument is the end of the line. It is not allowed to use a shell environment variable in an option name or argument. It is not necessary to use quotes in an option or argument, except for empty arguments. An empty argument can be provided by appending a pair of quotes to the separating equal sign or whitespace; with a short op‐ tion, the separator can be omitted as well. For a long option with a separating equal sign `=', the pair of quotes can be omitted, thus ending the line with the separating equal sign. All other quote characters are cancelled internally. In the configuration files, arbitrary whitespace is allowed at the begin‐ ning of each line, it is just ignored. Each whitespace within a line is replaced by a single space character ` ' internally. All lines of the configuration lines that do not start with a minus char‐ acter are ignored, such that comments starting with `#' are possible. So there are no shell commands in the configuration files. As an example, consider the following configuration file that can be used either in /etc/groff/groffer.conf or ~/.groff/groffer.conf. # groffer configuration file # # groffer options that are used in each call of groffer --foreground=DarkBlue --resolution 100 --x-viewer=gxditview -geometry 900x1200 --pdf-viewer xpdf -z 150 The lines starting with # are just ignored, so they act as command lines. This configuration sets four groffer options (the lines starting with `-'). This has the following effects: · Use a text color of DarkBlue in all viewers that support this, such as gxditview. · Use a resolution of 100 dpi in all viewers that support this, such as gxditview. By this, the default device in x mode is set to X100. · Force gxditview(1) as the x-mode viewer using the geometry option for setting the width to 900 dpi and the height to 1200 dpi. This geometry is suitable for a resolution of 100 dpi. · Use xpdf(1) as the pdf-mode viewer with the argument -Z 150. EXAMPLES The usage of groffer is very easy. Usually, it is just called with a file name or man page. The following examples, however, show that groffer has much more fancy capabilities. sh# groffer /usr/local/share/doc/groff/meintro.ms.gz Decompress, format and display the compressed file meintro.ms.gz in the directory /usr/local/share/doc/groff, using the standard viewer gxditview as graphical viewer when in X Window, or the less(1) pager program when not in X Window. sh# groffer groff If the file ./groff exists use it as input. Otherwise interpret the ar‐ gument as a search for the man page named groff in the smallest possible man section, being section 1 in this case. sh# groffer man:groff search for the man page of groff even when the file ./groff exists. sh# groffer groff.7 sh# groffer 7 groff search the man page of groff in man section 7. This section search works only for a digit or a single character from a small set. sh# groffer fb.modes If the file ./fb.modes does not exist interpret this as a search for the man page of fb.modes. As the extension modes is not a single character in classical section style the argument is not split to a search for fb. sh# groffer groff ’troff(1)’ man:roff The arguments that are not existing files are looked-up as the following man pages: groff (automatic search, should be found in man section 1), troff (in section 1), and roff (in the section with the lowest number, being 7 in this case). The quotes around ’troff(1)’ are necessary be‐ cause the paranthesis are special shell characters; escaping them with a backslash character \( and \) would be possible, too. The formatted files are concatenated and displayed in one piece. sh# LANG=de groffer --man --www --www-viever=galeon ls Retrieve the German man page (language de) for the ls program, decompress it, format it to html format (www mode) and view the result in the web browser galeon. The option --man guarantees that the man page is re‐ trieved, even when a local file ls exists in the actual directory. sh# groffer --source 'man:roff(7)' Get the man page called roff in man section 7, decompress it, and print its unformatted content, its source code. sh# groffer --de-p --in --ap This is a set of abbreviated arguments, it is determined as sh# groffer --debug-params --intermediate-output --apropos sh# cat file.gz | groffer -Z -mfoo" The file file.gz is sent to standard input, this is decompressed, and then this is transported to the groff intermediate output mode without post-processing (groff option -Z ), using macro package foo (groff option -m ) . sh# echo '\f[CB]WOW!' | > groffer --x --bg red --fg yellow --geometry 200x100 - Display the word WOW! in a small window in constant-width bold font, using color yellow on red background. COMPATIBILITY The groffer program is written in Perl, the Perl version during writing was v5.8.8. groffer provides its own parser for command line arguments that is compatible to both POSIX getopts(1) and GNU getopt(1). It can handle option arguments and file names containing white space and a large set of special characters. The following standard types of options are supported. · The option consisting of a single minus - refers to standard input. · A single minus followed by characters refers to a single character op‐ tion or a combination thereof; for example, the groffer short option combination -Qmfoo is equivalent to -Q -m foo . · Long options are options with names longer than one character; they are always preceded by a double minus. An option argument can either go to the next command line argument or be appended with an equal sign to the argument; for example, --long=arg is equivalent to --long arg. · An argument of -- ends option parsing; all further command line argu‐ ments are interpreted as filespec parameters, i.e. file names or con‐ structs for searching man pages). · All command line arguments that are neither options nor option argu‐ ments are interpreted as filespec parameters and stored until option parsing has finished. For example, the command line sh# groffer file1 -a -o arg file2 is equivalent to sh# groffer -a -o arg -- file1 file2 The free mixing of options and filespec parameters follows the GNU prin‐ ciple. That does not fulfill the strange option behavior of POSIX that ends option processing as soon as the first non-option argument has been reached. The end of option processing can be forced by the option `--' anyway. BUGS Report bugs to the bug-groff mailing list<EMAIL_ADDRESS>Include a complete, self-contained example that will allow the bug to be repro‐ duced, and say which version of groffer you are using. You can also use the groff mailing list<EMAIL_ADDRESS>but you must first subscribe to this list. You can do that by visiting the groff mailing list web page ⟨http://lists.gnu.org/mailman/listinfo/groff⟩. See groff(1) for information on availability. SEE ALSO groff(1), troff(1) Details on the options and environment variables available in groff; all of them can be used with groffer. groff(7) Documentation of the groff language. grog(1) Internally, groffer tries to guess the groff command line options from the input using this program. chem(1) Preprocessor of groff that is run automatically. groff_out(5) Documentation on the groff intermediate output (ditroff output). groff_tmac(5) Documentation on the groff macro files. man(1) The standard program to display man pages. The information there is only useful if it is the man page for GNU man. Then it docu‐ ments the options and environment variables that are supported by groffer. gxditview(1), xditview(1x) Viewers for groffer's x mode. kpdf(1), kghostview(1), evince(1), ggv(1), gv(1), ghostview(1), gs(1) Viewers for groffer's ps mode. kpdf(1), acroread(1), evince(1), xpdf(1), gpdf(1), kghostview(1), ggv(1) Viewers for groffer's pdf mode. kdvi(1), xdvi(1), dvilx(1) Viewers for groffer's dvi mode. konqueror(1), epiphany(1), firefox(1), mozilla(1), netscape(1), lynx(1) Web-browsers for groffer's html or www mode. less(1) Standard pager program for the tty mode . gzip(1), bzip2(1) The decompression programs supported by groffer. AUTHOR This file was written by Bernd Warken. COPYING Copyright (C) 2001, 2002, 2004, 2005, 2006, 2009, 2010 Free Software Foundation, Inc. This file is part of groffer, which is part of groff, a free software project. You can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. You should have received a copy of the GNU General Public License along with groff, see the files COPYING and LICENSE in the top directory of the groff source package. Or read the man page gpl(1). You can also visit <http://www.gnu.org/licenses/>. Groff Version 1.21 25 June 2012 GROFFER(1)


Program Committee invites prospective authors to submit original and previously unpublished research and application papers in all spectrums of related fields. The conference topics cover but are not limited to the following areas :-
| Abstract submission Up to 1st November, 2019 |
| Paper acceptance intimation 10th November, 2019 |
| Full papers submission Up to 30th November, 2019 |
| Early bird registration Up to 15th November, 2019 |
| Conference days 12th to 14th December, 2019 |


|
LiteCore
Couchbase Lite cross-platform core implementation
|
Data Structures | |
| struct | C4Progress |
| struct | C4ReplicatorStatus |
| Current status of replication. More... | |
| struct | C4ReplicatorParameters |
Typedefs | |
| typedef struct C4Replicator | C4Replicator |
| Opaque reference to a replicator. More... | |
| typedef void(* | C4ReplicatorStatusChangedCallback) (C4Replicator *, C4ReplicatorStatus, void *context) |
| Callback a client can register, to get progress information. More... | |
| typedef void(* | C4ReplicatorDocumentErrorCallback) (C4Replicator *, bool pushing, C4String docID, C4Error error, bool transient, void *context) |
| Callback a client can register, to hear about errors replicating individual documents. More... | |
| typedef bool(* | C4ReplicatorValidationFunction) (C4String docID, FLDict body, void *context) |
| Callback that can choose to reject an incoming pulled revision by returning false. More... | |
Enumerations | |
| enum | C4ReplicatorMode : int32_t { kC4Disabled, kC4Passive, kC4OneShot, kC4Continuous } |
| How to replicate, in either direction. More... | |
| enum | C4ReplicatorActivityLevel : int32_t { kC4Stopped, kC4Offline, kC4Connecting, kC4Idle, kC4Busy } |
Functions | |
| bool | c4repl_isValidDatabaseName (C4String dbName) |
| Checks whether a database name is valid, for purposes of appearing in a replication URL. More... | |
| bool | c4repl_parseURL (C4String url, C4Address *address, C4String *dbName) |
| A simple URL parser that populates a C4Address from a URL string. More... | |
| C4Replicator * | c4repl_new (C4Database *db, C4Address remoteAddress, C4String remoteDatabaseName, C4Database *otherLocalDB, C4ReplicatorParameters params, C4Error *err) |
| Creates a new replicator. More... | |
| void | c4repl_free (C4Replicator *repl) |
| Frees a replicator reference. More... | |
| void | c4repl_stop (C4Replicator *repl) |
| Tells a replicator to stop. More... | |
| C4ReplicatorStatus | c4repl_getStatus (C4Replicator *repl) |
| Returns the current state of a replicator. More... | |
| C4Slice | c4repl_getResponseHeaders (C4Replicator *repl) |
| Returns the HTTP response headers as a Fleece-encoded dictionary. More... | |
| bool | c4db_setCookie (C4Database *db, C4String setCookieHeader, C4String fromHost, C4Error *outError) |
| Takes the value of a "Set-Cookie:" header, received from the given host, and saves the cookie into the database's cookie store. More... | |
| C4StringResult | c4db_getCookies (C4Database *db, C4Address request, C4Error *error) |
| Locates any saved HTTP cookies relevant to the given request, and returns them as a string that can be used as the value of a "Cookie:" header. More... | |
| void | c4db_clearCookies (C4Database *db) |
| Removes all cookies from the database's cookie store. More... | |
Variables | |
| const char *const | kC4ReplicatorActivityLevelNames [5] |
| #define kC4AuthTypeBasic "Basic" |
| #define kC4AuthTypeClientCert "Client Cert" |
| #define kC4AuthTypeFacebook "Facebook" |
| #define kC4AuthTypeOpenIDConnect "OpenID Connect" |
| #define kC4AuthTypeSession "Session" |
| #define kC4Replicator2Scheme C4STR("blip") |
| #define kC4Replicator2TLSScheme C4STR("blips") |
| #define kC4ReplicatorAuthClientCert "clientCert" |
| #define kC4ReplicatorAuthPassword "password" |
| #define kC4ReplicatorAuthType "type" |
| #define kC4ReplicatorAuthUserName "username" |
| #define kC4ReplicatorCheckpointInterval "checkpointInterval" |
| #define kC4ReplicatorOptionAuthentication "auth" |
| #define kC4ReplicatorOptionChannels "channels" |
| #define kC4ReplicatorOptionCookies "cookies" |
| #define kC4ReplicatorOptionDocIDs "docIDs" |
| #define kC4ReplicatorOptionExtraHeaders "headers" |
| #define kC4ReplicatorOptionFilter "filter" |
| #define kC4ReplicatorOptionFilterParams "filterParams" |
| #define kC4ReplicatorOptionNoConflicts "noConflicts" |
| #define kC4ReplicatorOptionPinnedServerCert "pinnedCert" |
| #define kC4ReplicatorOptionSkipDeleted "skipDeleted" |
| typedef struct C4Replicator C4Replicator |
Opaque reference to a replicator.
| typedef void(* C4ReplicatorDocumentErrorCallback) (C4Replicator *, bool pushing, C4String docID, C4Error error, bool transient, void *context) |
Callback a client can register, to hear about errors replicating individual documents.
| typedef void(* C4ReplicatorStatusChangedCallback) (C4Replicator *, C4ReplicatorStatus, void *context) |
Callback a client can register, to get progress information.
This will be called on arbitrary background threads, and should not block.
Callback that can choose to reject an incoming pulled revision by returning false.
| enum C4ReplicatorActivityLevel : int32_t |
| enum C4ReplicatorMode : int32_t |
| void c4db_clearCookies | ( | C4Database * | db | ) |
Removes all cookies from the database's cookie store.
| C4StringResult c4db_getCookies | ( | C4Database * | db, |
| C4Address | request, | ||
| C4Error * | error | ||
| ) |
Locates any saved HTTP cookies relevant to the given request, and returns them as a string that can be used as the value of a "Cookie:" header.
| bool c4db_setCookie | ( | C4Database * | db, |
| C4String | setCookieHeader, | ||
| C4String | fromHost, | ||
| C4Error * | outError | ||
| ) |
Takes the value of a "Set-Cookie:" header, received from the given host, and saves the cookie into the database's cookie store.
(Persistent cookies are saved as metadata in the database file until they expire. Session cookies are kept in memory, until the last C4Database handle to the given database is closed.)
| void c4repl_free | ( | C4Replicator * | repl | ) |
Frees a replicator reference.
If the replicator is running it will stop.
| C4Slice c4repl_getResponseHeaders | ( | C4Replicator * | repl | ) |
Returns the HTTP response headers as a Fleece-encoded dictionary.
| C4ReplicatorStatus c4repl_getStatus | ( | C4Replicator * | repl | ) |
Returns the current state of a replicator.
| bool c4repl_isValidDatabaseName | ( | C4String | dbName | ) |
Checks whether a database name is valid, for purposes of appearing in a replication URL.
| C4Replicator* c4repl_new | ( | C4Database * | db, |
| C4Address | remoteAddress, | ||
| C4String | remoteDatabaseName, | ||
| C4Database * | otherLocalDB, | ||
| C4ReplicatorParameters | params, | ||
| C4Error * | err | ||
| ) |
Creates a new replicator.
| db | The local database. |
| remoteAddress | The address of the remote server (null if other db is local.) |
| remoteDatabaseName | The name of the database at the remote address. |
| otherLocalDB | The other local database (null if other db is remote.) |
| params | Replication parameters (see above.) |
| err | Error, if replication can't be created. |
A simple URL parser that populates a C4Address from a URL string.
The fields of the address will point inside the url string.
| void c4repl_stop | ( | C4Replicator * | repl | ) |
Tells a replicator to stop.
| const char* const kC4ReplicatorActivityLevelNames[5] |


Search
Preparing search index...
The search index is not available
browserslist-useragent-regexp
Options
All
Public
Public/Protected
All
Inherited
Only exported
Menu
Globals
"regexp/index"
Module "regexp/index"
Index
References
BRACED_
NUMBER_
PATTERN
DIGIT_
PATTERN
ESCAPE_
SYMBOL
NUMBER_
PATTERN
OPTIMIZABLE_
GROUP
apply
Versions
ToReg
Exp
apply
Versions
ToReg
Exps
capture
Postfix
enum
OrRange
get
Number
Patterns
Count
get
Number
Patterns
Part
has
Number
Pattern
join
Parts
join
Versioned
Browsers
Reg
Exps
number
ToDigits
optimize
optimize
Rays
Number
Patterns
range
ToReg
Exp
ray
Range
Digit
Pattern
ray
ToNumber
Patterns
reg
Exp
ToString
replace
Number
Patterns
segment
Range
Number
Pattern
segment
ToNumber
Patterns
segment
ToNumber
Patterns
OrEnum
skip
Square
Braces
split
Common
Diff
split
ToDecade
Ranges
References
BRACED_
NUMBER_
PATTERN
Re-exports
BRACED_NUMBER_PATTERN
DIGIT_
PATTERN
Re-exports
DIGIT_PATTERN
ESCAPE_
SYMBOL
Re-exports
ESCAPE_SYMBOL
NUMBER_
PATTERN
Re-exports
NUMBER_PATTERN
OPTIMIZABLE_
GROUP
Re-exports
OPTIMIZABLE_GROUP
apply
Versions
ToReg
Exp
Re-exports
applyVersionsToRegExp
apply
Versions
ToReg
Exps
Re-exports
applyVersionsToRegExps
capture
Postfix
Re-exports
capturePostfix
enum
OrRange
Re-exports
enumOrRange
get
Number
Patterns
Count
Re-exports
getNumberPatternsCount
get
Number
Patterns
Part
Re-exports
getNumberPatternsPart
has
Number
Pattern
Re-exports
hasNumberPattern
join
Parts
Re-exports
joinParts
join
Versioned
Browsers
Reg
Exps
Re-exports
joinVersionedBrowsersRegExps
number
ToDigits
Re-exports
numberToDigits
optimize
Re-exports
optimize
optimize
Rays
Number
Patterns
Re-exports
optimizeRaysNumberPatterns
range
ToReg
Exp
Re-exports
rangeToRegExp
ray
Range
Digit
Pattern
Re-exports
rayRangeDigitPattern
ray
ToNumber
Patterns
Re-exports
rayToNumberPatterns
reg
Exp
ToString
Re-exports
regExpToString
replace
Number
Patterns
Re-exports
replaceNumberPatterns
segment
Range
Number
Pattern
Re-exports
segmentRangeNumberPattern
segment
ToNumber
Patterns
Re-exports
segmentToNumberPatterns
segment
ToNumber
Patterns
OrEnum
Re-exports
segmentToNumberPatternsOrEnum
skip
Square
Braces
Re-exports
skipSquareBraces
split
Common
Diff
Re-exports
splitCommonDiff
split
ToDecade
Ranges
Re-exports
splitToDecadeRanges
Globals
"regexp/index"
BRACED_
NUMBER_
PATTERN
DIGIT_
PATTERN
ESCAPE_
SYMBOL
NUMBER_
PATTERN
OPTIMIZABLE_
GROUP
apply
Versions
ToReg
Exp
apply
Versions
ToReg
Exps
capture
Postfix
enum
OrRange
get
Number
Patterns
Count
get
Number
Patterns
Part
has
Number
Pattern
join
Parts
join
Versioned
Browsers
Reg
Exps
number
ToDigits
optimize
optimize
Rays
Number
Patterns
range
ToReg
Exp
ray
Range
Digit
Pattern
ray
ToNumber
Patterns
reg
Exp
ToString
replace
Number
Patterns
segment
Range
Number
Pattern
segment
ToNumber
Patterns
segment
ToNumber
Patterns
OrEnum
skip
Square
Braces
split
Common
Diff
split
ToDecade
Ranges
Generated using
TypeDoc


- Title: {{ this.business?.title }}
- Category: {{ this.category?.name }}
- Locality: {{ this.location?.locality }}
- Street Number: {{ this.location?.number }}
- Phone Number: {{ this.business?.number }}
- Level: {{ this.business?.level }}
{{ this.business?.about }}


How certain data-driven schemes to improve the human condition have failed
(while achieving a high R^2).Senior Data Scientist, Enigma
Research Fellow, Tow Center
slides: abelson.nyc/seeing-like-a-stata
Certain forms of knowledge and control require a narrowing of vision. The great advantage of such tunnel vision is that it brings into sharp focus certain limited aspects of an otherwise far more complex and unwieldy reality. This very simplification, in turn, makes the phenomenon at the center of the field of vision more legible and hence more susceptible to careful measurement and calculation.


Add Promotions
Promotions
| Promo Type | On | From | To | Promo Days | Privacy | Promo Code | Status | Used | Remove |
|---|---|---|---|---|---|---|---|---|---|
| 1G1 | All items | 2021-07-14 | 2021-07-14 | All days | Public | none | Active | 2 |
| Promo Type | On | From | To | Promo Days | Privacy | Promo Code | Status | Used | Remove |
|---|---|---|---|---|---|---|---|---|---|
| 1G1 | All items | 2021-07-14 | 2021-07-14 | All days | Public | none | Active | 2 |


Get all the way turnt with our special Gucci gang drinks on the house happy hour all day everyday.
Steps from the beach, rooms in Lifestyle Tropical Beach's Mediterranean-style buildings have balconies or patios with pool, garden, or ocean views; white-tile floors; and locally crafted furniture.


China central bank says downward pressure on economy is increasing
by ReutersBEIJING (Nov 25): Downward pressure on the Chinese economy is increasing and potential risks and problems will be difficult to eliminate in the short term, China's central bank said on Monday.
The People's Bank of China, in its annual financial stability report, said China will continue to implement proactive fiscal policy and prudent monetary policy.
The country will also implement greater tax cuts and increase the issuance quota for local governments' special bonds used to fund infrastructure projects by a large margin, the report said, without providing further details.


--- title: Mario Kart Wii client: Nintendo Australia collaborator: Blissmedia date: "2011-04-01" publishDate: "2019-10-22" subtitle: | Front-end development, User Experience, Facebook API aliases: - /pages/mariokartwii.html ---
Nintendo wanted to push the limits of what could be accomplished with their latest game site for Mario Kart Wii. They gave us the vision of pushing the 'three dimensional' envelope, I smashed together a parallax proof-of-concept and we ran with it.
Includes Facebook application to allow users to 'attack' or 'defend' by posting Mario Kart items on friends' and thier own walls, leading to tens of thousands of impressions.


WITHIN THE ROCK
USA. 1996. Director/Screenplay - Gary J. Tunnicliffe, Producers - Stanley Isaacs, Scott McGinnis & Robert Patrick, Photography - Adam Kane, Music - Tony Fennell & Rod Gammons, Music Co-ordinator - Helen Gammons, Digital Effects Created by Eugene Jeoung, Additional Digital Effects - Post Modern Digital (Supervisor - Jim Tibbits), Spaceship CGI Effects - Corbitt Design, Battle Scarz Sequence Created and Designed by Nicholas Edgar, Special Effects Supervisor - Wayne Beauchamp, Creature Effects/Key Props - Image Animation International (Supervisor - Tunnicliffe), Production Design - Deborah Raymond & Dorian Vernacchio. Production Company - 360 entertainment/Le Monde Entertainment/Prism Pictures. Caroline Barclay (Dr Dana Shaw), Xander Berkeley (Ryan), Barbara Patrick (Samantha `Nuke-em' Rogers), Michael Zelniker (Archer), Bradford Tatum (Cody Harrison), Duane Whitaker (Potter), Brian Krause (Luke Harrison), Calvin Levels (Banton), Dale Dye (General Hurst), Earl Boen (Michael Isaacs)
Plot: In the year 2019 a moon, nicknamed Galileo's Child, is discovered heading on an impact course with the Earth. A team of spacefaring drillers are sent up to plant a nuclear warhead that will divert the moon's course. But during the course of the drilling the team uncover an alien tomb and unwittingly revive a creature that has been placed there by an alien people millennia ago and now starts slaughtering them.
`Within the Rock' is the directing and writing debut of Gary J. Tunnicliffe. Tunnicliffe is probably better known as a makeup effects supervisor at the Image Animation facility, being responsible for work on the likes of `Candyman', `Lord of Illusions' and `Blade'. Tunnicliffe makes a potentially interesting debut.
The film's premise seems to have been borrowed outright by this year's mega-budgeted `Armageddon'. There are an alarming number of similarities between the two films - in both films a group of roughnecks are landed on an astral body that is on a collision course with Earth in order to drill to its core and plant a nuke to divert its path. Of course the part of the story that `Armageddon' didn't borrow is the latter two-thirds where the film turns into yet another copy of `Alien'. But the similarities are enough to make one wonder. The set up in the first third is by far the better part of the film - the basic idea is established with a certain verisimilitude, the characters are given a certain degree of rounded depth over the usual faceless victims that fill most `Alien' clones and the discovery of the tomb has an appropriate sense of eeriness.
But unfortunately once its monster is unleashed the film travels down all too familiar grounds. It had sort of given the hope it might actually be a little bit more than a run through all the familiar cliches with its potentially interesting premise but the creature effects, the suspense set-ups and twists are all too familiar. And the film emerges as nothing more than another routine B-budget `Alien' copy. The plot never makes it too clear at times exactly how some of the plans to defeat the creature are supposed to work. There are also moments of plotting that are quite silly - like when an alien language in binary code is translated and instantly emerges as Old Testament English. The film has been made on a clear cut budget - we see little of the asteroid, we do see its explosion but never the ship landing on it. Nevertheless the film shows Tunnicliffe is capable of better things. Certainly the film is a better debut than Tunnicliffe's fellow Image Animation supervisor Bob Keen made the same year with the amazingly silly `Proteus'.
Copyright 1998 Richard Scheib
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


Beginners¶
This chapter is divided into the different programming languages, which will be introduced here (e.g. Python, R, JavaScript). All of those little sections will give you a little introduction into those tools, as well as some hints about the usage of the software. Most importantly we want you to support us in rewriting the section, adding references and erase mistakes. The benefit for you is that you will understand the frameworks or code even better as you start expressing it in simple words. We can tell from our working experience that every code snippet needs to be documented which helps everyone.
R¶
JavaScript¶
To-Do’s¶
[ ] - Write Introduction
[ ] - Introduction to Python
[ ] - What is a function?
#. [ ] - How to write a docstring? s


{% extends "registration/auth_base.html" %} {% block auth_content %}
Confirm your email ID, you have registered with this account
Back to login


| Branches Locations | Addresses (Street, City ,Postal code) |
|---|---|
| Seattle | 1022 Hill Haven Drive, Seattle, 98109 |
| Tokyo | 2923 Blue Spruce Lane, Tokyo, 21045 |
| Dubai | 2035 Doctors Drive, Dubai, 10185 |
| Paris | 2174 Taylor Street, Paris, 10528 |
| Lima | 187 Boundary Street, Lima, 32084 |
(All Branches are open from 6am to 7pm from Saturday to Thursday)
- Mail<EMAIL_ADDRESS>- Phone Number:<PHONE_NUMBER>
About Us
Salmon Cookies is the best place for you and your family.
We use very simple tools to provide our services.
And here are some of our other products:
Shirt
Stickers


URBAN LEGENDS: THE FINAL CUT
Reviewed by Harvey Karten Columbia Pictures/Phoenix Pictures Director: John Ottman Writer: Paul Harris Boardman, Scott Derrickson Cast: Jennifer Morrison, Joseph Lawrence, Anson Mount, Eva Mendes, Jessica Cauffiel, Marco Hofschneider, Matthew Davis, Loretta Devine, Hart Bovchner, Michael Bacall, Anthony Anderson
The narrative line that informs "Urban Legends: The Final Cut" is so hackneyed, so stale, that even the junior high school kids who were admitted to a special advance screening of this R-rated movie (which has one or two fairly explicit sex scenes and lots of gore) appeared burned out. The three fourteen-year-olds I chatted with on the way out said they'd seen it all before "hey, man lots o' times," they knew the killer would be the person least suspected, they even knew which quick scares were false alarms and which would lead to actual slashings.
The pretensions to Hitchcock that director John Ottman played around with in his directorial debut may have been as over the heads of the tykes in the audience as the master's birds, and when a couple of characters on screen bullied each other with accusations of campus power struggles, the young 'uns in their plush seats simply cried out "Hit him!" without understanding the drift of the controversy. But Hitchcockian birds, towers and intimations of paranoia notwithstanding, isn't it time to close the door on these same ol' same ol' pix? If you've seen 'em twenty times before, they're no longer scary and given the absence of wit in scripters Paul Harris Boardman and Scott Derrickson's dialogue, we look forward with apathy to their upcoming "Hellraiser Inferno" which was commissioned by Dimension Films.
One of the performers, Sandra (Jessica Cauffiel) did turn in one of the few decent comic scenes in the opening twenty minutes of a movie which started out with some promise and then fell into inanity. The big concept in Ottman's film is the notion of life vs. art, specifically, when is an action on the screen part of a film within a film and when is the action a representation of reality? The action takes place on a college campus (surprise!), actually filmed at a place in Ontario, Canada which has some surprisingly vivid architecture. We're in film school where a bunch of 20-year-old aspiring filmmakers are competing for the coveted Hitchcock award, whose attainment would yield $15,000 to the winner and guarantee him or her a Hollywood deal.
Chief among the contenders at Alpine University is Amy Mayfield (Jennifer Morrison), who breaks from her favorite genre of documentaries to try a Hithcockian suspense story for her thesis project. She hires a bunch of unpaid amateurs, proving that you get what you pay for. Her staff includes lesbian Vanessa (Eva Mendes--who gets to knock off one of the film's cutest, if terribly vulgar, one-liners); Simon (Marco Hofschneider), a pretentious, womanizing Continental type; a couple of grossly stereotypical gofers, Stan (Anthony Anderson) and Dirk (Michael Bacall), the specimens whom we know will be killed off around the middle of the story. Travis (Matthew Davis)is chief among the heartthrobs, the one we trust will end up with Amy. As a latex-bearing killer picks off these seniors, in one case removing a girl's kidney before cutting her up some more and guillotining the damsel, we temporarily pick up the brains we checked at the box to figure the identity of the maniac--who looks like a cross between a duellist out of The Count of Monte Cristo and a microphone.
The one arresting part of the film occurs at the very beginning during a stormy airplane ride in which Sandra (Jessica Cauffiel) screams in competition with the roar of the thunder as the plane hurtles toward the earth. Jennifer Morrison, who attempts to anchor the film, is not particularly appealing but she does a reasonable job with what the banal dialogue she's been given.
Rated R. Running Time: 100 minutes. (C) 2000 Harvey Karten<EMAIL_ADDRESS>The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


--- layout: default title: "Ploid Inc" fulltitle: "Ploid | Genomics Platform as a Service" excerpt: "" ---
HQ in Huntsville, AL 🚀


Wall Street opens at record high as trade optimism persists
The Dow Jones Industrial Average rose 43.54 points, or 0.16%, at the open to 28,079.76.
by ReutersWall Street's main stock indexes opened at record highs on November 19 on continued optimism that the United States and China would put an end to their damaging trade war, despite a slide in retail stocks after dour forecasts from Home Depot and Kohl's.
The Dow Jones Industrial Average rose 43.54 points, or 0.16%, at the open to 28,079.76.
The S&P 500 opened higher by 5.42 points, or 0.17%, at 3,127.45. The Nasdaq Composite gained 28.08 points, or 0.33%, to 8,578.02 at the opening bell.


INFOMENIA
Guide to your Career
Home
Find College
Sign Up
Login
Name:

Email:

Password:

Confirm:

Prefered branch:
COMPS
I.T.
EXTC
ETRX
MECH
Select District:
MUMBAI
PUNE
SANGLI
OTHER
I have passed 12
th
Percentage:
I accept all terms & conditions


CFFT1MX
Routine Documentation— Input: INTEGER MODE
The value of MODE on input determines the operation performed by
CFFT1MX
.
On input:
- MODE=0 : only initializations (specific to the value of N) are performed using a default plan; this is usually followed by calls to the same routine with MODE=-1 or 1.
- MODE=-1 : a forward transform is performed. Initializations are assumed to have been performed by a prior call to
CFFT1MX
.- MODE=1 : a backward (reverse) transform is performed. Initializations are assumed to have been performed by a prior call to
CFFT1MX
.- MODE=-2 : (default) initializations and a forward transform are performed.
- MODE=2 : (default) initializations and a backward transform are performed.
- MODE=100 : similar to MODE=0; only initializations (specific to the value of N) are performed, but these are based on a plan that is first generated by timing a subset of all possible plans and choosing the quickest (i.e. the FFT computation was timed as fastest based on the chosen plan). The plan generation phase may take a significant amount of time depending on the value of N.
— Input: LOGICAL INPL
On input: if INPL is .TRUE. then X is overwritten by the output sequences; otherwise the output sequences are returned in Y.
— Input/Output: COMPLEX X(1+(N-1)*INCX1+(NSEQ-1)*INCX2)
On input: X contains the NSEQ complex sequences of length N to be transformed; the ith element of sequence j is stored in X(1+(i-1)*INCX1+(j-1)*INCX2).
On output: if INPL is .TRUE. then X contains the transformed sequences in the same locations as on input; otherwise X remains unchanged.— Input: INTEGER INCX1
On input: INCX1 is the increment used to store successive elements of a given sequence in X (INCX1=1 for contiguous data).
Constraint: INCX1 > 0.— Input: INTEGER INCX2
On input: INCX2 is the increment used to store corresponding elements of successive sequences in X (INCX2=N for contiguous data).
Constraint: INCX2 > 0.— Output: COMPLEX Y(1+(N-1)*INCY1+(NSEQ-1)*INCY2)
On output: if INPL is .FALSE. then Y contains the transformed sequences with the ith element of sequence j stored in Y(1+(i-1)*INCY1+(j-1)*INCY2); otherwise Y is not referenced.
— Input: INTEGER INCY1
On input: INCY1 is the increment used to store successive elements of a given sequence in Y. If INPL is .TRUE. then INCY1 is not referenced.
Constraint: INCY1 > 0.— Input: INTEGER INCY2
On input: INCY2 is the increment used to store corresponding elements of successive sequences in Y (INCY2=N for contiguous data). If INPL is .TRUE. then INCY2 is not referenced.
Constraint: INCY2 > 0.
C Forward FFTs are performed unscaled and in-place on two C contiguous vectors stored in the first two columns of X. C Manipulations are stored in 2nd and 3rd columns of X which are C then transformed back. C COMPLEX X(N,3) SCALE = 1.0 INPL = .TRUE. CALL CFFT1MX(0,SCALE,INPL,2,N,X,1,N,DUM,1,N,COMM,INFO) CALL CFFT1MX(-1,SCALE,INPL,2,N,X,1,N,DUM,1,N,COMM,INFO) DO 10 I = 1, N X(I,3) = X(I,1)*CONJG(X(I,2))/REAL(N) X(I,2) = CMPLX(0.0D0,1.0D0)*X(I,2)/REAL(N) 10 CONTINUE CALL CFFT1MX(1,SCALE,INPL,2,N,X(1,2),1,N,DUM,1,N,COMM,INFO) |


The joints in this package are mainly designed to be used in kinematic loop structures. Every component consists of 3 elementary joints. These joints are combined in such a way that the kinematics of the 3 joints between frame_a and frame_b are computed from the movement of frame_a and frame_b, i.e., there are no constraints between frame_a and frame_b. This requires to solve a non-linear system of equations which is performed analytically (i.e., when a mathematical solution exists, it is computed efficiently and reliably). A detailed description how to use these joints is provided in MultiBody.UsersGuide.Tutorial.LoopStructures.AnalyticLoopHandling.
The assembly joints in this package are named JointXYZ where XYZ are the first letters of the elementary joints used in the component, in particular:
| P | Prismatic joint |
| R | Revolute joint |
| S | Spherical joint |
| U | Universal joint |
For example, JointUSR is an assembly joint consisting of a universal, a spherical and a revolute joint.
This package contains the following models:
| Model | Description |
|---|---|
| JointUPS | Universal - prismatic - spherical joint aggregation |
| JointUSR | Universal - spherical - revolute joint aggregation |
| JointUSP | Universal - spherical - prismatic joint aggregation |
| JointSSR | Spherical - spherical - revolute joint aggregation with an
optional mass point at the rod connecting the two spherical
joints |
| JointSSP | Spherical - spherical - prismatic joint aggregation with an
optional mass point at the rod connecting the two spherical
joints |
| JointRRR | Revolute - revolute - revolute joint aggregation for planar
loops |
| JointRRP | Revolute - revolute - prismatic joint aggregation for planar
loops |
Note, no component of this package has potential states, since the components are designed in such a way that the generalized coordinates of the used elementary joints are computed from the frame_a and frame_b coordinates. Still, it is possible to use the components in a tree structure. In this case states are selected from bodies that are connected to the frame_a or frame_b side of the component. In most cases this gives a less efficient solution, as if elementary joints of package Modelica.Mechanics.MultiBody.Joints would be used directly.
The analytic handling of kinematic loops by using joint aggregations with 6 degrees of freedom as provided in this package, is a new methodology. It is based on a more general method for solving non-linear equations of kinematic loops developed by Woernle and Hiller. An automatic application of this more general method is difficult, and a manual application is only suited for specialists in this field. The method introduced here is a compromise: It can be quite easily applied by an end user, but for a smaller class of kinematic loops. The method of the "characteristic pair of joints" from Woernle and Hiller is described in:
| Name | Description |
|---|---|
| JointUPS | Universal - prismatic - spherical joint aggregation (no constraints, no potential states) |
| JointUSR | Universal - spherical - revolute joint aggregation (no constraints, no potential states) |
| JointUSP | Universal - spherical - prismatic joint aggregation (no constraints, no potential states) |
| JointSSR | Spherical - spherical - revolute joint aggregation with mass (no constraints, no potential states) |
| JointSSP | Spherical - spherical - prismatic joint aggregation with mass (no constraints, no potential states) |
| JointRRR | Planar revolute - revolute - revolute joint aggregation (no constraints, no potential states) |
| JointRRP | Planar revolute - revolute - prismatic joint aggregation (no constraints, no potential states) |


Enumerables
What are they
4/12/15
First off, what is an enumerable? According to the Well-Grounded Rubyist by David A. Black an Enumerable is a module that "endows collection objects with the knowledge of how to traverse and transform themselves in a great number of ways." Simply put, enumerable is a method used to count and modify objects in a collection.
There are lots of uses for enumerables such as Enumerable#map which lets you change each item in an array in the same manner. Enumerable#group_by which according to ruby-doc.org, lets you create hashes where "the keys are the evaluated keys from the block and the values are array of elements in the collection that correspond to the key". Enumerable#cycle lets you call a block (block is the code that tells the enumerable what to do) on each element of the array a designated or infinite amount of times. In this post we will be discussing the Enumerable#cycle at a greater depth.
As I said earlier, the Enumerable#cycle can let you call a block of code while cycling through the array an infinite amount of times. For example: array = [1, 2, 3, 4] array.cycle { |x| puts x } # this will print 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, and so on until the user uses ctrl-c to break the cycle array.cycle(2) { |x| puts x } # this will print 1, 2, 3, 4, 1, 2, 3, 4 The 2nd example only printed out 2 cycles because we wrote ".cycle(2)".
So far we have seen how .cycle can be used to do things an infinite amount of times or a finite amount of times, but there are much more options when combined with other methods. For example if we just wanted to go through each of the elements of an array. Lets create an array for the days of the week. days = %w{ Monday Tuesday Wednesday Thursday Friday Saturday Sunday } # "%w{}" adds in the quotes and commas for you when creating the array days = days.cycle # this turns the array into a cycle Now we can use another enumerator .next to bring up each of the days days.next #=> Monday days.next #=> Tuesday days.next #=> Wednesday
Lets see this in action. Lets pretend that you have a number of friends who are insanely jealous of each other. You want to visit one friend each day of the week but you don't want to visit any friend more than the others. We are going to create a new array for friends and will use the days array we created earlier. friends = %w{ Bob Janet Sue Mike Clarissa}.cycle # We can add cycle directly to the end of the literal notation. Now lets create a schedule for visiting with them for the course of 2 weeks (14 days) 14.times do day = days.next friend = friends.next puts "#{day}: visit #{friend}" end => Monday: visit Bob Tuesday: visit Janet Wednesday: visit Sue Thursday: visit Mike Friday: visit Clarissa Saturday: visit Bob Sunday: visit Janet Monday: visit Sue Tuesday: visit Mike Wednesday: visit Clarissa Thursday: visit Bob Friday: visit Janet Saturday: visit Sue Sunday: visit Mike Note if you ever want to reset the cycle back to the beginning you can use .rewind friends.rewind # brings you back to Bob, when .next would have brought you Clarissa in this example.
#DBCRuby


My Entire Body Was Being Crushed.
| DOSE: |
repeated |
oral |
Valerian |
(pill / tablet) |
I started taking valerian to ease some anxiety and general stir-craziness. I was at the point where I was easily aggitated by many tiny stressful situations. I took these pills with a cup of water before bedtime usually around midnight. This first time I took one valerian pill, and felt tired within a half hour, the next day I woke feeling like a saint, and felt unusually kind during situations that bothered me before. I also had felt more energetic the whole day, after an hour or two of mild grogginess upon awakening. The next time I took two pills and had the same effects. It began as a miracle.
After taking a week break, and having such success I decided to try it again. Two pills did nothing for me the third time, except make me tired and somewhat unwilling to sleep for 2 hours while being exhausted. The fourth time I took it I felt aggitated and could not sleep for 3 hours, the next day was never the same, and I felt no different. So I cut the dose to 1 pill the next day, and I felt like my dreams were becomming too deep, I would wake up several times in the middle of the night because of numbness in my arms and legs.
The sixth time, the numbness came on within 30 minutes of lying down. The seventh time I tried to dodge the numb feeling by taking it immediately before bed - this time was weirder because I felt like I couldn't wake up, like I had been paralyzed.
 I felt like I wanted to wake up - I decided I would start moving my arms - but the more I tried to move them the more numb / restrained I felt. Then I tried to do a sit up and felt completely paralyzed. I felt like my entire body was being crushed.  I was certain this was the end - that I had finally killed myself with herbs. I told myself 'No, you can't let it end this way' and willed it away. I don't know it was a dream or reality to this day, but I suspect it was a dream inside a dream. It is a shame because I was so sure the effects were GREAT and then it never worked the same. Even when I cut the dose to half a pill I had the same insomnia/numbness.
Experience Reports are the writings and opinions of the individual authors who submit them.
Some of the activities described are dangerous and/or illegal and none are recommended by Erowid.


In fact it took more than two hours to create this blog that you are reading right now, but that included doing several other tasks like fixing some issues on a client's site, browsing facebook, writing this article and fixing the kitchen's curtain for my mom.
What You Need
- Terminal window
- Text editor
- Github Account
- Disqus Account
- A Domain Name (Optional)
Now that you have everything needed. Let's start building our blog system.
Installing Jekyll
Jekyll is an open source program, written in Ruby by Tom Preston-Werner, GitHub's co-founder. Jekyll is a simple, blog-aware, static site generator for personal, project, or organization sites. --Wikipedia
Following the installation steps mentioned on Jekyll's Official Website do the following:
gem install jekyll jekyll new my-awesome-site cd my-awesome-site jekyll serve
In your browser address bar type http://<IP_ADDRESS>:4000 or whatever address jekyll serve provides and hit enter.
Oops the blog is ready! It took less than a minute! But I promised you that you will spend two hours, so let's repeat the above 120 times :p
In fact, what we did is that we just made sure that jekyll is working with no issues. Go ahead and explore the code in my-awesome-site folder. When you feel ready continue to the next steps.
Installing a Bootstrap Powered Jekyll Theme
Googling for Jekyll themes I came across many beautiful themes from which I chose the following one:
https://github.com/IronSummitMedia/startbootstrap-clean-blog-jekyll
So, let's install it:
Make sure you cd ..
out of the previously installed folder
git clone https://github.com/IronSummitMedia/startbootstrap-clean-blog-jekyll.git mv startbootstrap-clean-blog-jekyll mysite cd mysite jekyll serve
Go to http://<IP_ADDRESS>:4000 again and you will see our blog with the new theme
Modify the Theme
If you are familiar with Bootstrap and LESS which I assume you are ... you can simply modify the files in the "less" folder in the root of "mysite" folder.
Main Configuration and Personalization
With your favourite text editor open the "_config.yml" file and edit the values under #site settings.
Adding Your First Post
in the folder named "_layouts" you will find all the posts in the blog as a file for each post. You will probably want to delete all of them and leave just one as a template for your future posts. Edit the template that's left and make sure you keep the naming conversion yyyy-mm-dd-page-title-seperated-with-hypens.markdown
Creating the Comment funcationality
If you don't have an account on Disqus, create one. Then follow the instructions on https://publishers.disqus.com/engage?utm_source=Home-Nav until you get the embedding code.
With your editor open the file "_layouts/post.html" and put the embedding code before the forth closing div from bottom.
Uploading your site to github
Follow the instructions on this page https://pages.github.com/
That's all for today... let me know which point needs to be described more extensively and I'll write a seperate post for it. Thanks for reading.


Profile
Friends
Additional information
Friend's of Doncho
Pesho Ivanov
student
Vankata
Sofware developer
Bai Gosho
System admin


A product vision represents the core essence of its product or product line. It also sets the direction for where a product is headed, or the end state for what a product will deliver in the future. Your vision serves as the north star for every action taken to enhance the product; if adding a feature will not help your product achieve its vision, then the value of that feature should be diminished. This is crucial information that your team must understand to develop and maintain a winning product. To keep your vision grounded in reality, imagine yourself reading reviews about your product in five years. What would you expect those reviews to say?
Edward Izvorean - Thoughts - Understanding product vision is important because if the whole group does not know what they are doing, the overall goal can get lost. We are working towards an end product and if people keep getting side tracked from it, it takes longer to get done, things get missed and mistakes are made.
Matt Carrillo - Thoughts - I think that understanding product vision is important because when a team is analyzing and building each individual piece of a product, it can become easy to lose sight of what the product is supposed to be as a whole.
Justin Baker - Thoughts - Product vision is important in order to understand what you want your final product to be. It allows someone to decide what features it has and the flexibility of the project.


Your client does not have the permission to request this URL from this server. Go back to DroidWikiThat’s all we know.


Dónde estaremos presentando:
| Evento | Ubicación | Fecha |
|---|
Eventos Pasados:
| Eventos | Ubicación | Fecha |
|---|---|---|
| ngVikings | Oslo, Norway | May 25-26 conference, 27 workshops, 2020 |
| ng-conf | Salt Lake City, Utah | April 1-3, 2020 |
| ngIndia | Delhi, India | Feb 29, 2020 |
| ReactiveConf | Prague, Czech Republic | October 30 - November 1, 2019 |
| NG Rome MMXIX | Rome, Italy | Oct 6th workshops, 7th conference, 2019 |
| AngularConnect | London, UK | September 19-20, 2019 |
| NG-DE | Berlin, Germany | August 29th workshops, 30-31 conference, 2019 |
| ng-japan | Tokyo, Japan | July 13, 2019 |
| ngVikings | Copenhagen, Denmark | May 26 (workshops), 27-28 (conference), 2019 |
| ng-conf | Salt Lake City, Utah | May 1-3, 2019 |
| ng-India | Gurgaon, India | February 23, 2019 |
| ngAtlanta | Atlanta, Georgia | January 9-12, 2019 |
| AngularConnect | London, United Kingdom | November 5-7, 2018 |
| ReactiveConf | Prague, Czech Republic | October 29-31, 2018 |
| AngularMix | Orlando, Florida | October 10-12, 2018 |
| Angular Conf Australia | Melbourne, Australia | Jun 22, 2018 |
| ng-japan | Tokyo, Japan | Jun 16, 2018 |
| WeAreDevelopers | Vienna, Austria | May 16-18, 2018 |
| ng-conf | Salt Lake City, Utah | April 18-20, 2018 |
| ngVikings | Helsinki, Finland | March 1-2, 2018 |
| ngAtlanta | Atlanta, Georgia | January 30, 2018 |


|
|
||
|
|
An export company which exports goods produced in India are shipped to another country for future sale or trade. Exports are a essential component of a country’s economy, as the sale of such goods adds to the producing nation's gross output. B3 exports want to take part in the economic growth of our country.
We B3 Exports engaged in exporting Mats which made of a special kind of grass called "Korai". The Korai Mat weaving craft is a customary skill of the people in southern part of Tamil Nadu, India.
This is a traditional craft and being done by the people of the villages. Korai mats are formed from natural fibre resource collected from korai grass which are amphibious grown locally for the purpose of manufacturing mat.


The Feed Input is a component specifically designed to allow users to type their own notes and add them to a feed.
- The user is only allowed to enter plain text via the Feed Input.
- As the user enters more text into the text area, the Feed Input should grow in height to accommodate.