RubyGems - rroonga - Versions diffs - 6.0.7-x64-mingw32 → 6.0.9-x64-mingw32 - Mend

rroonga 6.0.7-x64-mingw32 → 6.0.9-x64-mingw32

Files changed (797) hide show

data/vendor/local/share/doc/pcre/html/pcreprecompile.html ADDED Viewed

@@ -0,0 +1,163 @@
+<html>
+<head>
+<title>pcreprecompile specification</title>
+</head>
+<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
+<h1>pcreprecompile man page</h1>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>
+<p>
+This page is part of the PCRE HTML documentation. It was generated automatically
+from the original man page. If there is any nonsense in it, please consult the
+man page, in case the conversion went wrong.
+<br>
+<ul>
+<li><a name="TOC1" href="#SEC1">SAVING AND RE-USING PRECOMPILED PCRE PATTERNS</a>
+<li><a name="TOC2" href="#SEC2">SAVING A COMPILED PATTERN</a>
+<li><a name="TOC3" href="#SEC3">RE-USING A PRECOMPILED PATTERN</a>
+<li><a name="TOC4" href="#SEC4">COMPATIBILITY WITH DIFFERENT PCRE RELEASES</a>
+<li><a name="TOC5" href="#SEC5">AUTHOR</a>
+<li><a name="TOC6" href="#SEC6">REVISION</a>
+</ul>
+<br><a name="SEC1" href="#TOC1">SAVING AND RE-USING PRECOMPILED PCRE PATTERNS</a><br>
+<P>
+If you are running an application that uses a large number of regular
+expression patterns, it may be useful to store them in a precompiled form
+instead of having to compile them every time the application is run.
+If you are not using any private character tables (see the
+<a href="pcre_maketables.html"><b>pcre_maketables()</b></a>
+documentation), this is relatively straightforward. If you are using private
+tables, it is a little bit more complicated. However, if you are using the
+just-in-time optimization feature, it is not possible to save and reload the
+JIT data.
+</P>
+<P>
+If you save compiled patterns to a file, you can copy them to a different host
+and run them there. If the two hosts have different endianness (byte order),
+you should run the <b>pcre[16|32]_pattern_to_host_byte_order()</b> function on the
+new host before trying to match the pattern. The matching functions return
+PCRE_ERROR_BADENDIANNESS if they detect a pattern with the wrong endianness.
+</P>
+<P>
+Compiling regular expressions with one version of PCRE for use with a different
+version is not guaranteed to work and may cause crashes, and saving and
+restoring a compiled pattern loses any JIT optimization data.
+</P>
+<br><a name="SEC2" href="#TOC1">SAVING A COMPILED PATTERN</a><br>
+<P>
+The value returned by <b>pcre[16|32]_compile()</b> points to a single block of
+memory that holds the compiled pattern and associated data. You can find the
+length of this block in bytes by calling <b>pcre[16|32]_fullinfo()</b> with an
+argument of PCRE_INFO_SIZE. You can then save the data in any appropriate
+manner. Here is sample code for the 8-bit library that compiles a pattern and
+writes it to a file. It assumes that the variable <i>fd</i> refers to a file
+that is open for output:
+<pre>
+  int erroroffset, rc, size;
+  char *error;
+  pcre *re;
+  re = pcre_compile("my pattern", 0, &error, &erroroffset, NULL);
+  if (re == NULL) { ... handle errors ... }
+  rc = pcre_fullinfo(re, NULL, PCRE_INFO_SIZE, &size);
+  if (rc &#60; 0) { ... handle errors ... }
+  rc = fwrite(re, 1, size, fd);
+  if (rc != size) { ... handle errors ... }
+</pre>
+In this example, the bytes that comprise the compiled pattern are copied
+exactly. Note that this is binary data that may contain any of the 256 possible
+byte values. On systems that make a distinction between binary and non-binary
+data, be sure that the file is opened for binary output.
+</P>
+<P>
+If you want to write more than one pattern to a file, you will have to devise a
+way of separating them. For binary data, preceding each pattern with its length
+is probably the most straightforward approach. Another possibility is to write
+out the data in hexadecimal instead of binary, one pattern to a line.
+</P>
+<P>
+Saving compiled patterns in a file is only one possible way of storing them for
+later use. They could equally well be saved in a database, or in the memory of
+some daemon process that passes them via sockets to the processes that want
+them.
+</P>
+<P>
+If the pattern has been studied, it is also possible to save the normal study
+data in a similar way to the compiled pattern itself. However, if the
+PCRE_STUDY_JIT_COMPILE was used, the just-in-time data that is created cannot
+be saved because it is too dependent on the current environment. When studying
+generates additional information, <b>pcre[16|32]_study()</b> returns a pointer to a
+<b>pcre[16|32]_extra</b> data block. Its format is defined in the
+<a href="pcreapi.html#extradata">section on matching a pattern</a>
+in the
+<a href="pcreapi.html"><b>pcreapi</b></a>
+documentation. The <i>study_data</i> field points to the binary study data, and
+this is what you must save (not the <b>pcre[16|32]_extra</b> block itself). The
+length of the study data can be obtained by calling <b>pcre[16|32]_fullinfo()</b>
+with an argument of PCRE_INFO_STUDYSIZE. Remember to check that
+<b>pcre[16|32]_study()</b> did return a non-NULL value before trying to save the
+study data.
+</P>
+<br><a name="SEC3" href="#TOC1">RE-USING A PRECOMPILED PATTERN</a><br>
+<P>
+Re-using a precompiled pattern is straightforward. Having reloaded it into main
+memory, called <b>pcre[16|32]_pattern_to_host_byte_order()</b> if necessary, you
+pass its pointer to <b>pcre[16|32]_exec()</b> or <b>pcre[16|32]_dfa_exec()</b> in
+the usual way.
+</P>
+<P>
+However, if you passed a pointer to custom character tables when the pattern
+was compiled (the <i>tableptr</i> argument of <b>pcre[16|32]_compile()</b>), you
+must now pass a similar pointer to <b>pcre[16|32]_exec()</b> or
+<b>pcre[16|32]_dfa_exec()</b>, because the value saved with the compiled pattern
+will obviously be nonsense. A field in a <b>pcre[16|32]_extra()</b> block is used
+to pass this data, as described in the
+<a href="pcreapi.html#extradata">section on matching a pattern</a>
+in the
+<a href="pcreapi.html"><b>pcreapi</b></a>
+documentation.
+</P>
+<P>
+<b>Warning:</b> The tables that <b>pcre_exec()</b> and <b>pcre_dfa_exec()</b> use
+must be the same as those that were used when the pattern was compiled. If this
+is not the case, the behaviour is undefined.
+</P>
+<P>
+If you did not provide custom character tables when the pattern was compiled,
+the pointer in the compiled pattern is NULL, which causes the matching
+functions to use PCRE's internal tables. Thus, you do not need to take any
+special action at run time in this case.
+</P>
+<P>
+If you saved study data with the compiled pattern, you need to create your own
+<b>pcre[16|32]_extra</b> data block and set the <i>study_data</i> field to point
+to the reloaded study data. You must also set the PCRE_EXTRA_STUDY_DATA bit in
+the <i>flags</i> field to indicate that study data is present. Then pass the
+<b>pcre[16|32]_extra</b> block to the matching function in the usual way. If the
+pattern was studied for just-in-time optimization, that data cannot be saved,
+and so is lost by a save/restore cycle.
+</P>
+<br><a name="SEC4" href="#TOC1">COMPATIBILITY WITH DIFFERENT PCRE RELEASES</a><br>
+<P>
+In general, it is safest to recompile all saved patterns when you update to a
+new PCRE release, though not all updates actually require this.
+</P>
+<br><a name="SEC5" href="#TOC1">AUTHOR</a><br>
+<P>
+Philip Hazel
+<br>
+University Computing Service
+<br>
+Cambridge CB2 3QH, England.
+<br>
+</P>
+<br><a name="SEC6" href="#TOC1">REVISION</a><br>
+<P>
+Last updated: 12 November 2013
+<br>
+Copyright &copy; 1997-2013 University of Cambridge.
+<br>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>

data/vendor/local/share/doc/pcre/html/pcresample.html ADDED Viewed

@@ -0,0 +1,110 @@
+<html>
+<head>
+<title>pcresample specification</title>
+</head>
+<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
+<h1>pcresample man page</h1>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>
+<p>
+This page is part of the PCRE HTML documentation. It was generated automatically
+from the original man page. If there is any nonsense in it, please consult the
+man page, in case the conversion went wrong.
+<br>
+<br><b>
+PCRE SAMPLE PROGRAM
+</b><br>
+<P>
+A simple, complete demonstration program, to get you started with using PCRE,
+is supplied in the file <i>pcredemo.c</i> in the PCRE distribution. A listing of
+this program is given in the
+<a href="pcredemo.html"><b>pcredemo</b></a>
+documentation. If you do not have a copy of the PCRE distribution, you can save
+this listing to re-create <i>pcredemo.c</i>.
+</P>
+<P>
+The demonstration program, which uses the original PCRE 8-bit library, compiles
+the regular expression that is its first argument, and matches it against the
+subject string in its second argument. No PCRE options are set, and default
+character tables are used. If matching succeeds, the program outputs the
+portion of the subject that matched, together with the contents of any captured
+substrings.
+</P>
+<P>
+If the -g option is given on the command line, the program then goes on to
+check for further matches of the same regular expression in the same subject
+string. The logic is a little bit tricky because of the possibility of matching
+an empty string. Comments in the code explain what is going on.
+</P>
+<P>
+If PCRE is installed in the standard include and library directories for your
+operating system, you should be able to compile the demonstration program using
+this command:
+<pre>
+  gcc -o pcredemo pcredemo.c -lpcre
+</pre>
+If PCRE is installed elsewhere, you may need to add additional options to the
+command line. For example, on a Unix-like system that has PCRE installed in
+<i>/usr/local</i>, you can compile the demonstration program using a command
+like this:
+<pre>
+  gcc -o pcredemo -I/usr/local/include pcredemo.c -L/usr/local/lib -lpcre
+</pre>
+In a Windows environment, if you want to statically link the program against a
+non-dll <b>pcre.a</b> file, you must uncomment the line that defines PCRE_STATIC
+before including <b>pcre.h</b>, because otherwise the <b>pcre_malloc()</b> and
+<b>pcre_free()</b> exported functions will be declared
+<b>__declspec(dllimport)</b>, with unwanted results.
+</P>
+<P>
+Once you have compiled and linked the demonstration program, you can run simple
+tests like this:
+<pre>
+  ./pcredemo 'cat|dog' 'the cat sat on the mat'
+  ./pcredemo -g 'cat|dog' 'the dog sat on the cat'
+</pre>
+Note that there is a much more comprehensive test program, called
+<a href="pcretest.html"><b>pcretest</b>,</a>
+which supports many more facilities for testing regular expressions and both
+PCRE libraries. The
+<a href="pcredemo.html"><b>pcredemo</b></a>
+program is provided as a simple coding example.
+</P>
+<P>
+If you try to run
+<a href="pcredemo.html"><b>pcredemo</b></a>
+when PCRE is not installed in the standard library directory, you may get an
+error like this on some operating systems (e.g. Solaris):
+<pre>
+  ld.so.1: a.out: fatal: libpcre.so.0: open failed: No such file or directory
+</pre>
+This is caused by the way shared library support works on those systems. You
+need to add
+<pre>
+  -R/usr/local/lib
+</pre>
+(for example) to the compile command to get round this problem.
+</P>
+<br><b>
+AUTHOR
+</b><br>
+<P>
+Philip Hazel
+<br>
+University Computing Service
+<br>
+Cambridge CB2 3QH, England.
+<br>
+</P>
+<br><b>
+REVISION
+</b><br>
+<P>
+Last updated: 10 January 2012
+<br>
+Copyright &copy; 1997-2012 University of Cambridge.
+<br>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>

data/vendor/local/share/doc/pcre/html/pcrestack.html ADDED Viewed

@@ -0,0 +1,225 @@
+<html>
+<head>
+<title>pcrestack specification</title>
+</head>
+<body bgcolor="#FFFFFF" text="#00005A" link="#0066FF" alink="#3399FF" vlink="#2222BB">
+<h1>pcrestack man page</h1>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>
+<p>
+This page is part of the PCRE HTML documentation. It was generated automatically
+from the original man page. If there is any nonsense in it, please consult the
+man page, in case the conversion went wrong.
+<br>
+<br><b>
+PCRE DISCUSSION OF STACK USAGE
+</b><br>
+<P>
+When you call <b>pcre[16|32]_exec()</b>, it makes use of an internal function
+called <b>match()</b>. This calls itself recursively at branch points in the
+pattern, in order to remember the state of the match so that it can back up and
+try a different alternative if the first one fails. As matching proceeds deeper
+and deeper into the tree of possibilities, the recursion depth increases. The
+<b>match()</b> function is also called in other circumstances, for example,
+whenever a parenthesized sub-pattern is entered, and in certain cases of
+repetition.
+</P>
+<P>
+Not all calls of <b>match()</b> increase the recursion depth; for an item such
+as a* it may be called several times at the same level, after matching
+different numbers of a's. Furthermore, in a number of cases where the result of
+the recursive call would immediately be passed back as the result of the
+current call (a "tail recursion"), the function is just restarted instead.
+</P>
+<P>
+The above comments apply when <b>pcre[16|32]_exec()</b> is run in its normal
+interpretive manner. If the pattern was studied with the
+PCRE_STUDY_JIT_COMPILE option, and just-in-time compiling was successful, and
+the options passed to <b>pcre[16|32]_exec()</b> were not incompatible, the matching
+process uses the JIT-compiled code instead of the <b>match()</b> function. In
+this case, the memory requirements are handled entirely differently. See the
+<a href="pcrejit.html"><b>pcrejit</b></a>
+documentation for details.
+</P>
+<P>
+The <b>pcre[16|32]_dfa_exec()</b> function operates in an entirely different way,
+and uses recursion only when there is a regular expression recursion or
+subroutine call in the pattern. This includes the processing of assertion and
+"once-only" subpatterns, which are handled like subroutine calls. Normally,
+these are never very deep, and the limit on the complexity of
+<b>pcre[16|32]_dfa_exec()</b> is controlled by the amount of workspace it is given.
+However, it is possible to write patterns with runaway infinite recursions;
+such patterns will cause <b>pcre[16|32]_dfa_exec()</b> to run out of stack. At
+present, there is no protection against this.
+</P>
+<P>
+The comments that follow do NOT apply to <b>pcre[16|32]_dfa_exec()</b>; they are
+relevant only for <b>pcre[16|32]_exec()</b> without the JIT optimization.
+</P>
+<br><b>
+Reducing <b>pcre[16|32]_exec()</b>'s stack usage
+</b><br>
+<P>
+Each time that <b>match()</b> is actually called recursively, it uses memory
+from the process stack. For certain kinds of pattern and data, very large
+amounts of stack may be needed, despite the recognition of "tail recursion".
+You can often reduce the amount of recursion, and therefore the amount of stack
+used, by modifying the pattern that is being matched. Consider, for example,
+this pattern:
+<pre>
+  ([^&#60;]|&#60;(?!inet))+
+</pre>
+It matches from wherever it starts until it encounters "&#60;inet" or the end of
+the data, and is the kind of pattern that might be used when processing an XML
+file. Each iteration of the outer parentheses matches either one character that
+is not "&#60;" or a "&#60;" that is not followed by "inet". However, each time a
+parenthesis is processed, a recursion occurs, so this formulation uses a stack
+frame for each matched character. For a long string, a lot of stack is
+required. Consider now this rewritten pattern, which matches exactly the same
+strings:
+<pre>
+  ([^&#60;]++|&#60;(?!inet))+
+</pre>
+This uses very much less stack, because runs of characters that do not contain
+"&#60;" are "swallowed" in one item inside the parentheses. Recursion happens only
+when a "&#60;" character that is not followed by "inet" is encountered (and we
+assume this is relatively rare). A possessive quantifier is used to stop any
+backtracking into the runs of non-"&#60;" characters, but that is not related to
+stack usage.
+</P>
+<P>
+This example shows that one way of avoiding stack problems when matching long
+subject strings is to write repeated parenthesized subpatterns to match more
+than one character whenever possible.
+</P>
+<br><b>
+Compiling PCRE to use heap instead of stack for <b>pcre[16|32]_exec()</b>
+</b><br>
+<P>
+In environments where stack memory is constrained, you might want to compile
+PCRE to use heap memory instead of stack for remembering back-up points when
+<b>pcre[16|32]_exec()</b> is running. This makes it run a lot more slowly, however.
+Details of how to do this are given in the
+<a href="pcrebuild.html"><b>pcrebuild</b></a>
+documentation. When built in this way, instead of using the stack, PCRE obtains
+and frees memory by calling the functions that are pointed to by the
+<b>pcre[16|32]_stack_malloc</b> and <b>pcre[16|32]_stack_free</b> variables. By
+default, these point to <b>malloc()</b> and <b>free()</b>, but you can replace
+the pointers to cause PCRE to use your own functions. Since the block sizes are
+always the same, and are always freed in reverse order, it may be possible to
+implement customized memory handlers that are more efficient than the standard
+functions.
+</P>
+<br><b>
+Limiting <b>pcre[16|32]_exec()</b>'s stack usage
+</b><br>
+<P>
+You can set limits on the number of times that <b>match()</b> is called, both in
+total and recursively. If a limit is exceeded, <b>pcre[16|32]_exec()</b> returns an
+error code. Setting suitable limits should prevent it from running out of
+stack. The default values of the limits are very large, and unlikely ever to
+operate. They can be changed when PCRE is built, and they can also be set when
+<b>pcre[16|32]_exec()</b> is called. For details of these interfaces, see the
+<a href="pcrebuild.html"><b>pcrebuild</b></a>
+documentation and the
+<a href="pcreapi.html#extradata">section on extra data for <b>pcre[16|32]_exec()</b></a>
+in the
+<a href="pcreapi.html"><b>pcreapi</b></a>
+documentation.
+</P>
+<P>
+As a very rough rule of thumb, you should reckon on about 500 bytes per
+recursion. Thus, if you want to limit your stack usage to 8Mb, you should set
+the limit at 16000 recursions. A 64Mb stack, on the other hand, can support
+around 128000 recursions.
+</P>
+<P>
+In Unix-like environments, the <b>pcretest</b> test program has a command line
+option (<b>-S</b>) that can be used to increase the size of its stack. As long
+as the stack is large enough, another option (<b>-M</b>) can be used to find the
+smallest limits that allow a particular pattern to match a given subject
+string. This is done by calling <b>pcre[16|32]_exec()</b> repeatedly with different
+limits.
+</P>
+<br><b>
+Obtaining an estimate of stack usage
+</b><br>
+<P>
+The actual amount of stack used per recursion can vary quite a lot, depending
+on the compiler that was used to build PCRE and the optimization or debugging
+options that were set for it. The rule of thumb value of 500 bytes mentioned
+above may be larger or smaller than what is actually needed. A better
+approximation can be obtained by running this command:
+<pre>
+  pcretest -m -C
+</pre>
+The <b>-C</b> option causes <b>pcretest</b> to output information about the
+options with which PCRE was compiled. When <b>-m</b> is also given (before
+<b>-C</b>), information about stack use is given in a line like this:
+<pre>
+  Match recursion uses stack: approximate frame size = 640 bytes
+</pre>
+The value is approximate because some recursions need a bit more (up to perhaps
+16 more bytes).
+</P>
+<P>
+If the above command is given when PCRE is compiled to use the heap instead of
+the stack for recursion, the value that is output is the size of each block
+that is obtained from the heap.
+</P>
+<br><b>
+Changing stack size in Unix-like systems
+</b><br>
+<P>
+In Unix-like environments, there is not often a problem with the stack unless
+very long strings are involved, though the default limit on stack size varies
+from system to system. Values from 8Mb to 64Mb are common. You can find your
+default limit by running the command:
+<pre>
+  ulimit -s
+</pre>
+Unfortunately, the effect of running out of stack is often SIGSEGV, though
+sometimes a more explicit error message is given. You can normally increase the
+limit on stack size by code such as this:
+<pre>
+  struct rlimit rlim;
+  getrlimit(RLIMIT_STACK, &rlim);
+  rlim.rlim_cur = 100*1024*1024;
+  setrlimit(RLIMIT_STACK, &rlim);
+</pre>
+This reads the current limits (soft and hard) using <b>getrlimit()</b>, then
+attempts to increase the soft limit to 100Mb using <b>setrlimit()</b>. You must
+do this before calling <b>pcre[16|32]_exec()</b>.
+</P>
+<br><b>
+Changing stack size in Mac OS X
+</b><br>
+<P>
+Using <b>setrlimit()</b>, as described above, should also work on Mac OS X. It
+is also possible to set a stack size when linking a program. There is a
+discussion about stack sizes in Mac OS X at this web site:
+<a href="http://developer.apple.com/qa/qa2005/qa1419.html">http://developer.apple.com/qa/qa2005/qa1419.html.</a>
+</P>
+<br><b>
+AUTHOR
+</b><br>
+<P>
+Philip Hazel
+<br>
+University Computing Service
+<br>
+Cambridge CB2 3QH, England.
+<br>
+</P>
+<br><b>
+REVISION
+</b><br>
+<P>
+Last updated: 24 June 2012
+<br>
+Copyright &copy; 1997-2012 University of Cambridge.
+<br>
+<p>
+Return to the <a href="index.html">PCRE index page</a>.
+</p>