Re: [Rd] latin1,utf-8...encoding and data
This is indeed unfortunate, but expecting Chinese speakers (20% of the
world's population) to write in Latin-1 was also unfortunate.
What I had (and still have) some hope of doing is being able to mark
character strings as UTF-8, probably via a flag bit on the CHARSXP. Then
output routines could be made to convert (if possible) to the current
locale. But that was before I found out how hard it was to get non-ASCII
characters displayed correctly. Also, any solution to this almost
certainly means abandoning Windows 95/98/ME as they don't have support for
Unicode (and although we could add such support at C level, they would not
have the Unicode fonts needed). (It might be OK to do that now, but it
was not a couple of years ago.)
Don't underestimate the font problem. Last week I gave a seminar about
statistical computing in my own dept, and I thought I would show R
operating in Chinese (we have quite a number of Chinese speakers, indeed
more than from Latin-1 languages). It did not work correctly in my
pre-seminar tests, because there were no CJK fonts installed on the
lecture-room computer. There was no warning nor error, just
unintelligible output.
If you are only concerned with Latin-1 and UTF-8, there is something you
can do. Rather than have a .rda file, store your datasets as .R files,
with another .R file as a driver. So you would need something like
ex1.R:
source("ex1_dat.R", encoding="latin1")
ex_dat.R:
dump of the object, converted to latin1.
If you don't specify lazydata, this will ensure the object gets converted
to the current locale when the data() statement is executed. If you do
specify lazydata, the conversion will happen when the package is
installed, which is fine if you (and any other users) always use the same
locale (or at least always use a locale with the same encoding, e.g.
always use a UTF-8 locale). However, this is really only of use in
locales that will have font coverage of Latin-1, and R installations
without iconv will not do any necessary conversion (which is why I
suggest dumping in latin1 and not in UTF-8).
On Thu, 19 Oct 2006, Martin Maechler wrote:
"Stéphane" == Stéphane Dray <[EMAIL PROTECTED]>
on Thu, 19 Oct 2006 09:46:49 +0200 writes:
Stéphane> Thanks a lot for this clear answer. So there is no way to preserve
our
Stéphane> french cultural exception (accented characters),
I agree that there are many French cultural exceptions ;-)
--- and as a Swiss, I highly estimate several of them ---
however "accented" characters (with the appropriate meaning of "accented")
are not at all a French exception, rather almost a continental
European one {as long as we are staying in the "latin" alphabet
context}. If I think of what I know of Europe, the only
country/language *not* using some version of "accented"
characters are the British and (I think) the Dutch/Flamish.
Everyone else (? probably I forgot some, and don't know about others
like gaelic,...) has some kind of accents...
I agree with Stéphane that this is unfortunate for quite a few
of us, and it came as a big surprise to me when I first heard
about this from Brian. .. aah, life was easy when we western
chauvinists could behave as if the whole relevant part of the
world was happy with iso-latin1...
Martin
Stéphane> if we want to be international... I have thought
Stéphane> that the inclusion of a parameter encoding in data
Stéphane> function (e.g. data(mydata,encoding="latin1"))
Stéphane> like in the function 'file' could be an way to
Stéphane> solve the problem. Apparently, the problem is much
Stéphane> more complicated...
Stéphane> Sincerely.
Stéphane> Prof Brian Ripley wrote:
>> Only ASCII letters are portable: those accented characters do not even
>> exist in many of the encodings used for R, e.g. Russian and Japanese
>> on Windows machines.
>>
>> There is no way to associate an encoding with a character string in
>> R. We considered it, but it would have had severe back-compatibility
>> problems and little advantage (you cannot display non-ASCII character
>> strings portably: even if you have a Unicode encoding you still need
>> to select a suitable font).
>>
>> 'B. Ripley' (sic)
>>
>>
>> On Wed, 18 Oct 2006, Stéphane Dray wrote:
>>
>>> Hello,
>>> I have some questions concerning encoding and package distribution. We
>>> develop the ade4 package. For some data sets included in the package,
>>> there are accentued character (e.g. é,è...). The data sets have been
>>> saved using latin1 encoding, but some of us use utf-8 and can not see
>>> some data sets which contains accented chracters.
>>> e.g:
>>>
>>> librarry(ade4)
>>> data(rankrock)
>>> rankrock
>>>
>>> in this case, characters are in rownames. Other data sets have such
>>> characters in data (e.g. levels of factors..). A solution is to use
>>> iconv... this is quite easy for us
[Rd] Watch out for the latest Cygwin upgrade
I just updated my copy of Cygwin to the latest version, and now Windows builds are failing on that machine. The only parts of the R toolset I changed were the Cygwin dlls. I haven't tracked down exactly what the problem is, and probably won't be able to do so for a few days. So if you're a Windows user thinking about a Cygwin upgrade, be prepared for problems... Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] sourcing dput output
Is this not supposed to work?
> dput(BOD, file = "/BOD.R")
> source("/BOD.R")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row names must be 'character' or 'integer', not 'double'
> dput(iris, file = "/iris.R")
> source("/iris.R")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row names must be 'character' or 'integer', not 'double'
> R.version.string # XP
[1] "R version 2.4.0 Patched (2006-10-07 r39598)"
I also tried control = "all" as an argument to dput as well as a number
of other control values but did not find one that worked.
dump("BOD.R", file = "/BOD.R"); source("/BOD.R")
and similarly for iris do work. Also under 2.3.1pat dput output of these
two data frame could be sourced:
> dput("BOD", file = "/BOD.R")
> source("/BOD.R")
> dput("iris", file = "/iris.R")
> source("/iris.R")
> R.version.string
[1] "Version 2.3.1 Patched (2006-06-04 r38279)"
What is supposed to be the difference between dput and dump anyways
and should dput output be source-able like it used to be?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sourcing dput output
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Is this not supposed to work?
>
> > dput(BOD, file = "/BOD.R")
> > source("/BOD.R")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> row names must be 'character' or 'integer', not 'double'
>
> > dput(iris, file = "/iris.R")
> > source("/iris.R")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> row names must be 'character' or 'integer', not 'double'
>
> > R.version.string # XP
> [1] "R version 2.4.0 Patched (2006-10-07 r39598)"
>
> I also tried control = "all" as an argument to dput as well as a number
> of other control values but did not find one that worked.
Eh?
> dput(iris, file = "/tmp/iris.R")
> source("/tmp/iris.R")
Error in attributes(.Data) <- c(attributes(.Data), attrib) :
row names must be 'character' or 'integer', not 'double'
> dput(iris, file = "/tmp/iris.R",control="all")
> source("/tmp/iris.R")
> dput(BOD, file = "/tmp/BOD.R",control="all")
> source("/tmp/BOD.R")
>
Happy as a clam...
> R.version.string
[1] "R version 2.4.0 Patched (2006-10-20 r39680)"
(SUSE 9.3, local compile)
--
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] sourcing dput output
Thanks.
However, that still leaves these questions:
1. I assume the changes to the internal representation of rownames is
behind this but should not dput continue to work exactly the same as
it used to work??? I would think that the internal representation aspect
would be just that -- internal and not affect various commands.
2. what is the difference between dput and dump supposed to be
anyways?
On 25 Oct 2006 17:13:23 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> "Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
>
> > Is this not supposed to work?
> >
> > > dput(BOD, file = "/BOD.R")
> > > source("/BOD.R")
> > Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> > row names must be 'character' or 'integer', not 'double'
> >
> > > dput(iris, file = "/iris.R")
> > > source("/iris.R")
> > Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> > row names must be 'character' or 'integer', not 'double'
> >
> > > R.version.string # XP
> > [1] "R version 2.4.0 Patched (2006-10-07 r39598)"
> >
> > I also tried control = "all" as an argument to dput as well as a number
> > of other control values but did not find one that worked.
>
>
> Eh?
>
> > dput(iris, file = "/tmp/iris.R")
> > source("/tmp/iris.R")
> Error in attributes(.Data) <- c(attributes(.Data), attrib) :
>row names must be 'character' or 'integer', not 'double'
> > dput(iris, file = "/tmp/iris.R",control="all")
> > source("/tmp/iris.R")
> > dput(BOD, file = "/tmp/BOD.R",control="all")
> > source("/tmp/BOD.R")
> >
>
> Happy as a clam...
>
> > R.version.string
> [1] "R version 2.4.0 Patched (2006-10-20 r39680)"
>
> (SUSE 9.3, local compile)
> --
> 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] as.missing
Peter Dalgaard wrote:
>"Charles C. Berry" <[EMAIL PROTECTED]> writes:
>
>
>
>>On Tue, 24 Oct 2006, Duncan Murdoch wrote:
>>
>>
>
>
>
>>>with no defaults. However, this little demo illustrates the point, I think:
>>>
>>>
>>>
g <- function(gnodef, gdef=1) {
>>>+if (missing(gnodef)) cat('gnodef is missing\n')
>>>+if (missing(gdef)) cat('gdef is missing\n')
>>>+cat('gdef is ',gdef,'\n')
>>>+ }
>>>
>>>
f <- function(fnodef, fdef) {
>>>+g(fnodef, fdef)
>>>+ }
>>>
>>>
g()
>>>gnodef is missing
>>>gdef is missing
>>>gdef is 1
>>>
>>>
f()
>>>gnodef is missing
>>>gdef is missing
>>>Error in cat("gdef is ", gdef, "\n") : argument "fdef" is missing, with
>>>no default
>>>
>>>
>>>What would be nice to be able to do is to have a simple way for f() to
>>>act just like g() does.
>>>
>>>
>>Is this what you want?
>>
>>
>>
>>> f <- function(fnodef, fdef=NULL) {
>>>
>>>
>>+ g()}
>>
>>
>>>f()
>>>
>>>
>>gnodef is missing
>>gdef is missing
>>gdef is 1
>>
>>
>
>I think not. More like
>
> f <- function(fnodef, fdef) {
>if(missing(fdef)) g(fnodef) else g(fnodef, fdef)
> }
>
>(the generalization of which is obviously a pain...)
>
>
>
Yes, both a pain and the resulting code can be unnecessarily difficult
to read, compared with something like
f <- function(fnodef, gArgs=as.missing()) {g(fnodef, gArgs) }
which would generalize cleanly.
La version française suit le texte anglais.
This email may contain privileged and/or confidential inform...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cross-compilation
Hi everyone, I am trying to cross-compile a package I wrote using the Yan and Rossini tutorial "Building Microsoft Windows versions of R and R packages using Intel Linux". I have got reasonably far with this but when doing the linking using the line: i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR I get lots of these type of messages: /my/path/to/mylibrary.cpp:43: undefined reference to `_GLOBAL_OFFSET_TABLE_' and other similar linker errors for virtually every object and command in the program. After some googling I have found that there may be problems with the libgcc.a library and its default -fPIC argument during compilation. Has anyone got this tutorial to work and if so how did they overcome this? I am attempting to do this on Fedora Core 4 on a 32-bit machine, having completed all the previous sections of the tutorial for building a cross-platform version of R. Many thanks Tom -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] as.missing
You can do it like this:
> as.missing <- force
> g <- function(x = as.missing()) missing(x)
> g(3)
[1] FALSE
> g()
[1] TRUE
On 10/24/06, Paul Gilbert <[EMAIL PROTECTED]> wrote:
> (I'm not sure if this is a request for a feature, or another instance
> where a feature has eluded me for many years.)
>
> Often I have a function which calls other functions, and may often use
> the default arguments to those functions, but needs the capability to
> pass along non-default choices. I usually do this with some variation on
>
> foo <- function(x, foo2Args=NULL or a list(foo2defaults),
>foo3Args=NULL or a list(foo3defaults))
>
> and then have logic to check for NULL, or use the list in combination
> with do.call. It is also possible to do this with ..., but it always
> seems a bit dangerous passing all the unnamed arguments along to all the
> functions being called, especially when I always seem to be calling
> functions that have similar arguments (maxit, eps, start, frequency, etc).
>
> It is a situation I have learned to live with, but one of my
> co-maintainers just pointed out to me that there should be a good way to
> do this in R. Perhaps there is something else I have missed all these
> years? Is there a way to do this cleanly? It would be nice to have
> something like
>
> foo <- function(x, foo2Args=as.missing(), foo3Args=as.missing())
>
> then the call to foo2 and foo3 could specify foo2Args and foo3Args, but
> these would get treated as if they were missing, unless they are given
> other values.
>
> Paul Gilbert
>
>
> La version française suit le texte anglais.
>
>
>
> This email may contain privileged and/or confidential inform...{{dropped}}
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] library loading errors (PR#9317)
Full_Name: Larry Layne Version: 2.4.0 OS: MS Windows 2000 Submission from: (NULL) (129.24.91.249) All of the following libraries loaded just fine in version 2.3.1: > utils:::menuInstallLocal() package 'tripack' successfully unpacked and MD5 sums checked updating HTML package descriptions > library(tripack) Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library 'C:/PROGRA~1/R/R-24~1.0/library/tripack/libs/tripack.dll': LoadLibrary failure: The specified procedure could not be found. Error in library(tripack) : .First.lib failed for 'tripack' > library(maptools) Loading required package: foreign Error in dyn.load(x, as.logical(local), as.logical(now)) : unable to load shared library 'C:/PROGRA~1/R/R-24~1.0/library/foreign/libs/foreign.dll': LoadLibrary failure: The specified procedure could not be found. Error: package 'foreign' could not be loaded > library(maps) > library(geoR) Loading required package: sp Error in loadNamespace(package, c(which.lib.loc, lib.loc), keep.source = keep.source) : in 'sp' methods for export not found: bbox, coordinates, coordinates<-, coordnames, coordnames<-, gridded, polygons, polygons<-, dimensions, [, transform, overlay, plot, recenter, spplot, spsample, summary Error: package 'sp' could not be loaded > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Cross-compilation
Dear Tom,
It has worked for me out-of-the box in at least two times, one a while ago
with R-2.2-something and recently with R-2.4.0. In both cases, I was running
Debian (with a mix of testing and unstable) on x86. I never had to do
anything, just run the script and at least in one case I did crosscompile a
package with C++.
R.
On Wednesday 25 October 2006 18:03, Tom McCallum wrote:
> Hi everyone,
>
> I am trying to cross-compile a package I wrote using the Yan and Rossini
> tutorial "Building Microsoft Windows versions of R and R packages using
> Intel Linux". I have got reasonably far with this but when doing the
> linking using the line:
>
> i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o
> mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR
>
> I get lots of these type of messages:
> /my/path/to/mylibrary.cpp:43: undefined reference to
> `_GLOBAL_OFFSET_TABLE_'
>
> and other similar linker errors for virtually every object and command in
> the program. After some googling I have found that there may be problems
> with the libgcc.a library and its default -fPIC argument during
> compilation.
>
> Has anyone got this tutorial to work and if so how did they overcome this?
>
> I am attempting to do this on Fedora Core 4 on a 32-bit machine, having
> completed all the previous sections of the tutorial for building a
> cross-platform version of R.
>
> Many thanks
>
> Tom
--
Ramón Díaz-Uriarte
Bioinformatics
Centro Nacional de Investigaciones Oncológicas (CNIO)
(Spanish National Cancer Center)
Melchor Fernández Almagro, 3
28029 Madrid (Spain)
Fax: +-34-91-224-6972
Phone: +-34-91-224-6900
http://ligarto.org/rdiaz
PGP KeyID: 0xE89B3462
(http://ligarto.org/rdiaz/0xE89B3462.asc)
**NOTA DE CONFIDENCIALIDAD** Este correo electrónico, y en s...{{dropped}}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] sourcing dput output
"Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> Thanks.
>
> However, that still leaves these questions:
>
> 1. I assume the changes to the internal representation of rownames is
> behind this but should not dput continue to work exactly the same as
> it used to work??? I would think that the internal representation aspect
> would be just that -- internal and not affect various commands.
dput (and deparse) does reveal internal structure, and is sometimes
used for that purpose. It does have some cases where the
representation is not completely accurate, which is a bit unfortunate,
but awkward to avoid, e.g.
> deparse(1:5)
[1] "c(1, 2, 3, 4, 5)"
but if you parse and evaluate that, you get mode "double", not
"integer". Therefore
> deparse(1:5,control="all")
[1] "as.integer(c(1, 2, 3, 4, 5))"
which evaluates correctly, but may clutter up displays in some
contexts (which escape me just now, but changing the default and
running make check should be illuminating).
[It is probably a generic design error in the S language(s) that there
isn't a parseable representation of every possible object, but that is
a bit late to fix.]
> 2. what is the difference between dput and dump supposed to be
> anyways?
They are mostly the same, dump is primarily for storage, dput might
also be for display. Notice that dump works for multiple objects since
it also stores variable names.
> On 25 Oct 2006 17:13:23 +0200, Peter Dalgaard <[EMAIL PROTECTED]> wrote:
> > "Gabor Grothendieck" <[EMAIL PROTECTED]> writes:
> >
> > > Is this not supposed to work?
> > >
> > > > dput(BOD, file = "/BOD.R")
> > > > source("/BOD.R")
> > > Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> > > row names must be 'character' or 'integer', not 'double'
> > >
> > > > dput(iris, file = "/iris.R")
> > > > source("/iris.R")
> > > Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> > > row names must be 'character' or 'integer', not 'double'
> > >
> > > > R.version.string # XP
> > > [1] "R version 2.4.0 Patched (2006-10-07 r39598)"
> > >
> > > I also tried control = "all" as an argument to dput as well as a number
> > > of other control values but did not find one that worked.
> >
> >
> > Eh?
> >
> > > dput(iris, file = "/tmp/iris.R")
> > > source("/tmp/iris.R")
> > Error in attributes(.Data) <- c(attributes(.Data), attrib) :
> >row names must be 'character' or 'integer', not 'double'
> > > dput(iris, file = "/tmp/iris.R",control="all")
> > > source("/tmp/iris.R")
> > > dput(BOD, file = "/tmp/BOD.R",control="all")
> > > source("/tmp/BOD.R")
> > >
> >
> > Happy as a clam...
> >
> > > R.version.string
> > [1] "R version 2.4.0 Patched (2006-10-20 r39680)"
> >
> > (SUSE 9.3, local compile)
> > --
> > 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
> >
>
--
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] Cross-compilation
Thanks for your reply, as an example it appears to have difficulty linking to even ostream library of the standard C++, as shown below: /home/tmccallum/ritzel/RItzel/src/Classifier.cpp:209: undefined reference to `_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc' Classifier.o: In function `operator<<': /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:218: undefined reference to `_ZNSolsEd' /usr/lib/gcc/i386-redhat-linux/4.0.2/../../../../include/c++/4.0.2/ostream:196: undefined reference to `_ZNSolsEl' I am currently working R-2.4.0 as downloaded today. I know the g++ has gone through some alterations and wondered if you knew the version of g++ you cross-compiled your package with for comparison - mine is g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). Many thanks Tom On Wed, 25 Oct 2006 18:10:40 +0100, Ramon Diaz-Uriarte <[EMAIL PROTECTED]> wrote: > Dear Tom, > > It has worked for me out-of-the box in at least two times, one a while > ago > with R-2.2-something and recently with R-2.4.0. In both cases, I was > running > Debian (with a mix of testing and unstable) on x86. I never had to do > anything, just run the script and at least in one case I did > crosscompile a > package with C++. > > > R. > > On Wednesday 25 October 2006 18:03, Tom McCallum wrote: >> Hi everyone, >> >> I am trying to cross-compile a package I wrote using the Yan and Rossini >> tutorial "Building Microsoft Windows versions of R and R packages using >> Intel Linux". I have got reasonably far with this but when doing the >> linking using the line: >> >> i586-mingw32-g++ -shared -s -o mylibrary.dll mylibrary.def mylibrary.o >> mylibrary_res.o -L/my/path/RCrossBuild/WinR/R-2.4.0/bin -lR >> >> I get lots of these type of messages: >> /my/path/to/mylibrary.cpp:43: undefined reference to >> `_GLOBAL_OFFSET_TABLE_' >> >> and other similar linker errors for virtually every object and command >> in >> the program. After some googling I have found that there may be >> problems >> with the libgcc.a library and its default -fPIC argument during >> compilation. >> >> Has anyone got this tutorial to work and if so how did they overcome >> this? >> >> I am attempting to do this on Fedora Core 4 on a 32-bit machine, having >> completed all the previous sections of the tutorial for building a >> cross-platform version of R. >> >> Many thanks >> >> Tom > -- --- Tom McCallum WWW: http://www.tom-mccallum.com Tel: 0131-4783393 Mobile: 07866-470257 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library loading errors (PR#9317)
On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote: > Full_Name: Larry Layne > Version: 2.4.0 > OS: MS Windows 2000 > Submission from: (NULL) (129.24.91.249) > > > All of the following libraries loaded just fine in version 2.3.1: Not a bug. For sp in particular, please simply re-install the contributed package, and possibly others, because (as noted in NEWS) there are incompatibilities in the way classes are built in binary packages between R 2.3.1 and R 2.4.0: update.packages(checkBuilt=TRUE) It is possible that you also have an old version of the recommended package foreign in your library path - look at what: .libPaths() says and see if an old foreign isn't lurking ahead of the 2.4.0 one built with the binary you installed. Output of .sessionInfo() and .libPaths() may lead you to the root of the problem. > > > utils:::menuInstallLocal() > package 'tripack' successfully unpacked and MD5 sums checked > updating HTML package descriptions > > library(tripack) > Error in dyn.load(x, as.logical(local), as.logical(now)) : > unable to load shared library > 'C:/PROGRA~1/R/R-24~1.0/library/tripack/libs/tripack.dll': > LoadLibrary failure: The specified procedure could not be found. > > Error in library(tripack) : .First.lib failed for 'tripack' > > library(maptools) > Loading required package: foreign > Error in dyn.load(x, as.logical(local), as.logical(now)) : > unable to load shared library > 'C:/PROGRA~1/R/R-24~1.0/library/foreign/libs/foreign.dll': > LoadLibrary failure: The specified procedure could not be found. > > Error: package 'foreign' could not be loaded > > library(maps) > > library(geoR) > Loading required package: sp > Error in loadNamespace(package, c(which.lib.loc, lib.loc), keep.source = > keep.source) : > in 'sp' methods for export not found: bbox, coordinates, > coordinates<-, > coordnames, coordnames<-, gridded, polygons, polygons<-, dimensions, [, > transform, overlay, plot, recenter, spplot, spsample, summary > Error: package 'sp' could not be loaded > > > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: [EMAIL PROTECTED] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] library loading errors (PR#9317)
Some of the packages needed to be newer, as you indicated. Thanks. --On Wednesday, October 25, 2006 7:49 PM +0200 Roger Bivand <[EMAIL PROTECTED]> wrote: > On Wed, 25 Oct 2006 [EMAIL PROTECTED] wrote: > >> Full_Name: Larry Layne >> Version: 2.4.0 >> OS: MS Windows 2000 >> Submission from: (NULL) (129.24.91.249) >> >> >> All of the following libraries loaded just fine in version 2.3.1: > > Not a bug. For sp in particular, please simply re-install the contributed > package, and possibly others, because (as noted in NEWS) there are > incompatibilities in the way classes are built in binary packages between > R 2.3.1 and R 2.4.0: > > update.packages(checkBuilt=TRUE) > > It is possible that you also have an old version of the recommended > package foreign in your library path - look at what: > > .libPaths() > > says and see if an old foreign isn't lurking ahead of the 2.4.0 one built > with the binary you installed. Output of .sessionInfo() and .libPaths() > may lead you to the root of the problem. > >> >> > utils:::menuInstallLocal() >> package 'tripack' successfully unpacked and MD5 sums checked >> updating HTML package descriptions >> > library(tripack) >> Error in dyn.load(x, as.logical(local), as.logical(now)) : >> unable to load shared library >> 'C:/PROGRA~1/R/R-24~1.0/library/tripack/libs/tripack.dll': >> LoadLibrary failure: The specified procedure could not be found. >> >> Error in library(tripack) : .First.lib failed for 'tripack' >> > library(maptools) >> Loading required package: foreign >> Error in dyn.load(x, as.logical(local), as.logical(now)) : >> unable to load shared library >> 'C:/PROGRA~1/R/R-24~1.0/library/foreign/libs/foreign.dll': >> LoadLibrary failure: The specified procedure could not be found. >> >> Error: package 'foreign' could not be loaded >> > library(maps) >> > library(geoR) >> Loading required package: sp >> Error in loadNamespace(package, c(which.lib.loc, lib.loc), keep.source = >> keep.source) : >> in 'sp' methods for export not found: bbox, coordinates, >> coordinates<-, coordnames, coordnames<-, gridded, polygons, >> polygons<-, dimensions, [, transform, overlay, plot, recenter, spplot, >> spsample, summary >> Error: package 'sp' could not be loaded >> > >> >> __ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > -- > Roger Bivand > Economic Geography Section, Department of Economics, Norwegian School of > Economics and Business Administration, Helleveien 30, N-5045 Bergen, > Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 > e-mail: [EMAIL PROTECTED] > > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NA handling in as.character applied to a list
Hi all, In some circumstances, as.character applied to a list converts real NA's into the string "NA". Propagation of NAs is something R does very well and unless there are good reasons for losing the NA, it would improve the consistency w.r.t. NA handling for as.character to behave differently. Here's an example: ## Create a list with character, logical, and integer NA elements v <- list(a=as.character(NA), b=NA, c=as.integer(NA)) sapply(v, is.na) abc TRUE TRUE TRUE sapply(as.character(v), is.na) NANA TRUE FALSE FALSE Thoughts? + seth -- Seth Falcon | Computational Biology | Fred Hutchinson Cancer Research Center http://bioconductor.org __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Cox model - (TStart,Tstop] algorith
Hi ALL, To fit proportional hazard Cox Model with counting process style of input data R and S-plus implement "(TStart,Tstop] algorithm" (agfit3.c) which uses "smart subsets" of sorted events time. Are there any accessible publications where the idea of this algorithm was represented ? Thank you, Gregory Kotler __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] NA handling in as.character applied to a list
Seth Falcon <[EMAIL PROTECTED]> writes:
> Hi all,
>
> In some circumstances, as.character applied to a list converts real
> NA's into the string "NA". Propagation of NAs is something R does
> very well and unless there are good reasons for losing the NA, it
> would improve the consistency w.r.t. NA handling for as.character to
> behave differently.
>
> Here's an example:
>
> ## Create a list with character, logical, and integer NA elements
> v <- list(a=as.character(NA), b=NA, c=as.integer(NA))
> sapply(v, is.na)
>
>abc
> TRUE TRUE TRUE
>
> sapply(as.character(v), is.na)
>
> NANA
> TRUE FALSE FALSE
>
> Thoughts?
Hmm...
> as.character(v)
[1] NA "NA" "NA"
This does look like a leftover from times when there was no character
NA in the language. It is the kind of thing you need to be very
careful about fixing though. (I have a couple of scars from
as.character on formulas when introducing backtick quoting.)
BTW, another little bit of nastiness popped up when playing around
with this:
> dput(v,control="all")
structure(list(a = NA, b = NA, c = as.integer(NA)), .Names = c("a",
"b", "c"))
> sapply(v,mode)
a b c
"character" "logical" "numeric"
--
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] how to determine if a function's result is invisible
Suppose we have a function such as the following F <- function(f, x) f(x)+1 which runs function f and then transforms it. I would like the corresponding function which works the same except that unlike F returns an invisible result if and only if f does. Is there some way of determining whether f returns an invisible result or not? Thus we want this: f <- function(x) x g <- function(x) invisible(x) > F(f, 1) 2 > > F(g, 1) > __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> Suppose we have a function such as the following
>
> F <- function(f, x) f(x)+1
>
> which runs function f and then transforms it. I would like the
> corresponding function which works the same except that
> unlike F returns an invisible result if and only if f does.
>
> Is there some way of determining whether f returns
> an invisible result or not?
>
> Thus we want this:
>
> f <- function(x) x
> g <- function(x) invisible(x)
>
> > F(f, 1)
> 2
> >
>
> > F(g, 1)
> >
Gabor,
There may be a better way of doing this and/or this will spark some
thoughts.
Let's create two simple functions:
f.inv <- function(x) {invisible(x)}
f <- function(x) {x}
So we now have:
> f.inv(1)
> f(1)
[1] 1
> any(grep("invisible", (deparse(f
[1] FALSE
> any(grep("invisible", (deparse(f.inv
[1] TRUE
This is not extensively tested of course, but another function that
comes to mind that does return a result 'invisibly' is:
> any(grep("invisible", (deparse(barplot.default
[1] TRUE
So there seems to be some foundation for working, as long as the target
function can be deparsed, which may limit things with respect to
C/FORTRAN based functions.
HTH,
Marc Schwartz
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NA handling in as.character applied to a list
Also, Splus 7 has a different behaviour from R: > sapply(v, is.na) a b c F T T > sapply(as.character(v), is.na) [1] F F F > as.character(v) [1] "\"NA\"" "NA" "NA" In R, it remains logical: if it isn't in character mode, then as.character always turns NA's into "NA"'s. If that behaviour is not desired, and you want to keep character NA's as true NA's, then you can test from the original object. I agree that is dangerous to change the behaviour of simple things like this, and don't recommend any change in behaviour. However, this isn't documented, so here is my suggested patch for ?as.character . (Edit this as necessary). +mt __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] NA handling in as.character applied to a list
Okay ... I'll try to attach that patch once more ... (does this list
only accept certain exertions for attachments? I used '.patch', but it
must have been filtered off, so I'll try '.patch.txt' now ...)
+mt
Index: R/src/library/base/man/character.Rd
===
--- R/src/library/base/man/character.Rd (revision 39730)
+++ R/src/library/base/man/character.Rd (working copy)
@@ -34,6 +34,9 @@
back to numeric may change the number. If you want to convert numbers
to character with the maximum possible precision, use
\code{\link{format}}.
+
+ \code{as.character} replaces \code{NA} values from non-character modes
+ with the \code{character} \code{"NA"}, which is not \code{NA}.
}
\value{
\code{character} creates a character vector of the specified length.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding function which works the same except that
> > unlike F returns an invisible result if and only if f does.
> >
> > Is there some way of determining whether f returns
> > an invisible result or not?
> >
> > Thus we want this:
> >
> > f <- function(x) x
> > g <- function(x) invisible(x)
> >
> > > F(f, 1)
> > 2
> > >
> >
> > > F(g, 1)
> > >
>
> Gabor,
>
> There may be a better way of doing this and/or this will spark some
> thoughts.
>
> Let's create two simple functions:
>
> f.inv <- function(x) {invisible(x)}
>
> f <- function(x) {x}
>
> So we now have:
>
> > f.inv(1)
> > f(1)
> [1] 1
>
>
> > any(grep("invisible", (deparse(f
> [1] FALSE
>
> > any(grep("invisible", (deparse(f.inv
> [1] TRUE
That's not going to work, since invisibility can also be a side effect
of assignment, e.g.
g <- function(x) { x <- x }
-Deepayan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Error: invalid multibyte string
I'm observing the following on different platforms:
> parse(text='"\\x7F"')
expression("\177")
> parse(text='"\\x80"')
Error: invalid multibyte string
...
> parse(text='"\\xFF"')
Error: invalid multibyte string
However,
cat("\x7F\n\x80\n...\xFF\n")
works. Using R --vanilla.
SYSTEMS GIVING THE ERROR:
> sessionInfo()
R version 2.4.0 (2006-10-03)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_AU.UTF-8;LC_NUMERIC=C;LC_TIME=en_AU.UTF-8;LC_COLLATE=en_AU.UTF-8;LC_MONETARY=en_AU.UTF-8;LC_MESSAGES=en_AU.UTF-8;LC_PAPER=en_AU.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_AU.UTF-8;LC_IDENTIFICATION=C
R version 2.4.0 Patched (2006-10-03 r39576)
i686-pc-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
SYSTEMS OK:
R version 2.4.0 Under development (unstable) (2006-07-23 r38687)
x86_64-unknown-linux-gnu
locale:
LC_CTYPE=en_US.UTF-8;LC_NUMERIC=C;LC_TIME=en_US.UTF-8;LC_COLLATE=en_US.UTF-8;LC_MONETARY=en_US.UTF-8;LC_MESSAGES=en_US.UTF-8;LC_PAPER=en_US.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=en_US.UTF-8;LC_IDENTIFICATION=C
R version 2.4.0 (2006-10-03)
i386-pc-mingw32
locale:
LC_COLLATE=English_United States.1252;LC_CTYPE=English_United
States.1252;LC_MONETARY=English_United
States.1252;LC_NUMERIC=C;LC_TIME=English_United States.1252
R version 2.4.0 Patched (2006-10-10 r39600)
i386-pc-mingw32
locale:
LC_COLLATE=English_Australia.1252;LC_CTYPE=English_Australia.1252;LC_MONETARY=En
glish_Australia.1252;LC_NUMERIC=C;LC_TIME=English_Australia.1252
Version 2.3.0 (2006-04-24)
x86_64-unknown-linux-gnu
locale:
All of the above have the following packages attached:
[1] "methods" "stats" "graphics" "grDevices" "utils" "datasets"
[7] "base"
We identified this problem because R CMD check complained:
> * checking package dependencies ... WARNING
> Error in deparse(e[[2]]) : invalid multibyte string
> Execution halted
because we use "\xFF" (or "\377") in the source code to be used as a
terminator in a vector buffer; "\0" can't be used for other reasons.
Is the above a bug in R or one in my head?
/H
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/2006 8:14 PM, Gabor Grothendieck wrote: > Suppose we have a function such as the following > > F <- function(f, x) f(x)+1 > > which runs function f and then transforms it. I would like the > corresponding function which works the same except that > unlike F returns an invisible result if and only if f does. > > Is there some way of determining whether f returns > an invisible result or not? > > Thus we want this: > > f <- function(x) x > g <- function(x) invisible(x) > >> F(f, 1) > 2 > >> F(g, 1) I don't think there's a way to do that. Internally there's a global flag called R_Visible; if it is set to zero, the value won't print. But it gets reset to 1 very easily (e.g. by adding 1 to the result of an invisible function), and it's not available in the API for you to write C code to look at it. I think you'll just have to do require the user of your F to tell you that they want the result to be invisible. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote: > On 10/25/2006 8:14 PM, Gabor Grothendieck wrote: > > Suppose we have a function such as the following > > > > F <- function(f, x) f(x)+1 > > > > which runs function f and then transforms it. I would like the > > corresponding function which works the same except that > > unlike F returns an invisible result if and only if f does. > > > > Is there some way of determining whether f returns > > an invisible result or not? > > > > Thus we want this: > > > > f <- function(x) x > > g <- function(x) invisible(x) > > > >> F(f, 1) > > 2 > > > >> F(g, 1) > > I don't think there's a way to do that. Internally there's a global > flag called R_Visible; if it is set to zero, the value won't print. But > it gets reset to 1 very easily (e.g. by adding 1 to the result of an > invisible function), and it's not available in the API for you to write > C code to look at it. > > I think you'll just have to do require the user of your F to tell you > that they want the result to be invisible. > > Duncan Murdoch > Perhaps R_Visible be made available at the R level in the future. It would be helpful in situations where you are transforming a function but want to keep aspects of it such as whether the return result is invisible. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > Suppose we have a function such as the following
> >
> > F <- function(f, x) f(x)+1
> >
> > which runs function f and then transforms it. I would like the
> > corresponding function which works the same except that
> > unlike F returns an invisible result if and only if f does.
> >
> > Is there some way of determining whether f returns
> > an invisible result or not?
> >
> > Thus we want this:
> >
> > f <- function(x) x
> > g <- function(x) invisible(x)
> >
> > > F(f, 1)
> > 2
> > >
> >
> > > F(g, 1)
> > >
>
> Gabor,
>
> There may be a better way of doing this and/or this will spark some
> thoughts.
>
> Let's create two simple functions:
>
> f.inv <- function(x) {invisible(x)}
>
> f <- function(x) {x}
>
> So we now have:
>
> > f.inv(1)
> > f(1)
> [1] 1
>
>
> > any(grep("invisible", (deparse(f
> [1] FALSE
>
> > any(grep("invisible", (deparse(f.inv
> [1] TRUE
>
>
> This is not extensively tested of course, but another function that
> comes to mind that does return a result 'invisibly' is:
>
> > any(grep("invisible", (deparse(barplot.default
> [1] TRUE
>
> So there seems to be some foundation for working, as long as the target
> function can be deparsed, which may limit things with respect to
> C/FORTRAN based functions.
>
> HTH,
>
> Marc Schwartz
>
>
>
Clever idea. As others have mentioned there are some limitations
plus generics would not work since the code is in the methods
but its an interesting suggestion that would work part of the time.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > Suppose we have a function such as the following
> > >
> > > F <- function(f, x) f(x)+1
> > >
> > > which runs function f and then transforms it. I would like the
> > > corresponding function which works the same except that
> > > unlike F returns an invisible result if and only if f does.
> > >
> > > Is there some way of determining whether f returns
> > > an invisible result or not?
> > >
> > > Thus we want this:
> > >
> > > f <- function(x) x
> > > g <- function(x) invisible(x)
> > >
> > > > F(f, 1)
> > > 2
> > > >
> > >
> > > > F(g, 1)
> > > >
> >
> > Gabor,
> >
> > There may be a better way of doing this and/or this will spark some
> > thoughts.
> >
> > Let's create two simple functions:
> >
> > f.inv <- function(x) {invisible(x)}
> >
> > f <- function(x) {x}
> >
> > So we now have:
> >
> > > f.inv(1)
> > > f(1)
> > [1] 1
> >
> >
> > > any(grep("invisible", (deparse(f
> > [1] FALSE
> >
> > > any(grep("invisible", (deparse(f.inv
> > [1] TRUE
>
> That's not going to work, since invisibility can also be a side effect
> of assignment, e.g.
>
> g <- function(x) { x <- x }
Good point. Can we tweak it a bit to try to cover additional
situations, such as this? For example:
is.invisible <- function(x)
{
dep.x <- deparse(x)
ifelse(any(grep("invisible", dep.x)) |
any(grep("<-", dep.x[length(dep.x) - 1])),
TRUE, FALSE)
}
f.inv <- function(x) {invisible(x)}
f <- function(x) {x}
g <- function(x) { x <- x }
> is.invisible(f.inv)
[1] TRUE
> is.invisible(f)
[1] FALSE
> is.invisible(g)
[1] TRUE
In this case to (possibly) cover the assignment situation, I am looking
for an assignment operator ("<-") in the last code line of the function
body. Note that if there are blank lines in the function body after the
assignment line and before the closing brace, the assignment line is
still the final line of code found in the deparse().
Given Duncan's comment, it sounds like this might not be doable for 100%
of the situations, but we may be able to cover the 80% of the common
ones.
Gabor, to your follow up comment about generics, perhaps the code can be
yet further extended to check the class of the relevant argument(s) to
the function(s) in question to similarly search/deparse the methods that
would presumably be dispatched. It would certainly become more
convoluted however.
Thoughts?
Marc
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-10-25 at 19:16 -0700, Deepayan Sarkar wrote:
> > On 10/25/06, Marc Schwartz <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2006-10-25 at 20:14 -0400, Gabor Grothendieck wrote:
> > > > Suppose we have a function such as the following
> > > >
> > > > F <- function(f, x) f(x)+1
> > > >
> > > > which runs function f and then transforms it. I would like the
> > > > corresponding function which works the same except that
> > > > unlike F returns an invisible result if and only if f does.
> > > >
> > > > Is there some way of determining whether f returns
> > > > an invisible result or not?
> > > >
> > > > Thus we want this:
> > > >
> > > > f <- function(x) x
> > > > g <- function(x) invisible(x)
> > > >
> > > > > F(f, 1)
> > > > 2
> > > > >
> > > >
> > > > > F(g, 1)
> > > > >
> > >
> > > Gabor,
> > >
> > > There may be a better way of doing this and/or this will spark some
> > > thoughts.
> > >
> > > Let's create two simple functions:
> > >
> > > f.inv <- function(x) {invisible(x)}
> > >
> > > f <- function(x) {x}
> > >
> > > So we now have:
> > >
> > > > f.inv(1)
> > > > f(1)
> > > [1] 1
> > >
> > >
> > > > any(grep("invisible", (deparse(f
> > > [1] FALSE
> > >
> > > > any(grep("invisible", (deparse(f.inv
> > > [1] TRUE
> >
> > That's not going to work, since invisibility can also be a side effect
> > of assignment, e.g.
> >
> > g <- function(x) { x <- x }
>
> Good point. Can we tweak it a bit to try to cover additional
> situations, such as this? For example:
>
>
> is.invisible <- function(x)
> {
> dep.x <- deparse(x)
>
> ifelse(any(grep("invisible", dep.x)) |
> any(grep("<-", dep.x[length(dep.x) - 1])),
> TRUE, FALSE)
> }
>
>
> f.inv <- function(x) {invisible(x)}
> f <- function(x) {x}
> g <- function(x) { x <- x }
>
>
> > is.invisible(f.inv)
> [1] TRUE
>
> > is.invisible(f)
> [1] FALSE
>
> > is.invisible(g)
> [1] TRUE
>
>
> In this case to (possibly) cover the assignment situation, I am looking
> for an assignment operator ("<-") in the last code line of the function
> body. Note that if there are blank lines in the function body after the
> assignment line and before the closing brace, the assignment line is
> still the final line of code found in the deparse().
>
> Given Duncan's comment, it sounds like this might not be doable for 100%
> of the situations, but we may be able to cover the 80% of the common
> ones.
>
> Gabor, to your follow up comment about generics, perhaps the code can be
> yet further extended to check the class of the relevant argument(s) to
> the function(s) in question to similarly search/deparse the methods that
> would presumably be dispatched. It would certainly become more
> convoluted however.
In the case of S3 one could search for a UseMethod and, if found, just
search all available methods for invisible without trying to figure out
which one(s) get dispatched on the theory that its likely
that they will all return or all not return invisibly since methods are
supposed to maintain a certain sense of semantic consistency.
In the case of internal R functions there may not be that many that
return invisibly so one could just make a list of them and check against
that list. Is there some way to grep these out?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] how to determine if a function's result is invisible
On 10/25/2006 11:02 PM, Gabor Grothendieck wrote:
> On 10/25/06, Duncan Murdoch <[EMAIL PROTECTED]> wrote:
>> On 10/25/2006 8:14 PM, Gabor Grothendieck wrote:
>>> Suppose we have a function such as the following
>>>
>>> F <- function(f, x) f(x)+1
>>>
>>> which runs function f and then transforms it. I would like the
>>> corresponding function which works the same except that
>>> unlike F returns an invisible result if and only if f does.
>>>
>>> Is there some way of determining whether f returns
>>> an invisible result or not?
>>>
>>> Thus we want this:
>>>
>>> f <- function(x) x
>>> g <- function(x) invisible(x)
>>>
F(f, 1)
>>> 2
>>>
F(g, 1)
>> I don't think there's a way to do that. Internally there's a global
>> flag called R_Visible; if it is set to zero, the value won't print. But
>> it gets reset to 1 very easily (e.g. by adding 1 to the result of an
>> invisible function), and it's not available in the API for you to write
>> C code to look at it.
>>
>> I think you'll just have to do require the user of your F to tell you
>> that they want the result to be invisible.
>>
>> Duncan Murdoch
>>
>
> Perhaps R_Visible be made available at the R level in the future.
> It would be helpful in situations where you are transforming a
> function but want to keep aspects of it such as whether the
> return result is invisible.
Actually, there is a way, but it's undocumented (i.e., use at your own
risk). It's the eval.with.vis function. This is an internal function
that is used within source() and capture.output(); you'll have to guess
from the usage there what the args are. But here's an F that does
something close to what you want:
> fix(F)
> f <- function() 1
> g <- function() invisible(1)
>
> F <- function (expr)
+ {
+ expr <- substitute(expr)
+ pf <- parent.frame()
+ tmp <- .Internal(eval.with.vis(expr, pf,
+ baseenv()))
+ tmp
+ }
> F(f())
$value
[1] 1
$visible
[1] TRUE
> F(g())
$value
[1] 1
$visible
[1] FALSE
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Watch out for the latest Cygwin upgrade
Duncan Murdoch <[EMAIL PROTECTED]> wrote: > I just updated my copy of Cygwin to the latest version, and now Windows > builds are failing on that machine. The only parts of the R toolset I > changed were the Cygwin dlls. I haven't tracked down exactly what the > problem is, and probably won't be able to do so for a few days. > So if you're a Windows user thinking about a Cygwin upgrade, be prepared > for problems... The change that bit me is that the latest cygwin bash is unhappy with cr/lf line endings in scripts. Which breaks some of the "R CMD ..." scripts in non-obvious ways. The error messages are hard to interpret because they have embedded "\r" characters, causing some of the text of the messages to be overwritten. There is a sort-of workaround in the latest release (the "igncr" shell option) but that seems to still be in flux so I decided to revert to the previous release for now. There seems to be a somewhat cavalier attitude among Cygwin developers about backwards compatibility. They've said that their primary focus is on making cygwin as linux-like as possible, and they're willing to sacrifice interoperability to do so. -- Dave __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
