[Rd] PR#8210
This failure is reproducible: 1) This requires a machine without "makeinfo". I ran into it on a RedHat 9.0 system, but I doubt the OS matters. 2) unpack the R-2.2.0 source tarball 3) cd R-2.2.0 4) ./configure ; make ; make check ; make install [add configure args as appropriate; works fine] 5) make distclean ; ./configure ; make ; make check ; make install [add configure args as appropriate] The last "make install" fails because "make distclean" removed doc/html/resources.html and makeinfo is needed to rebuild it. Quick fix: extract R-2.2.0/doc/html/resources.html from the tarball and run "make install" again. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R patched for Windows missing
R patched for Windows seems to be missing. If one clicks on R-2.2.0pat-win32.exe at, say, http://stat.ethz.ch/CRAN/bin/windows/base/rpatched.html then an error occurs. I tried it at several mirror sites with the same result. The web page in question says: This directory contains a Windows binary build of R including patches up to 2005-10-24. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pb with dyn.load
Hi,
here are a couple of strange things happening with R.2.2.0 compiled
under Mandrake-10.1
At the begining of the story I have segmentation fault
using package RandomFields in conjuction with some Fortran code of mine
loaded with dyn.load.
One of my fortran programs contains a subroutine named fstat
Trying to trace , I simplified the sequence as much as possible
and I end up with the the simple fortran programs and R code atached
which give the result below.
Any explanation about the strange things below and what
I should do to avoid them would help.
Gilles
#
QUESTION 1:
[EMAIL PROTECTED] guillot]$ R
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.2.0 (2005-10-06 r35749)
ISBN 3-900051-07-0
>system("R CMD SHLIB ~/tmp/test1.f")
g77 -fPIC -g -O2 -c /home/guillot/tmp/test1.f -o /home/guillot/tmp/test1.o
gcc -shared -L/usr/local/lib
-o /home/guillot/tmp/test1.so /home/guillot/tmp/test1.o -lg2c -lm -lgcc_s
> system("R CMD SHLIB ~/tmp/test2.f")
g77 -fPIC -g -O2 -c /home/guillot/tmp/test2.f -o /home/guillot/tmp/test2.o
gcc -shared -L/usr/local/lib
-o /home/guillot/tmp/test2.so /home/guillot/tmp/test2.o -lg2c -lm -lgcc_s
>
> is.loaded("sub")
[1] FALSE
> is.loaded("sub_")
[1] FALSE
>
## OK
> dyn.load("~/tmp/test1.so")
> is.loaded("sub")
[1] FALSE
> is.loaded("sub_")
[1] TRUE
>
## it seems it does not comply with the 'value' section of the help
## of function is.loaded:
## "it needs the
##name you would give to '.C' or '.Fortran' and *not* that remapped
##by 'symbol.C' and 'symbol.For'."
##
## am i missing something ?
> q()
QUESTION 2:
[EMAIL PROTECTED] guillot]$R
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.2.0 (2005-10-06 r35749)
ISBN 3-900051-07-0
>is.loaded("fstat")
[1] FALSE
> is.loaded("fstat_")
[1] FALSE
> dyn.load("~/tmp/test1.so")
> is.loaded("fstat")
[1] FALSE
> is.loaded("fstat_")
[1] TRUE
## why ?
> dyn.load("~/tmp/test2.so")
> .Fortran(name="fstat",
+ as.integer(999),
+ as.integer(100),
+ as.integer(200))
[[1]]
[1] 1073913012
[[2]]
[1] 0
[[3]]
[1] 200
## pb in memory management ?
system("R CMD SHLIB ~/tmp/test1.f")
system("R CMD SHLIB ~/tmp/test2.f")
is.loaded("sub")
is.loaded("sub_")
dyn.load("~/tmp/test1.so")
is.loaded("sub")
is.loaded("sub_")
q()
R
s.loaded("fstat")
is.loaded("fstat_")
dyn.load("~/tmp/test1.so")
is.loaded("fstat")
is.loaded("fstat_")
dyn.load("~/tmp/test2.so")
.Fortran(name="fstat",
as.integer(999),
as.integer(100),
as.integer(200))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pb with dyn.load - fortran code now attached
Hi,
here are a couple of strange things happening with R.2.2.0 compiled
under Mandrake-10.1
At the begining of the story I have segmentation fault
using package RandomFields in conjuction with some Fortran code of mine
loaded with dyn.load.
One of my fortran programs contains a subroutine named fstat
Trying to trace , I simplified the sequence as much as possible
and I end up with the the simple fortran programs and R code atached
which give the result below.
Any explanation about the strange things below and what
I should do to avoid them would help.
Gilles
#
QUESTION 1:
[EMAIL PROTECTED] guillot]$ R
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.2.0 (2005-10-06 r35749)
ISBN 3-900051-07-0
>system("R CMD SHLIB ~/tmp/test1.f")
g77 -fPIC -g -O2 -c /home/guillot/tmp/test1.f -o /home/guillot/tmp/test1.o
gcc -shared -L/usr/local/lib
-o /home/guillot/tmp/test1.so /home/guillot/tmp/test1.o -lg2c -lm -lgcc_s
> system("R CMD SHLIB ~/tmp/test2.f")
g77 -fPIC -g -O2 -c /home/guillot/tmp/test2.f -o /home/guillot/tmp/test2.o
gcc -shared -L/usr/local/lib
-o /home/guillot/tmp/test2.so /home/guillot/tmp/test2.o -lg2c -lm -lgcc_s
>
> is.loaded("sub")
[1] FALSE
> is.loaded("sub_")
[1] FALSE
>
## OK
> dyn.load("~/tmp/test1.so")
> is.loaded("sub")
[1] FALSE
> is.loaded("sub_")
[1] TRUE
>
## it seems it does not comply with the 'value' section of the help
## of function is.loaded:
## "it needs the
##name you would give to '.C' or '.Fortran' and *not* that remapped
##by 'symbol.C' and 'symbol.For'."
##
## am i missing something ?
> q()
QUESTION 2:
[EMAIL PROTECTED] guillot]$R
R : Copyright 2005, The R Foundation for Statistical Computing
Version 2.2.0 (2005-10-06 r35749)
ISBN 3-900051-07-0
>is.loaded("fstat")
[1] FALSE
> is.loaded("fstat_")
[1] FALSE
> dyn.load("~/tmp/test1.so")
> is.loaded("fstat")
[1] FALSE
> is.loaded("fstat_")
[1] TRUE
## why ?
> dyn.load("~/tmp/test2.so")
> .Fortran(name="fstat",
+ as.integer(999),
+ as.integer(100),
+ as.integer(200))
[[1]]
[1] 1073913012
[[2]]
[1] 0
[[3]]
[1] 200
## pb in memory management ?
system("R CMD SHLIB ~/tmp/test1.f")
system("R CMD SHLIB ~/tmp/test2.f")
is.loaded("sub")
is.loaded("sub_")
dyn.load("~/tmp/test1.so")
is.loaded("sub")
is.loaded("sub_")
q()
R
s.loaded("fstat")
is.loaded("fstat_")
dyn.load("~/tmp/test1.so")
is.loaded("fstat")
is.loaded("fstat_")
dyn.load("~/tmp/test2.so")
.Fortran(name="fstat",
as.integer(999),
as.integer(100),
as.integer(200))
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Microsoft help files
I wonder if the software here: http://morte.jedrea.com/~jedwin/projects/chmlib/ or at any of the links on that page might allow elimination of the need for separately downloading the Microsoft Help compiler -- which is just one more task that one must perform to get up and running to build your own R packages on Windows. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Microsoft help files
Gabor Grothendieck wrote: > I wonder if the software here: > > http://morte.jedrea.com/~jedwin/projects/chmlib/ > > or at any of the links on that page might allow elimination of the > need for separately downloading the Microsoft Help compiler -- > which is just one more task that one must perform to get > up and running to build your own R packages on Windows. Actually, why does one need to depend on the Microsoft Help compiler? The windows build of GNU makeinfo can generate MS *.hlp file directly. That's more "native" MS windows than CHM files. Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb with dyn.load - fortran code now attached
On Wed, 26 Oct 2005, Gilles GUILLOT wrote:
> QUESTION 1:
> [EMAIL PROTECTED] guillot]$ R
> R : Copyright 2005, The R Foundation for Statistical Computing
> Version 2.2.0 (2005-10-06 r35749)
> ISBN 3-900051-07-0
>
> >system("R CMD SHLIB ~/tmp/test1.f")
> g77 -fPIC -g -O2 -c /home/guillot/tmp/test1.f -o /home/guillot/tmp/test1.o
> gcc -shared -L/usr/local/lib
> -o /home/guillot/tmp/test1.so /home/guillot/tmp/test1.o -lg2c -lm -lgcc_s
> > system("R CMD SHLIB ~/tmp/test2.f")
> g77 -fPIC -g -O2 -c /home/guillot/tmp/test2.f -o /home/guillot/tmp/test2.o
> gcc -shared -L/usr/local/lib
> -o /home/guillot/tmp/test2.so /home/guillot/tmp/test2.o -lg2c -lm -lgcc_s
> >
> > is.loaded("sub")
> [1] FALSE
> > is.loaded("sub_")
> [1] FALSE
> >
> ## OK
> > dyn.load("~/tmp/test1.so")
> > is.loaded("sub")
> [1] FALSE
> > is.loaded("sub_")
> [1] TRUE
> >
> ## it seems it does not comply with the 'value' section of the help
> ## of function is.loaded:
> ## "it needs the
> ##name you would give to '.C' or '.Fortran' and *not* that remapped
> ##by 'symbol.C' and 'symbol.For'."
> ##
> ## am i missing something ?
> > q()
The is.loaded method needs the argument to look exactly
like the associated output from 'nm' (i.e., symbol name).
$ nm ~/tmp/test1.so | grep sub
Thus, you are manually asking for the following
> is.loaded(symbol.For("sub"))
The call to .Fortran use the (lowercase) name of the subroutine
as it would appear in the Fortran source code.
.Fortran("sub", ...)
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb with dyn.load - fortran code now attached
On Wed, 26 Oct 2005, Paul Roebuck wrote:
> On Wed, 26 Oct 2005, Gilles GUILLOT wrote:
>
>> QUESTION 1:
>> [EMAIL PROTECTED] guillot]$ R
>> R : Copyright 2005, The R Foundation for Statistical Computing
>> Version 2.2.0 (2005-10-06 r35749)
>> ISBN 3-900051-07-0
>>
>> >system("R CMD SHLIB ~/tmp/test1.f")
>> g77 -fPIC -g -O2 -c /home/guillot/tmp/test1.f -o /home/guillot/tmp/test1.o
>> gcc -shared -L/usr/local/lib
>> -o /home/guillot/tmp/test1.so /home/guillot/tmp/test1.o -lg2c -lm -lgcc_s
>>> system("R CMD SHLIB ~/tmp/test2.f")
>> g77 -fPIC -g -O2 -c /home/guillot/tmp/test2.f -o /home/guillot/tmp/test2.o
>> gcc -shared -L/usr/local/lib
>> -o /home/guillot/tmp/test2.so /home/guillot/tmp/test2.o -lg2c -lm -lgcc_s
>>>
>>> is.loaded("sub")
>> [1] FALSE
>>> is.loaded("sub_")
>> [1] FALSE
>>>
>> ## OK
>>> dyn.load("~/tmp/test1.so")
>>> is.loaded("sub")
>> [1] FALSE
>>> is.loaded("sub_")
>> [1] TRUE
>>>
>> ## it seems it does not comply with the 'value' section of the help
>> ## of function is.loaded:
>> ## "it needs the
>> ##name you would give to '.C' or '.Fortran' and *not* that remapped
>> ##by 'symbol.C' and 'symbol.For'."
>> ##
>> ## am i missing something ?
>>> q()
>
> The is.loaded method needs the argument to look exactly
> like the associated output from 'nm' (i.e., symbol name).
>
> $ nm ~/tmp/test1.so | grep sub
>
> Thus, you are manually asking for the following
>
>> is.loaded(symbol.For("sub"))
>
> The call to .Fortran use the (lowercase) name of the subroutine
> as it would appear in the Fortran source code.
>
> .Fortran("sub", ...)
Not at all the whole story. First (unfortunately), the case mapping is
OS-dependent and even compiler-dependent. Second, look at stats.so which
has
00030cf0 T supsmu_
yet
> is.loaded("supsmu_")
[1] FALSE
> is.loaded("supsmu")
[1] TRUE
That is a Fortran entry point, and it complies with the description
quoted.
What is.loaded() needs depends on how the symbol would be found
and so it is not much use.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Microsoft help files
> From: Hin-Tak Leung > > Gabor Grothendieck wrote: > > I wonder if the software here: > > > > http://morte.jedrea.com/~jedwin/projects/chmlib/ > > > > or at any of the links on that page might allow elimination of the > > need for separately downloading the Microsoft Help compiler -- > > which is just one more task that one must perform to get > > up and running to build your own R packages on Windows. > > Actually, why does one need to depend on the Microsoft Help > compiler? The windows build of GNU makeinfo can generate MS > *.hlp file directly. That's more "native" MS windows than CHM > files. > > Hin-Tak Leung Personally my order of preference is CHM > plain text > HLP Isn't it true that even MS is moving away from HLP? Andy __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R patched for Windows missing
Gabor Grothendieck <[EMAIL PROTECTED]> writes: > R patched for Windows seems to be missing. If one clicks on > R-2.2.0pat-win32.exe at, say, > >http://stat.ethz.ch/CRAN/bin/windows/base/rpatched.html > > then an error occurs. I tried it at several mirror sites with the same > result. The web page in question says: > > This directory contains a Windows binary build of R including patches > up to 2005-10-24. Looks like an HTML issue. Almost all links on that page go to files in the server root, and likewise for r-devel. The .exe files themselves seem to be quite happily sitting alongside the release binary at e.g. http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe The source for the link table in r-patched.html is currently looking like this: README.R-2.2.0pat Installation and other instructions. CHANGES New features of this Windows version. NEWS New features of all versions. R-2.2.0pat-win32.exe Setup program (about 25 megabytes). Please download this from a http://cran.r-project.org/mirrors.html";>mirror near you. This corresponds to the file named SetupR.exe or rw.exe in pre-2.2.0 releases. < -- O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Microsoft help files
Liaw, Andy wrote: >> From: Hin-Tak Leung >> >> Gabor Grothendieck wrote: >> >>> I wonder if the software here: >>> >>> http://morte.jedrea.com/~jedwin/projects/chmlib/ >>> >>> or at any of the links on that page might allow elimination of >>> the need for separately downloading the Microsoft Help compiler >>> -- which is just one more task that one must perform to get up >>> and running to build your own R packages on Windows. >> >> Actually, why does one need to depend on the Microsoft Help >> compiler? The windows build of GNU makeinfo can generate MS *.hlp >> file directly. That's more "native" MS windows than CHM files. > > > Personally my order of preference is > > CHM > plain text > HLP > > Isn't it true that even MS is moving away from HLP? WINHLP comes with a built-in search-and-index functionalty, and rather more user-friendly than CHM or plain text. I am talking about indexing and searching sizeable documents with internal organizations and structures. Even pdf is better the plain text. You want the R-reference manual as a text file? I am against additional dependency (particularly at build-time, unless you bundle it), especially on software that has just been written and may not be around/maintained in a few months' time (one can at least say the microsoft CHM compiler will be around!). Since much of R's documentation is already quite texinfo/makeinfo friendly, it is just an extra couple of line in the makefile to generate hlp file, ditto for rtf and ditto for pdf. HT __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R patched for Windows missing
Peter Dalgaard wrote: > Gabor Grothendieck <[EMAIL PROTECTED]> writes: > > >>R patched for Windows seems to be missing. If one clicks on >>R-2.2.0pat-win32.exe at, say, >> >> http://stat.ethz.ch/CRAN/bin/windows/base/rpatched.html >> >>then an error occurs. I tried it at several mirror sites with the same >>result. The web page in question says: >> >>This directory contains a Windows binary build of R including patches >>up to 2005-10-24. > > > Looks like an HTML issue. Almost all links on that page go to files in > the server root, and likewise for r-devel. The .exe files themselves > seem to be quite happily sitting alongside the release binary at e.g. > > http://cran.r-project.org/bin/windows/base/R-2.2.0pat-win32.exe > > > The source for the link table in r-patched.html is currently looking like > this: See the thread on this with subject "Re: [Rd] download problem: Windows binaries - patched/devel versions". We know about it and are working on it. It's caused by the mirroring software being a little too helpful. Duncan Murdoch > > > > > HREF="../../../../../../../../../README.R-2.2.0pat">README.R-2.2.0pat > Installation and other instructions. > > > HREF="../../../../../../../../../CHANGES.R-2.2.0pat">CHANGES > > New features of this Windows version. > > > HREF="../../../../../../../../../NEWS.R-2.2.0pat">NEWS > New features of all versions. > > > > HREF="../../../../../../../../../R-2.2.0pat-win32.exe">R-2.2.0pat-win32.exe > Setup program (about 25 megabytes). Please download this > from a http://cran.r-project.org/mirrors.html";>mirror near > you. > This corresponds to the file named SetupR.exe or > rw.exe in pre-2.2.0 releases. > > > > > > < > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pb with dyn.load - fortran code now attached
On Wed, 26 Oct 2005, Prof Brian Ripley wrote:
> On Wed, 26 Oct 2005, Paul Roebuck wrote:
>
> > On Wed, 26 Oct 2005, Gilles GUILLOT wrote:
> >
> >> QUESTION 1:
> >> [EMAIL PROTECTED] guillot]$ R
> >> R : Copyright 2005, The R Foundation for Statistical Computing
> >> Version 2.2.0 (2005-10-06 r35749)
> >> ISBN 3-900051-07-0
> >>
> >> >system("R CMD SHLIB ~/tmp/test1.f")
> >> g77 -fPIC -g -O2 -c /home/guillot/tmp/test1.f -o
> >> /home/guillot/tmp/test1.o
> >> gcc -shared -L/usr/local/lib
> >> -o /home/guillot/tmp/test1.so /home/guillot/tmp/test1.o -lg2c -lm -lgcc_s
> >>> system("R CMD SHLIB ~/tmp/test2.f")
> >> g77 -fPIC -g -O2 -c /home/guillot/tmp/test2.f -o
> >> /home/guillot/tmp/test2.o
> >> gcc -shared -L/usr/local/lib
> >> -o /home/guillot/tmp/test2.so /home/guillot/tmp/test2.o -lg2c -lm -lgcc_s
> >>>
> >>> is.loaded("sub")
> >> [1] FALSE
> >>> is.loaded("sub_")
> >> [1] FALSE
> >>>
> >> ## OK
> >>> dyn.load("~/tmp/test1.so")
> >>> is.loaded("sub")
> >> [1] FALSE
> >>> is.loaded("sub_")
> >> [1] TRUE
> >>>
> >> ## it seems it does not comply with the 'value' section of the help
> >> ## of function is.loaded:
> >> ## "it needs the
> >> ##name you would give to '.C' or '.Fortran' and *not* that remapped
> >> ##by 'symbol.C' and 'symbol.For'."
> >> ##
> >> ## am i missing something ?
> >>> q()
> >
> > The is.loaded method needs the argument to look exactly
> > like the associated output from 'nm' (i.e., symbol name).
> >
> > $ nm ~/tmp/test1.so | grep sub
> >
> > Thus, you are manually asking for the following
> >
> >> is.loaded(symbol.For("sub"))
> >
> > The call to .Fortran use the (lowercase) name of the subroutine
> > as it would appear in the Fortran source code.
> >
> > .Fortran("sub", ...)
>
> Not at all the whole story. First (unfortunately), the case mapping is
> OS-dependent and even compiler-dependent. Second, look at stats.so which
> has
>
> 00030cf0 T supsmu_
>
> yet
>
> > is.loaded("supsmu_")
> [1] FALSE
> > is.loaded("supsmu")
> [1] TRUE
>
> That is a Fortran entry point, and it complies with the description
> quoted.
>
> What is.loaded() needs depends on how the symbol would be found
> and so it is not much use.
My example using symbol.For was outdated as I haven't
used the function in some time. I would suggest a
modification to the man page for this method though.
Rather than using the vague word 'nowadays'
available for use in '.C' or '.Fortran': nowadays it needs the
it might mention when this change took place.
available for use in '.C' or '.Fortran': as of R-2.x.x, it needs the
I know it occurred after R-1.9.1 but don't know when.
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] unexpected '[<-.data.frame' result
Is this a bug? If not, I am curious to know why '[<-.data.frame' was designed to yield a.frame$y != a.frame$z rather than refusing to carry out the operation at all. > a.frame <- data.frame( x=letters[1:5] ) > a.frame[ 2:5, "y" ] <- letters[2:5] > a.frame[[ "z" ]][ 2:5 ] <- letters[2:5] > a.frame xyz 1 ab 2 bcb 3 cdc 4 ded 5 e e Chuck Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:[EMAIL PROTECTED] UC San Diego http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected '[<-.data.frame' result
"Charles C. Berry" <[EMAIL PROTECTED]> writes:
> Is this a bug?
>
> If not, I am curious to know why '[<-.data.frame' was designed to yield
> a.frame$y != a.frame$z rather than refusing to carry out the operation at
> all.
>
> > a.frame <- data.frame( x=letters[1:5] )
> > a.frame[ 2:5, "y" ] <- letters[2:5]
> > a.frame[[ "z" ]][ 2:5 ] <- letters[2:5]
> > a.frame
>xyz
> 1 ab
> 2 bcb
> 3 cdc
> 4 ded
> 5 e e
It sure looks like a bug, and we're not even prototype-compatible:
turmalin:~/>Splus
S-PLUS : Copyright (c) 1988, 2003 Insightful Corp.
S : Copyright Lucent Technologies, Inc.
Version 6.2.1 for Linux 2.4.18 : 2003
Working data will be in /home/bs/pd/MySwork
> a.frame <- data.frame( x=letters[1:5] )
> a.frame[ 2:5, "y" ] <- letters[2:5]
> a.frame
x y
1 a
2 b b
3 c c
4 d d
5 e e
(S-PLUS doesn't know about character NA, so it's not surprising that
you get an empty cell, but it does fill in the right rows of y).
Why would you expect the operation to be refused?
The problem is not, BTW, restricted to character column indexing:
> a.frame
x y V3
1 a bb
2 b bc
3 c cd
4 d de
5 e e
The problem would seem to be the else clause in
if (jj <= nvars) {
if (length(dim(x[jj])) != 2)
x[[jj]][iseq] <- vjj
else x[[jj]][iseq, ] <- vjj
}
else {
length(vjj) <- nrows
x[[jj]] <- vjj
}
which I think wants to be
else {
x[[jj]] <- vjj[FALSE]
length(x[[jj]]) <- nrows
x[[jj]][iseq] <- vjj
}
--
O__ Peter Dalgaard Øster Farimagsgade 5, Entr.B
c/ /'_ --- Dept. of Biostatistics PO Box 2099, 1014 Cph. K
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Borland C++ and [R] dyn.load() for windows
Hi,
I compiled a C program file on Borland C++ 5.5 compiler to get one dll output
(as instructed in the file readme.package).
The C program file is just the example on page 31 of "writing R extensions":
void convolve(double *a, int *na, double *b, int *nb, double *ab)
{
int i, j, nab = *na + *nb - 1;
for(i = 0; i < nab; i++)
ab[i] = 0.0;
for(i = 0; i < *na; i++)
for(j = 0; j < *nb; j++)
ab[i + j] += a[i] * b[j];
}
I used
"bcc32 -Ic:\Borland\bcc55\include -Lc:\Borland\bcc55\Lib -u- -6 -O2 -WDE
c:\Borland\bcc55\convolve.c"
to get "convolve.dll". It seemed fine.
When I used dyn.load("C:\\Borland\\BCC55\\Bin\\convolve.dll") in R (Version
2.0.1 ), it seemed fine also, no warning or error messages. However, when I
used is.loaded("convolve") to check if it was loaded, it showed "False".
I am working on winXP.
What could be the possible reason for that?
thanks
huanyu
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Borland C++ and [R] dyn.load() for windows
On Wed, 26 Oct 2005, huanyu zhou wrote:
> Hi,
> I compiled a C program file on Borland C++ 5.5 compiler to get one dll output
> (as instructed in the file readme.package).
> The C program file is just the example on page 31 of "writing R extensions":
>
> void convolve(double *a, int *na, double *b, int *nb, double *ab)
> {
> int i, j, nab = *na + *nb - 1;
> for(i = 0; i < nab; i++)
> ab[i] = 0.0;
> for(i = 0; i < *na; i++)
> for(j = 0; j < *nb; j++)
> ab[i + j] += a[i] * b[j];
> }
> I used
> "bcc32 -Ic:\Borland\bcc55\include -Lc:\Borland\bcc55\Lib -u- -6 -O2 -WDE
> c:\Borland\bcc55\convolve.c"
> to get "convolve.dll". It seemed fine.
>
> When I used dyn.load("C:\\Borland\\BCC55\\Bin\\convolve.dll") in R (Version
> 2.0.1 ), it seemed fine also, no warning or error messages. However, when I
> used is.loaded("convolve") to check if it was loaded, it showed "False".
>
> I am working on winXP.
>
> What could be the possible reason for that?
The usual reason is that no symbols are exported from the DLL: please use
pedump -e to check. I don't see any evidence that you asked for any to be
and the example in README.packages uses __declspec(dllexport) in the
original source. You are advised to look up the reference given there for
further details.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] strptime problem for 2004-10-03 02:00:00
Great. Thanks for confirmation. Cheers, Mike. Message: 16 Date: Tue, 25 Oct 2005 21:33:54 +0100 (BST) From: Prof Brian Ripley <[EMAIL PROTECTED]> Subject: Re: [Rd] strptime problem for 2004-10-03 02:00:00 To: Michael Sumner <[EMAIL PROTECTED]> Cc: r-devel@stat.math.ethz.ch Message-ID: <[EMAIL PROTECTED]> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed It's a bug, a rather rare one. 2004-10-03 02:00:00 does not exist in your time zone, and in trying to find out if the time is on DST or not it has failed to find out. It needs to be told that GMT is never on DST so not to bother. On Linux, running R with TZ="GMT" set should fix this. Windows is harder to control since it does not distinguish the UK timezone from GMT. There is a bugfix now in R-devel. It may migrate to R-patched in due course. On Tue, 25 Oct 2005, Michael Sumner wrote: >> Hello, I at first thought this was a system or locale issue, but since >> it occurs on >> both Windows and Linux and only for 2004 (AFAIK) I report it. >> >> I have a problem with as.POSIXct for the hour between >> "2004-10-03 02:00:00 GMT" and "2004-10-03 02:59:59 GMT". >> >> In short, the 2 AM (GMT) hour in 2004 (but not in other years) is >> interpreted as 1 AM by strptime: >> (I use ISOdatetime as a convenience). >> >> ## Windows XP >> >> ISOdatetime(2004, 10, 3, 2, 0, 0, tz = "GMT") >> ##[1] "2004-10-03 01:00:00 GMT" >> ISOdatetime(2004, 10, 3, 1, 0, 0, tz = "GMT") >> ##[1] "2004-10-03 01:00:00 GMT" >> >> ISOdatetime(2005, 10, 3, 2, 0, 0, tz = "GMT") >> ##[1] "2005-10-03 02:00:00 GMT" >> ISOdatetime(2005, 10, 3, 1, 0, 0, tz = "GMT") >> ## [1] "2005-10-03 01:00:00 GMT" >> > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] unexpected '[<-.data.frame' result
On Wed, 26 Oct 2005, Peter Dalgaard wrote: > "Charles C. Berry" <[EMAIL PROTECTED]> writes: > >> Is this a bug? >> >> If not, I am curious to know why '[<-.data.frame' was designed to yield >> a.frame$y != a.frame$z rather than refusing to carry out the operation at >> all. >> >>> a.frame <- data.frame( x=letters[1:5] ) >>> a.frame[ 2:5, "y" ] <- letters[2:5] >>> a.frame[[ "z" ]][ 2:5 ] <- letters[2:5] >>> a.frame >>xyz >> 1 ab >> 2 bcb >> 3 cdc >> 4 ded >> 5 e e > > It sure looks like a bug, and we're not even prototype-compatible: > [stuff deleted] > > Why would you expect the operation to be refused? > I was having trouble deciding if the use of "whole" in the Extract.data.frame help page was a warning against creating columns with only some entries present: "The replacement methods can be used to add whole column(s)..." [rest deleted] Charles C. Berry(858) 534-2098 Dept of Family/Preventive Medicine E mailto:[EMAIL PROTECTED] UC San Diego http://biostat.ucsd.edu/~cberry/ La Jolla, San Diego 92093-0717 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
