Commit 2779b419 authored by Radford Neal's avatar Radford Neal

Files from R-2.13.2.

parent 8cd16c68
This source diff could not be displayed because it is too large. You can view the blob instead.
No preview for this file type
Revision: 56322
Last Changed Date: 2011-07-08
Revision: 57111
Last Changed Date: 2011-09-30
This diff is collapsed.
......@@ -436,15 +436,6 @@ AC_ARG_WITH([ICU],
[R_ARG_USE(ICU)],
[use_ICU=yes])
## Byte-compilation of packages.
AC_ARG_ENABLE([byte-compiled-packages],
[AS_HELP_STRING([--enable-byte-compiled-packages],
[(not yet operational) byte-compile R packages @<:@no@:>@])],
[want_byte_compiled_packages="${enableval}"],
[want_byte_compiled_packages=no])
AM_CONDITIONAL(BYTE_COMPILE_PACKAGES,
[test "x${want_byte_compiled_packages}" = xyes])
### ** Precious variables.
AC_ARG_VAR([R_PRINTCMD],
......@@ -1853,7 +1844,7 @@ AC_CHECK_DECLS([mkdtemp, snprintf, strdup, strncasecmp, vsnprintf])
AC_SEARCH_LIBS(connect, [socket])
AC_SEARCH_LIBS(gethostbyname, [nsl socket])
AC_SEARCH_LIBS(xdr_string, [nsl])
AC_SEARCH_LIBS(xdr_string, [nsl tirpc])
R_FUNC___SETFPUCW
R_FUNC_CALLOC
if test "${ac_cv_have_decl_isfinite}" = "yes"; then
......
......@@ -15,6 +15,7 @@ Kurt Hornik
Stefano Iacus
Ross Ihaka
Friedrich Leisch
Uwe Ligges
Thomas Lumley
Martin Maechler
Duncan Murdoch
......
......@@ -327,7 +327,7 @@ According to http://www.netlib.org/cephes/readme
src/extra/pcre/LICENCE
src/extra/pcre/*.[ch]
Copyright (c) 1997-2010 University of Cambridge
Copyright (c) 1997-2011 University of Cambridge
All rights reserved.
See file src/extra/pcre/LICENCE. For binary builds of R that requires
......
R FAQ
Frequently Asked Questions on R
Version 2.13.2011-07-05
Version 2.13.2011-09-17
ISBN 3-900051-08-9
Kurt Hornik
......@@ -101,6 +101,7 @@ R FAQ
7.39 How do I create a plot with two y-axes?
7.40 How do I access the source code for a function?
7.41 Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?
7.42 Why is R apparently not releasing memory?
8 R Programming
8.1 How should I write summary methods?
8.2 How can I debug dynamically loaded code?
......@@ -148,10 +149,9 @@ The latest version of this document is always available from
`http://CRAN.R-project.org/doc/FAQ/'
From there, you can obtain versions converted to plain ASCII text, DVI,
GNU info, HTML, PDF, PostScript as well as the Texinfo source used for
creating all these formats using the GNU Texinfo system
(http://texinfo.org/).
From there, you can obtain versions converted to plain ASCII text, GNU
info, HTML, PDF, as well as the Texinfo source used for creating all these
formats using the GNU Texinfo system (http://texinfo.org/).
You can also obtain the R FAQ from the `doc/FAQ' subdirectory of a CRAN
site (*note What is CRAN?::).
......@@ -228,10 +228,11 @@ and bug reports.
Since mid-1997 there has been a core group (the "R Core Team") who can
modify the R source code archive. The group currently consists of Doug
Bates, John Chambers, Peter Dalgaard, Robert Gentleman, Kurt Hornik,
Stefano Iacus, Ross Ihaka, Friedrich Leisch, Thomas Lumley, Martin
Maechler, Duncan Murdoch, Paul Murrell, Martyn Plummer, Brian Ripley,
Duncan Temple Lang, Luke Tierney, and Simon Urbanek.
Bates, John Chambers, Peter Dalgaard, Seth Falcon, Robert Gentleman, Kurt
Hornik, Stefano Iacus, Ross Ihaka, Friedrich Leisch, Uwe Ligges, Thomas
Lumley, Martin Maechler, Duncan Murdoch, Paul Murrell, Martyn Plummer,
Brian Ripley, Deepayan Sarkar, Duncan Temple Lang, Luke Tierney, and Simon
Urbanek.
R has a home page at `http://www.R-project.org/'. It is free software
(http://www.gnu.org/philosophy/free-sw.html) distributed under a GNU-style
......@@ -2587,6 +2588,57 @@ the model where x doesn't explain any of the variance, is the model where
E[Y]=0 everywhere. (If you don't know a priori that E[Y]=0 when x=0, then
you probably shouldn't be fitting a line through the origin.)
7.42 Why is R apparently not releasing memory?
==============================================
This question is often asked in different flavors along the lines of "I
have removed objects in R and run `gc()' and yet `ps'/`top' still shows the
R process using a lot of memory", often on Linux machines.
This is an artifact of the way the operating system (OS) allocates
memory. In general it is common that the OS is not capable of releasing
all unused memory. In extreme cases it is possible that even if R frees
almost all its memory, the OS can not release any of it due to its design
and thus tools such as `ps' or `top' will report substantial amount of
resident RAM used by the R process even though R has released all that
memory. In general such tools do _not_ report the actual memory usage of
the process but rather what the OS is reserving for that process.
The short answer is that this is a limitation of the memory allocator in
the operating system and there is nothing R can do about it. That space is
simply kept by the OS in the hope that R will ask for it later. The
following paragraph gives more in-depth answer with technical details on
how this happens.
Most systems use two separate ways to allocate memory. For allocation of
large chunks they will use `mmap' to map memory into the process address
space. Such chunks can be released immediately when they are completely
free, because they can reside anywhere in the virtual memory. However,
this is a relatively expensive operation and many OSes have a limit on the
number of such allocated chunks, so this is only used for allocating large
memory regions. For smaller allocations the system can expand the data
segment of the process (historically using the `brk' system call), but this
whole area is always contiguous. The OS can only move the end of this
space, it cannot create any "holes". Since this operation is fairly cheap,
it is used for allocations of small pieces of memory. However, the
side-effect is that even if there is just one byte that is in use at the
end of the data segment, the OS cannot release any memory at all, because
it cannot change the address of that byte. This is actually more common
than it may seem, because allocating a lot of intermediate objects, then
allocating a result object and removing all intermediate objects is a very
common practice. Since the result is allocated at the end it will prevent
the OS from releasing any memory used by the intermediate objects. In
practice, this is not necessarily a problem, because modern operating
systems can page out unused portions of the virtual memory so it does not
necessarily reduce the amount of real memory available for other
applications. Typically, small objects such as strings or pairlists will
be affected by this behavior, whereas large objects such as long vectors
will be allocated using `mmap' and thus not affected. On Linux (and
possibly other Unix-like systems) it is possible to use the `mallinfo'
system call (also see the mallinfo (http://rforge.net/mallinfo) package) to
query the allocator about the layout of the allocations, including the
actually used memory as well as unused memory that cannot be released.
8 R Programming
***************
......
......@@ -12,7 +12,7 @@ all: NEWS.rds html/NEWS.html ../NEWS ../NEWS.pdf \
CHANGES.rds CHANGES html/CHANGES.html
NEWS.rds: NEWS.Rd
@$(ECHO) "saveRDS(tools:::prepare_Rd(tools::parse_Rd(\"$<\"), stages = \"install\"), \"$@\")" | $(R_EXE)
@$(ECHO) "options(warn=1);saveRDS(tools:::prepare_Rd(tools::parse_Rd(\"$<\"), stages = \"install\"), \"$@\")" | $(R_EXE)
CHANGES.rds: ../src/gnuwin32/CHANGES.Rd
@$(ECHO) "options(warn=1);saveRDS(tools:::prepare_Rd(tools::parse_Rd(\"$<\"), stages = \"install\"), \"$@\")" | $(R_EXE)
......
This diff is collapsed.
......@@ -2,19 +2,19 @@ R would not be what it is today without the invaluable help of these
people, who contributed by donating code, bug fixes and documentation:
Valerio Aimale, Thomas Baier, Roger Bivand, Ben Bolker, David Brahm,
Goran Brostrom, Patrick Burns, Vince Carey, Saikat DebRoy,
Brian D'Urso, Lyndon Drake, Dirk Eddelbuettel, Claus Ekstrom,
Sebastian Fischmeister, John Fox, Paul Gilbert, Yu Gong,
Gabor Grothendieck, Frank E Harrell Jr, Torsten Hothorn, Robert King,
Kjetil Kjernsmo, Roger Koenker, Philippe Lambert, Jan de Leeuw,
Uwe Ligges, Jim Lindsey, Patrick Lindsey, Catherine Loader,
Gordon Maclean, John Maindonald, David Meyer, Ei-ji Nakama,
Jens Oehlschaegel, Steve Oncley, Richard O'Keefe, Hubert Palme,
Roger D. Peng, Jose' C. Pinheiro, Tony Plate, Anthony Rossini,
Jonathan Rougier, Petr Savicky, Guenther Sawitzki, Marc Schwartz, Detlef Steuer,
Bill Simpson, Gordon Smyth, Adrian Trapletti, Terry Therneau,
Rolf Turner, Bill Venables, Gregory R. Warnes, Andreas Weingessel,
Morten Welinder, James Wettenhall, Simon Wood, and Achim Zeileis
Goran Brostrom, Patrick Burns, Vince Carey, Saikat DebRoy, Brian
D'Urso, Lyndon Drake, Dirk Eddelbuettel, Claus Ekstrom, Sebastian
Fischmeister, John Fox, Paul Gilbert, Yu Gong, Gabor Grothendieck,
Frank E Harrell Jr, Torsten Hothorn, Robert King, Kjetil Kjernsmo,
Roger Koenker, Philippe Lambert, Jan de Leeuw, Jim Lindsey, Patrick
Lindsey, Catherine Loader, Gordon Maclean, John Maindonald, David
Meyer, Ei-ji Nakama, Jens Oehlschaegel, Steve Oncley, Richard O'Keefe,
Hubert Palme, Roger D. Peng, Jose' C. Pinheiro, Tony Plate, Anthony
Rossini, Jonathan Rougier, Petr Savicky, Guenther Sawitzki, Marc
Schwartz, Detlef Steuer, Bill Simpson, Gordon Smyth, Adrian Trapletti,
Terry Therneau, Rolf Turner, Bill Venables, Gregory R. Warnes, Andreas
Weingessel, Morten Welinder, James Wettenhall, Simon Wood
and Achim Zeileis
The R Foundation may decide to give out <first.lastname>@R-project.org
email addresses to contributors to the R Project (even without making them
......@@ -23,8 +23,8 @@ would help advance the R project.
The R Core Group, Roger Bivand, John Fox and Bill Venables are the
ordinary members of the R Foundation. In addition, Dirk Eddelbuettel,
Torsten Hothorn, Uwe Ligges, David Meyer, Deepayan Sarkar, Simon Wood,
and Achim Zeileis are also e-addressable by
Torsten Hothorn, David Meyer, Deepayan Sarkar, Simon Wood, and Achim
Zeileis are also e-addressable by
<Firstname>.<Lastname>@R-project.org.
Many more, too numerous to mention here, have contributed by sending bug
......
This diff is collapsed.
This diff is collapsed.
......@@ -4,7 +4,7 @@
@settitle R FAQ
@setchapternewpage on
@set FAQ_YEAR 2011
@set FAQ_DATE @value{FAQ_YEAR}-07-05
@set FAQ_DATE @value{FAQ_YEAR}-09-17
@set REL_YEAR 2011
@set REL_MAJOR 2
@set REL_MINOR 13
......@@ -162,12 +162,12 @@ The latest version of this document is always available from
From there, you can obtain versions converted to
@url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.txt,, plain
@acronym{ASCII} text},
@url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.dvi.gz,, DVI},
@c @url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.dvi.gz,, DVI},
@url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.info.gz,, @acronym{GNU}
info}, @url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.html,, @HTML{}},
@url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.pdf,, PDF},
@url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.ps.gz,, PostScript} as
well as the @url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.texi,,
@c @url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.ps.gz,, PostScript}
as well as the @url{http://CRAN.R-project.org/doc/FAQ/R-FAQ.texi,,
Texinfo source} used for creating all these formats using the
@url{http://texinfo.org/, @acronym{GNU} Texinfo system}.
......@@ -277,10 +277,11 @@ by sending code and bug reports.
Since mid-1997 there has been a core group (the ``R Core Team'') who can
modify the R source code archive. The group currently consists of Doug
Bates, John Chambers, Peter Dalgaard, Robert Gentleman, Kurt Hornik,
Stefano Iacus, Ross Ihaka, Friedrich Leisch, Thomas Lumley, Martin
Maechler, Duncan Murdoch, Paul Murrell, Martyn Plummer, Brian Ripley,
Duncan Temple Lang, Luke Tierney, and Simon Urbanek.
Bates, John Chambers, Peter Dalgaard, Seth Falcon, Robert Gentleman,
Kurt Hornik, Stefano Iacus, Ross Ihaka, Friedrich Leisch, Uwe Ligges,
Thomas Lumley, Martin Maechler, Duncan Murdoch, Paul Murrell, Martyn
Plummer, Brian Ripley, Deepayan Sarkar, Duncan Temple Lang, Luke
Tierney, and Simon Urbanek.
R has a home page at @url{http://www.R-project.org/}. It is
@url{http://www.gnu.org/philosophy/free-sw.html, free software}
......@@ -2270,6 +2271,7 @@ dir /opt/R/src/unix
* How do I create a plot with two y-axes?::
* How do I access the source code for a function?::
* Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?::
* Why is R apparently not releasing memory?::
@end menu
@c @node Why does R run out of memory?, Why does sourcing a correct file fail?, R Miscellanea, R Miscellanea
......@@ -3315,7 +3317,7 @@ a complete overview on how to access source code, see Uwe Ligges (2006),
``Help Desk: Accessing the sources'', @emph{R News}, @strong{6/4},
43--45 (@url{http://cran.r-project.org/doc/Rnews/Rnews_2006-4.pdf}).
@node Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?, , How do I access the source code for a function?, R Miscellanea
@node Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?, Why is R apparently not releasing memory?, How do I access the source code for a function?, R Miscellanea
@section Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?
As described in @code{?summary.lm}, when the intercept is zero (e.g.,
......@@ -3355,6 +3357,61 @@ of the variance, is the model where @math{E[Y]=0} everywhere. (If you
don't know a priori that @math{E[Y]=0} when @math{x=0}, then you
probably shouldn't be fitting a line through the origin.)
@node Why is R apparently not releasing memory?, , Why does summary() report strange results for the R^2 estimate when I fit a linear model with no intercept?, R Miscellanea
@section Why is R apparently not releasing memory?
This question is often asked in different flavors along the lines of
``I have removed objects in R and run @code{gc()} and yet
@code{ps}/@code{top} still shows the R process using a lot of
memory'', often on Linux machines.
This is an artifact of the way the operating system (OS) allocates
memory. In general it is common that the OS is not capable of
releasing all unused memory. In extreme cases it is possible that even
if R frees almost all its memory, the OS can not release any of it due
to its design and thus tools such as @code{ps} or @code{top} will
report substantial amount of resident RAM used by the R process even
though R has released all that memory. In general such tools do
@emph{not} report the actual memory usage of the process but rather
what the OS is reserving for that process.
The short answer is that this is a limitation of the memory allocator
in the operating system and there is nothing R can do about it. That
space is simply kept by the OS in the hope that R will ask for it
later. The following paragraph gives more in-depth answer with
technical details on how this happens.
Most systems use two separate ways to allocate memory. For allocation
of large chunks they will use @code{mmap} to map memory into the
process address space. Such chunks can be released immediately when
they are completely free, because they can reside anywhere in the
virtual memory. However, this is a relatively expensive operation and
many OSes have a limit on the number of such allocated chunks, so this
is only used for allocating large memory regions. For smaller
allocations the system can expand the data segment of the process
(historically using the @code{brk} system call), but this whole area
is always contiguous. The OS can only move the end of this space, it
cannot create any ``holes''. Since this operation is fairly cheap, it
is used for allocations of small pieces of memory. However, the
side-effect is that even if there is just one byte that is in use
at the end of the data segment, the OS cannot release any memory
at all, because it cannot change the address of that byte. This is
actually more common than it may seem, because allocating a lot of
intermediate objects, then allocating a result object and removing all
intermediate objects is a very common practice. Since the result is
allocated at the end it will prevent the OS from releasing any memory
used by the intermediate objects. In practice, this is not necessarily
a problem, because modern operating systems can page out unused
portions of the virtual memory so it does not necessarily reduce the
amount of real memory available for other applications. Typically,
small objects such as strings or pairlists will be affected by this
behavior, whereas large objects such as long vectors will be allocated
using @code{mmap} and thus not affected. On Linux (and possibly other
Unix-like systems) it is possible to use the @code{mallinfo} system call
(also see the @url{http://rforge.net/mallinfo, mallinfo} package) to
query the allocator about the layout of the allocations, including the
actually used memory as well as unused memory that cannot be released.
@node R Programming, R Bugs, R Miscellanea, Top
@chapter R Programming
......
......@@ -1071,7 +1071,7 @@ and a 64-bit version.
You need @code{libpng}, @code{jpeg} and @code{libtiff} sources
(available, e.g., from @uref{http://www.libpng.org/},
@uref{http://www.ijg.org} and
@uref{ftp://ftp.remotesensing.org/@/pub/@/libtiff/}). The earliest
@uref{http://download.osgeo.org/@/libtiff/}. The earliest
versions that have been tested are @file{libpng-1.4.5.tar.gz},
@file{jpegsrc.v8b.tar.gz}, @file{tiff-3.9.4.tar.gz} (including betas of
@file{tiff-4.0.0}). It is also possible to use @samp{libjpeg-turbo}
......@@ -2013,7 +2013,9 @@ simplest way to set up such a file is to use function
which fields are needed. Optionally there can also be a
@file{PACKAGES.gz} file, a @command{gzip}-compressed version of
@file{PACKAGES}---as this will be downloaded in preference to
@file{PACKAGES} it should be included for large repositories.
@file{PACKAGES} it should be included for large repositories. (If you
have a mis-configured server that does not report correctly non-existent
files you will need @file{PACKAGES.gz}.)
To add your repository to the list offered by @code{setRepositories()},
see the help file for that function.
......@@ -2156,7 +2158,7 @@ Optionally, a modifier, for example to indicate that Austria is to be
considered pre- or post-Euro. The modifier is also used to indicate the
script (@code{@@latin}, @code{@@cyrillic}, @code{@@iqtelif}) or language
dialect (e.g.@: @code{saaho}, a dialect of Afar, and @code{bokmal} and
@code{nynorsk}, dialects of Norwegian regarded by some OSes are separate
@code{nynorsk}, dialects of Norwegian regarded by some OSes as separate
languages, @code{no} and @code{nn}).
@end itemize
......@@ -2659,6 +2661,19 @@ for @code{glibc} but not of most commercial Unixes. However, you can
make use of @acronym{GNU} @code{libiconv} (possibly as a plug-in
replacement: see @uref{http://www.gnu.org/@/software/@/libiconv/}).
An implementation of @acronym{XDR} is required. This is part of
@acronym{RPC} and historically has been part of @file{libc} on a
Unix-alike: however some builds@footnote{when built by default, but not
for example as built for Fedora 15.} @code{glibc 2.14} hide it. The
intention seems to be that the @acronym{TI-RPC} library be used instead,
in which case @code{libtirpc} (and its development version) needs to be
installed, and its headers need to be on the C include path (and
@command{configure} tries @file{/usr/include/tirpc} if the headers are
not found on the standard include path). The @R{} sources contain a
simple implementation of @acronym{XDR} which in recent versions can be
used on platforms with 32-bit or 64-bit @code{long} (and earlier ones
will fail to compile unless @code{long} is 32-bit).
The OS needs to have enough support@footnote{specifically, the C99
functionality of headers @file{wchar.h} and @file{wctype.h}, types
@code{wctans_t} and @code{mbstate_t} and functions @code{mbrtowc},
......@@ -2766,17 +2781,19 @@ The bitmapped graphics devices @code{jpeg()}, @code{png()} and
@code{tiff()} need the appropriate headers and libraries installed:
@code{jpeg} (version 6b or later, or @code{libjpeg-turbo}) or
@code{libpng} (version 1.2.7 or later, including 1.4.x and 1.5.x) and
@code{zlib} or @code{libtiff} (any recent version of 3.x.y -- 3.8.2 and
3.9.[124] have been tested) respectively.
@code{zlib} or @code{libtiff} (any recent version of 3.x.y -- 3.9.[45]
have been tested) respectively.
If you have them installed (including the appropriate headers and of
suitable versions), @code{zlib}, @code{libbz2} and PCRE will be used if
specified by @option{--with-system-zlib} (version 1.2.3 or later, but
beware that bugs have been found with 1.2.4 and 1.2.5, and these should
not be used on 32-bit Linux systems with LFS),
@option{--with-system-bzlib} or @option{--with-system-pcre}: otherwise
versions in the @R{} sources will be compiled in. As the latter suffice
and are tested with @R{} you should not need to change this.
@option{--with-system-bzlib} or @option{--with-system-pcre} (version
8.10 or later, preferably 8.13 which is what is supplied with @R{}):
otherwise versions in the @R{} sources will be compiled in. As the
latter suffice and are tested with @R{} you should not need to change
this.
@code{liblzma} from @code{xz-utils} version 4.999 or later (preferably
5.0.0 or later) will be used if installed: the version in the @R{}
......
This diff is collapsed.
......@@ -6554,13 +6554,11 @@ disappear.
@table @code
@item
Login, start your windowing system.
@item $ R
Start @R{} as appropriate for your platform.
Start @R{} appropriately for your platform (@pxref{Invoking R}).
The @R{} program begins, with a banner.
(Within @R{}, the prompt on the left hand side will not be shown to
(Within @R{} code, the prompt on the left hand side will not be shown to
avoid confusion.)
@item help.start()
......@@ -6952,18 +6950,9 @@ tilde-expansion: see the help for @code{path.expand}.
@item --min-vsize=@var{N}
@itemx --max-vsize=@var{N}
Specify the minimum or maximum amount of memory used for variable size
objects by setting the ``vector heap'' size to @var{N} bytes. Here,
@var{N} must either be an integer or an integer ending with @samp{G},
@samp{M}, @samp{K}, or @samp{k}, meaning `Giga' (2^30), `Mega' (2^20),
(computer) `Kilo' (2^10), or regular `kilo' (1000).
@item --min-nsize=@var{N}
@itemx --min-nsize=@var{N}
@itemx --max-nsize=@var{N}
Specify the amount of memory used for fixed size objects by setting the
number of ``cons cells'' to @var{N}. See the previous option for
details on @var{N}. A cons cell takes 28 bytes on a 32-bit machine, and
usually 56 bytes on a 64-bit machine.
Almost entirely of historical interest: see @code{?Memory} in @R{}.
@item --max-ppsize=@var{N}
Specify the maximum size of the pointer protection stack as @var{N}
......
This diff is collapsed.
......@@ -178,30 +178,26 @@ static void free_context(contextinfo *c)
}
/*
* Add a new DC into our list of DCs.
* Add a new DC into our list of DCs. This is kind of ugly: num_contexts just keeps growing, unless
* del_all_contexts is called, when it is set to 0. The free ones will be scattered through the list.
*/
PROTECTED
void add_context(object obj, HDC dc, HGDIOBJ old)
{
contextinfo *c;
/* Clear a spot for the new DC if the array is full. */
/* Search for or clear a spot for the new DC if the array is full. */
if (num_contexts == MAX_CONTEXTS) {
c = & context[empty_slot];
free_context(c);
/* Paul 2011-02-11
* Improve search for next empty slot
*/
{
int old_empty = empty_slot;
empty_slot = (empty_slot+1) % MAX_CONTEXTS;
while (context[empty_slot].dc) {
empty_slot = (empty_slot+1) % MAX_CONTEXTS;
}
if (empty_slot == old_empty) {
/* printf("Contexts exhausted; expect instability!"); */
}
}
int i = empty_slot;
while ( context[i].dc ) {
i = (i+1) % MAX_CONTEXTS;
if (i == empty_slot) {
free_context(&context[i]);
break;
}
}
c = & context[i];
empty_slot = (i+1) % MAX_CONTEXTS;
} else {
c = & context[num_contexts];
num_contexts++;
......@@ -271,7 +267,12 @@ void remove_context(object obj)
c->obj = NULL;
c->dc = 0;
c->old_bitmap = 0;
empty_slot = i;
/* If we delete the last one, reduce the count: avoid
a search next time. */
if (i == num_contexts - 1)
num_contexts--;
else
empty_slot = i;
}
}
}
......@@ -292,7 +293,13 @@ void del_context(object obj)
c->obj = NULL;
c->dc = 0;
c->old_bitmap = 0;
empty_slot = i;
/* If we delete the last one, reduce the count: avoid
a search next time. */
if (i == num_contexts - 1)
num_contexts--;
else
empty_slot = i;
}
}
}
......
......@@ -22,7 +22,7 @@ Email domain: cam.ac.uk
University of Cambridge Computing Service,
Cambridge, England.
Copyright (c) 1997-2010 University of Cambridge
Copyright (c) 1997-2011 University of Cambridge
All rights reserved.
......@@ -31,7 +31,7 @@ THE C++ WRAPPER FUNCTIONS
Contributed by: Google Inc.
Copyright (c) 2007-2010, Google Inc.
Copyright (c) 2007-2011, Google Inc.
All rights reserved.
......
NOTE: the current sources are up-to-date with PCRE 8.13 plus r661
from PCRE SVN which fixes collation symbol recognition issue.
This will be in PCRE 8.20 eventually and then this note can go away.
pcre_internal.h includes the relevant definitions that configure would
make.
......
......@@ -5,7 +5,7 @@
/* This is the public header file for the PCRE library, to be #included by
applications that call the PCRE functions.
Copyright (c) 1997-2010 University of Cambridge
Copyright (c) 1997-2011 University of Cambridge
-----------------------------------------------------------------------------
Redistribution and use in source and binary forms, with or without
......@@ -42,9 +42,9 @@ POSSIBILITY OF SUCH DAMAGE.
/* The current PCRE version information. */
#define PCRE_MAJOR 8
#define PCRE_MINOR 12
#define PCRE_MINOR 13
#define PCRE_PRERELEASE
#define PCRE_DATE 2011-01-15
#define PCRE_DATE 2011-09-03
/* When an application links to a PCRE DLL in Windows, the symbols that are
imported have to be identified as such. When building PCRE, the appropriate
......@@ -163,6 +163,32 @@ compile-time only bits for runtime options, or vice versa. */
#define PCRE_ERROR_BADNEWLINE (-23)
#define PCRE_ERROR_BADOFFSET (-24)
#define PCRE_ERROR_SHORTUTF8 (-25)
#define PCRE_ERROR_RECURSELOOP (-26)
/* Specific error codes for UTF-8 validity checks */
#define PCRE_UTF8_ERR0 0
#define PCRE_UTF8_ERR1 1
#define PCRE_UTF8_ERR2 2
#define PCRE_UTF8_ERR3 3
#define PCRE_UTF8_ERR4 4
#define PCRE_UTF8_ERR5 5
#define PCRE_UTF8_ERR6 6
#define PCRE_UTF8_ERR7 7
#define PCRE_UTF8_ERR8 8
#define PCRE_UTF8_ERR9 9
#define PCRE_UTF8_ERR10 10
#define PCRE_UTF8_ERR11 11
#define PCRE_UTF8_ERR12 12
#define PCRE_UTF8_ERR13 13
#define PCRE_UTF8_ERR14 14
#define PCRE_UTF8_ERR15 15
#define PCRE_UTF8_ERR16 16
#define PCRE_UTF8_ERR17 17
#define PCRE_UTF8_ERR18 18
#define PCRE_UTF8_ERR19 19
#define PCRE_UTF8_ERR20 20
#define PCRE_UTF8_ERR21 21
/* Request types for pcre_fullinfo() */
......@@ -254,6 +280,8 @@ typedef struct pcre_callout_block {
/* ------------------- Added for Version 1 -------------------------- */
int pattern_position; /* Offset to next item in the pattern */
int next_item_length; /* Length of next item in the pattern */
/* ------------------- Added for Version 2 -------------------------- */
const unsigned char *mark; /* Pointer to current mark or NULL */
/* ------------------------------------------------------------------ */
} pcre_callout_block;
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
......@@ -153,7 +153,11 @@ enum {
ucp_Old_Turkic,
ucp_Samaritan,
ucp_Tai_Tham,
ucp_Tai_Viet
ucp_Tai_Viet,
/* New for Unicode 6.0.0: */
ucp_Batak,
ucp_Brahmi,
ucp_Mandaic
};
#endif
......
......@@ -20,6 +20,6 @@ time_t is signed, which it is on all sensible platforms.)
To remake it, use a machine with zic in the path (it may be /usr/sbin/zic).
Copy the current version of tzdataXXXXx.tar.gz to this directory and run
make -f Make.zi VERSION=2011h
make -f Make.zi VERSION=2011j
for the appropriate version.
......@@ -15,24 +15,16 @@ XDR_CPPFLAGS = -I$(srcdir)
ALL_CPPFLAGS = $(XDR_CPPFLAGS) $(R_XTRA_CPPFLAGS) $(CPPFLAGS) $(DEFS)
SOURCES = xdr.c xdr_float.c xdr_mem.c xdr_stdio.c
HEADERS = rpc/auth.h rpc/auth_uni.h rpc/bcopy.h rpc/clnt.h rpc/netdb.h \
rpc/rpc.h rpc/rpc_msg.h rpc/svc.h rpc/svc_auth.h rpc/types.h rpc/xdr.h
DEPENDS = $(SOURCES:.c=.d)
OBJECTS = $(SOURCES:.c=.o)
@WANT_R_SHLIB_TRUE@ALL_CFLAGS = $(ALL_CFLAGS_LO) @C_VISIBILITY@
distdir = $(top_builddir)/$(PACKAGE)-$(VERSION)/$(subdir)