[Rd] Package that does not work until I re write the exactly the same code
Hi the list,
I am writing a package in S4 and I do not manage to understand a bug.
The "R CMD check" and the "R CMD build" both work. Here is links to the
package (not on CRAN yet for the raison that I explain bellow):
http://christophe.genolini.free.fr/aTelecharger/kml_0.5.zip
http://christophe.genolini.free.fr/aTelecharger/kml_0.5.tar.gz
Then I install the package and I try an example:
--- 8< --
library(kml)
dn <- as.cld(gald())
kml(dn)
# XXX ~ Fast KmL ~
# Erreur dans as.vector(x, mode) : argument 'mode' incorrect
--- 8< --
So I make some verifications:
--- 8<
class(dn)
# [1] "ClusterizLongData"
# attr(,"package")
# [1] "kml"
getMethod("kml","ClusterizLongData")
# Method Definition:
#
# function (Object, nbClusters = 2:6, nbRedrawing = 20, saveFreq = 100,
# maxIt = 200, trajMinSize = 2, print.cal = FALSE, print.traj = FALSE,
#imputationMethod = "copyMean", distance, power = 2, centerMethod =
meanNA,
#startingCond = "allMethods", distanceStartingCond = "euclidean",
# ...)
#{
# nbIdFull <- nrow(Object["traj"])
# .. [[[The full code is available below]]]
# }
#
#
#Signatures:
# Object
# target "ClusterizLongData"
# defined "ClusterizLongData"
--- 8<
Everything seems fine. The code is correct.
So I copy-and-paste the code that I get with
getMethods("kml","ClusterizLongData") and I affect it to a function
"func". Then I define again the method "kml".
Then I run again the example that does not work before and it works...
Any explanations?
Christophe Genolini
--- 8< --
###
### Affecting to func the code that getMethod("kml","ClusterizLongData")
delivers
###
func <- function (Object, nbClusters = 2:6, nbRedrawing = 20, saveFreq =
100,
maxIt = 200, trajMinSize = 2, print.cal = FALSE, print.traj = FALSE,
imputationMethod = "copyMean", distance, power = 2, centerMethod =
meanNA,
startingCond = "allMethods", distanceStartingCond = "euclidean",
...)
{
nbIdFull <- nrow(Object["traj"])
convergenceTime <- 0
noNA <- selectSupTrajMinSize(Object, trajMinSize)
trajNoNA <- Object["traj"][noNA, ]
nbTime <- length(Object["time"])
nbId <- nrow(trajNoNA)
saveCld <- 0
scr <- plotAll(Object, print.cal = print.cal, print.traj = print.traj,
print.sub = FALSE, col = "black", type.mean = "n")
if (length(startingCond) == 1) {
if (startingCond == "allMethods") {
startingCond <- c("maxDist", "randomAll", rep("randomK",
nbRedrawing))[1:nbRedrawing]
}
else {
startingCond <- rep(startingCond, nbRedrawing)
}
}
else {
}
if (missing(distance)) {
distance <- "euclidean"
}
if (is.character(distance)) {
distInt <- pmatch(distance, METHODS)
}
else {
distInt <- NA
}
if (print.traj) {
cat(" ~ Slow KmL ~\n")
fast <- FALSE
screenPlot <- scr[2]
if (!is.na(distInt)) {
distanceSlow <- function(x, y) {
dist(rbind(x, y), method = distance)
}
}
else {
distanceSlow <- distance
}
}
else {
screenPlot <- NA
if (is.na(distInt)) {
cat(" ~ Slow KmL ~\n")
fast <- FALSE
distanceSlow <- distance
}
else {
cat(" ~ Fast KmL ~\n")
fast <- TRUE
}
}
nameObject <- deparse(substitute(Object))
for (iRedraw in 1:nbRedrawing) {
for (iNbClusters in nbClusters) {
saveCld <- saveCld + 1
clustersInit <- partitionInitialise(nbClusters = iNbClusters,
method = startingCond[iRedraw], lengthPart = nbId,
matrixDist = as.matrix(dist(trajNoNA, method =
distanceStartingCond)))
clust <- rep(NA, nbIdFull)
if (fast) {
resultKml <- .C("kml1", as.double(t(trajNoNA)),
iNbInd = as.integer(nbId), iNbTime = as.integer(nbTime),
iNbCluster = as.integer(iNbClusters), maxIt =
as.integer(maxIt),
distance = as.integer(distInt), power =
as.numeric(power),
vClusterAffectation1 =
as.integer(clustersInit["clusters"]),
convergenceTime = as.integer(convergenceTime),
NAOK = TRUE, PACKAGE = "kml")[c(8, 9)]
clust[noNA] <- resultKml[[1]]
}
else {
resultKml <- trajKmlSlow(traj = trajNoNA,
clusterAffectation = clustersInit,
nbId = nbId, nbTime = nbTime, maxIt = maxIt,
screenPlot = scr[2], distance = distanceSlow,
centerMethod = centerMethod, ...)
clust[noNA] <- resultKml[[1]]["clusters"]
}
yPartition <- ordered(partition(nbClusters = iNbClusters,
clusters = clust))
Object["clusters"] <- clusterization(yLongData = as(Object,
"LongData"), xPartition = yPartition
[Rd] Finding the environment of a promise
Hi all,
Is it possible to determine the environment in which a promise will be
evaluated? e.g.
f <- function(code) { force(code) }
f({
a <- 1
b <- 2
})
Is there any way to tell from within f that a and b will be created in
the global environment?
Thanks,
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding the environment of a promise
If I understand your question, you can get the environment with sys.frame:
f <- function(code){
print(sys.frame())
force(code)
}
f({
a <- 1
b <- 2
})
On Wed, Sep 9, 2009 at 10:30 AM, Hadley Wickham wrote:
> Hi all,
>
> Is it possible to determine the environment in which a promise will be
> evaluated? e.g.
>
> f <- function(code) { force(code) }
> f({
> a <- 1
> b <- 2
> })
>
> Is there any way to tell from within f that a and b will be created in
> the global environment?
>
> Thanks,
>
> Hadley
>
> --
> http://had.co.nz/
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
--
Henrique Dallazuanna
Curitiba-Paraná-Brasil
25° 25' 40" S 49° 16' 22" O
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Debugging R core
Hi everyone. I'm working on R sources themselves (look into past messages if interested), and need to debug/benchmark R itself. To check R functionality, I'm running the test-suite with 'make check-devel', but it seems to overwrite the "reference output" at each invocation. I want to compare the output just for the first (initially untampered) build. How can I do that? The tests for 'base' seem to contain some obvious variable output like: 15338c15338 < [1] "/tmp/RtmpPyoUwB/ab4a764be5""/tmp/RtmpPyoUwB/a b c2876711c" --- > [1] "/tmp/RtmpvIWV48/ab73b00ff2""/tmp/RtmpvIWV48/a b c72f0579e" 14639c14639 < ..$ : --- > ..$ : is this expected? (can we fix it?). Is there any larger self-contained code I can use for benchmarking purposes? Thanks __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding the environment of a promise
On 9/9/2009 9:30 AM, Hadley Wickham wrote:
Hi all,
Is it possible to determine the environment in which a promise will be
evaluated? e.g.
f <- function(code) { force(code) }
f({
a <- 1
b <- 2
})
Is there any way to tell from within f that a and b will be created in
the global environment?
I don't think so in R code, but C code to do it would be possible. It
needs to be in C code to avoid forcing the promise.
I think we'd be reluctant to make an R function available to do this,
because it requires non-standard evaluation, and it's not something a
normal function should care about. (The promise belongs to the caller,
not to the function: why would the function need to play with it? It
should be happy with the value, or maybe a text representation of the
promise, for labelling purposes.)
Duncan Murdoch
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Monkey patching +.POSIXt
Hi all,
This summer I've been working with a grad student to bring more of the
date time classes from JODA (http://joda-time.sourceforge.net/) into
R. To make these work seamlessly with existing date time objects, we
need to patch +.POSIXt. (The ruby community uses the term
monkey-patching for this sort of ill-advised, by sometimes necessary,
internal hackery, hence the title.) The problem is I can't figure out
how to override +.POSIXt so that it gets called from +. Simply
including a new +.POSIXt function in the package doesn't work because
(I presume) + finds and uses base::+.POSIXt. The next thing I tried
was
assignInNamespace("+.POSIXt", lubridate::`+.POSIXt`, "base")
but that doesn't seem to work either, despite the documentation: "They
do attempt to alter a copy registered as an S3 method if one is
found." (perhaps there is a missing not there?)
In desperation, I also tried the following internal, undocumented
function, but it didn't help either:
registerS3method("+", "POSIXt", lubridate::`+.POSIXt`)
Any ideas?
Thanks,
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding the environment of a promise
> I don't think so in R code, but C code to do it would be possible. It needs
> to be in C code to avoid forcing the promise.
Thanks Duncan - I thought that might be the case.
> I think we'd be reluctant to make an R function available to do this,
> because it requires non-standard evaluation, and it's not something a normal
> function should care about.
True, but there are plenty of abnormal functions in R that demonstrate
the usefulness (and danger!) of non-standard evaluation.
> (The promise belongs to the caller, not to the
> function: why would the function need to play with it? It should be happy
> with the value, or maybe a text representation of the promise, for labelling
> purposes.)
Is there any way to get a text representation apart from with
deparse(substitute(x))? I think I remember asking you about this some
time ago, but it is still the case that blocks/promises don't store
srcref information? This come up recently while trying to make a
function that would both run a block or code and save it to a separate
file (a sort of poor man's sweave when you just want to include a
small portion of your code in a report). With blocks, the best I
could come up with was:
named_block <- function(name, code) {
text <- deparse(substitute(code), width = 100)
# evaluate code
force(code)
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
out <- text[!grepl("\\{|\\}", text)]
out <- gsub("^", "", out)
writeLines(out, filename)
}
b <- 1
named_block("test", {
# This is a comment
a <- 1
})
print(a)
The problem of course is that this loses comments.
You can do better with functions, but it requires more typing and
messing around with environments to ensure everything is scoped
correctly:
named_block <- function(name, f) {
text <- attr(f, "source")
code <- text[!grepl("^function \\(\\)\\{$|\\}", text)]
code <- gsub("^ ", "", code)
# evaluate code
eval(parse(text = code), env = parent.frame())
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
writeLines(code, filename)
}
b <- 1
named_block("test", function (){
# This is a comment
a <- 2
})
# Make sure objects created in correct environment
print(a)
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding the environment of a promise
On Sep 9, 2009, at 9:40 , Henrique Dallazuanna wrote:
If I understand your question, you can get the environment with
sys.frame:
f <- function(code){
print(sys.frame())
^-- this will always return R_GlobalEnv (see ?sys.frame - which = 0 by
default) regardless of the function and promise.
Also the question was about the environment of the promise, not the
function. Technically a promise can be evaluated anywhere since it
ignores the evaluation environment and will use its creation
environment which is what Hadley was trying to get at (and as Duncan
was saying it's not something that is or should be available at R
level as it's an internal implementation detail).
Cheers,
Simon
force(code)
}
f({
a <- 1
b <- 2
})
On Wed, Sep 9, 2009 at 10:30 AM, Hadley Wickham
wrote:
Hi all,
Is it possible to determine the environment in which a promise will
be
evaluated? e.g.
f <- function(code) { force(code) }
f({
a <- 1
b <- 2
})
Is there any way to tell from within f that a and b will be created
in
the global environment?
Thanks,
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Henrique Dallazuanna
Curitiba-Paraná-Brasil
25° 25' 40" S 49° 16' 22" O
[[alternative HTML version deleted]]
__
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
Re: [Rd] Finding the environment of a promise
You are right,
in the first time that I read the post, I understand incorrectly the
question.
On Wed, Sep 9, 2009 at 12:09 PM, Simon Urbanek
wrote:
>
> On Sep 9, 2009, at 9:40 , Henrique Dallazuanna wrote:
>
> If I understand your question, you can get the environment with sys.frame:
>>
>> f <- function(code){
>> print(sys.frame())
>>
>
> ^-- this will always return R_GlobalEnv (see ?sys.frame - which = 0 by
> default) regardless of the function and promise.
>
> Also the question was about the environment of the promise, not the
> function. Technically a promise can be evaluated anywhere since it ignores
> the evaluation environment and will use its creation environment which is
> what Hadley was trying to get at (and as Duncan was saying it's not
> something that is or should be available at R level as it's an internal
> implementation detail).
>
> Cheers,
> Simon
>
>
>force(code)
>> }
>>
>> f({
>> a <- 1
>> b <- 2
>> })
>>
>> On Wed, Sep 9, 2009 at 10:30 AM, Hadley Wickham wrote:
>>
>> Hi all,
>>>
>>> Is it possible to determine the environment in which a promise will be
>>> evaluated? e.g.
>>>
>>> f <- function(code) { force(code) }
>>> f({
>>> a <- 1
>>> b <- 2
>>> })
>>>
>>> Is there any way to tell from within f that a and b will be created in
>>> the global environment?
>>>
>>> Thanks,
>>>
>>> Hadley
>>>
>>> --
>>> http://had.co.nz/
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>>
>> --
>> Henrique Dallazuanna
>> Curitiba-Paraná-Brasil
>> 25° 25' 40" S 49° 16' 22" O
>>
>>[[alternative HTML version deleted]]
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
>
--
Henrique Dallazuanna
Curitiba-Paraná-Brasil
25° 25' 40" S 49° 16' 22" O
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Finding the environment of a promise
On 9/9/2009 10:53 AM, Hadley Wickham wrote:
I don't think so in R code, but C code to do it would be possible. It needs
to be in C code to avoid forcing the promise.
Thanks Duncan - I thought that might be the case.
I think we'd be reluctant to make an R function available to do this,
because it requires non-standard evaluation, and it's not something a normal
function should care about.
True, but there are plenty of abnormal functions in R that demonstrate
the usefulness (and danger!) of non-standard evaluation.
(The promise belongs to the caller, not to the
function: why would the function need to play with it? It should be happy
with the value, or maybe a text representation of the promise, for labelling
purposes.)
Is there any way to get a text representation apart from with
deparse(substitute(x))? I think I remember asking you about this some
time ago, but it is still the case that blocks/promises don't store
srcref information? This come up recently while trying to make a
function that would both run a block or code and save it to a separate
file (a sort of poor man's sweave when you just want to include a
small portion of your code in a report). With blocks, the best I
could come up with was:
Promises don't store srcrefs, but the evaluator does (in R-devel), a
statement at a time. So you might be able to look back through the call
stack to find where the call came from. (I forget whether any of this
is accessible from within R. Look at the implementation of traceback()
and browser(), which both access this information.)
Duncan Murdoch
named_block <- function(name, code) {
text <- deparse(substitute(code), width = 100)
# evaluate code
force(code)
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
out <- text[!grepl("\\{|\\}", text)]
out <- gsub("^", "", out)
writeLines(out, filename)
}
b <- 1
named_block("test", {
# This is a comment
a <- 1
})
print(a)
The problem of course is that this loses comments.
You can do better with functions, but it requires more typing and
messing around with environments to ensure everything is scoped
correctly:
named_block <- function(name, f) {
text <- attr(f, "source")
code <- text[!grepl("^function \\(\\)\\{$|\\}", text)]
code <- gsub("^ ", "", code)
# evaluate code
eval(parse(text = code), env = parent.frame())
# construct valid filename
filename <- gsub("[^a-z0-9]+", "-", tolower(name))
filename <- gsub("^-|-$", "", filename)
filename <- paste(filename, ".r", sep = "")
writeLines(code, filename)
}
b <- 1
named_block("test", function (){
# This is a comment
a <- 2
})
# Make sure objects created in correct environment
print(a)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Dependencies of packages' CHECK....
Uwe Ligges writes: >> 2) As part of the binary package build process, run CHECK >>with R_CHECK_FORCE_SUGGESTS = false. > 1, 3-5 sound fine, but I do not see why you need 2). I suppose because it makes me feel dirty to leave the check step out entirely, if there is some utility available from it. But I've got a reputation as an overengineer, so.. In any case, I agree that the earlier check doesn't add anything except possible satisfaction by the binary-package maintainers. - Allen S. Rout __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Monkey patching +.POSIXt
Hi Hadley
> This summer I've been working with a grad student to bring more of the
> date time classes from JODA (http://joda-time.sourceforge.net/) into
> R. To make these work seamlessly with existing date time objects, we
> need to patch +.POSIXt. (The ruby community uses the term
> monkey-patching for this sort of ill-advised, by sometimes necessary,
> internal hackery, hence the title.) The problem is I can't figure out
> how to override +.POSIXt so that it gets called from +. Simply
> including a new +.POSIXt function in the package doesn't work because
> (I presume) + finds and uses base::+.POSIXt. The next thing I tried
> was
>
> assignInNamespace("+.POSIXt", lubridate::`+.POSIXt`, "base")
>
> but that doesn't seem to work either, despite the documentation: "They
> do attempt to alter a copy registered as an S3 method if one is
> found." (perhaps there is a missing not there?)
>
>
In this particular case, the trick is to assign the new version both into the
namespace and into the environment '.__S3MethodsTable__.' inside the namespace.
Speaking as a monkey, I do this kind of thing regularly, and there is a
function 'assign.to.base' in the 'mvbutils' package that does it automatically,
e.g.
assign.to.base( '+.POSIXt', my.plus.POSIXt)
The '.onLoad' of mvbutils has a few examples, including as it happens
'+.POSIXt'. Although the version of 'mvbutils' on CRAN is quite out-of-date,
the code for 'assign.to.base' should be in there.
HTH
Mark Bravington
CSIRO, Hobart, Australia
From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] On Behalf
Of Hadley Wickham [had...@rice.edu]
Sent: 10 September 2009 00:40
To: r-devel@r-project.org
Subject: [Rd] Monkey patching +.POSIXt
Hi all,
In desperation, I also tried the following internal, undocumented
function, but it didn't help either:
registerS3method("+", "POSIXt", lubridate::`+.POSIXt`)
Any ideas?
Thanks,
Hadley
--
http://had.co.nz/
__
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] 'make install' fails on Solaris (PR#13946)
Full_Name: Bob Bownes Version: 2.9.2 OS: Solaris 10 Submission from: (NULL) (164.55.254.106) The sed lines in src/unix/Makefile confuse the grep distributed with Solaris that gets configured by ./configure. Switching from a separator of ':' to a separator of ',' fixes the problem. 76,77c76,77 < @$(SED) -e "s:@rhome:$(rhome):" -e "s:@rincludedir:$(rincludedir):" \ < -e 's:@libsprivate:$(STATIC_LIBR_PC):' \ --- > @$(SED) -e "s,@rhome,$(rhome)," -e "s,@rincludedir,$(rincludedir)," \ > -e 's,@libsprivate,$(STATIC_LIBR_PC),' \ __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Monkey patching +.POSIXt
>
> In this particular case, the trick is to assign the new version both into the
> namespace and into the environment '.__S3MethodsTable__.' inside the
> namespace.
The problem is +.POSIXt doesn't seem to be there:
> exists("+.POSIXt", asNamespace("base")$.__S3MethodsTable__., inherits=F)
[1] FALSE
> Speaking as a monkey, I do this kind of thing regularly, and there is a
> function 'assign.to.base' in the 'mvbutils' package that does it
> automatically, e.g.
>
> assign.to.base( '+.POSIXt', my.plus.POSIXt)
I tried that too, but without any luck.
Hadley
--
http://had.co.nz/
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Monkey patching +.POSIXt
Hmmm... 'assign.to.base( "+.POSIXt", myfun)' works on my system (2.9.1 patched
on Windows, at time of writing). Could be the 'mvbutils' version, I guess. What
happened when you tried it? And what if you did 'getAnywhere( "+.POSIXt")'
afterwards?
I was wrong about where '+.POSIXt' lives, though-- sorry. It is directly in
'baseenv()', not in 'baseenv().__S3MethodsTable__.'. 'assign.to.base' looks in
both, and in other packages as well as 'baseenv()'.
Mark
--
Mark Bravington
CSIRO Mathematical & Information Sciences
Marine Laboratory
Castray Esplanade
Hobart 7001
TAS
ph (+61) 3 6232 5118
fax (+61) 3 6232 5012
mob (+61) 438 315 623
Hadley Wickham wrote:
>> In this particular case, the trick is to assign the new version both
>> into the namespace and into the environment '.__S3MethodsTable__.'
>> inside the namespace.
>
> The problem is +.POSIXt doesn't seem to be there:
>
>> exists("+.POSIXt", asNamespace("base")$.__S3MethodsTable__.,
>> inherits=F)
> [1] FALSE
>
>
>> Speaking as a monkey, I do this kind of thing regularly, and there
>> is a function 'assign.to.base' in the 'mvbutils' package that does
>> it automatically, e.g.
>>
>> assign.to.base( '+.POSIXt', my.plus.POSIXt)
>
> I tried that too, but without any luck.
>
> Hadley
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 'make install' fails on Solaris (PR#13946)
On Thu, 10 Sep 2009, bow...@gmail.com wrote: Full_Name: Bob Bownes Version: 2.9.2 OS: Solaris 10 Submission from: (NULL) (164.55.254.106) The sed lines in src/unix/Makefile confuse the grep distributed with Solaris that gets configured by ./configure. Well, it calls sed not grep! Which version was that -- it works for me and for several others. I have SED = /usr/xpg4/bin/sed (see file Makeconf), and that is 'distributed with Solaris': perhaps you do not have it installed? The danger of changing R to fix a broken OS tool is that the change may break on other people's tools -- better to fix the tool. Switching from a separator of ':' to a separator of ',' fixes the problem. 76,77c76,77 < @$(SED) -e "s:@rhome:$(rhome):" -e "s:@rincludedir:$(rincludedir):" \ < -e 's:@libsprivate:$(STATIC_LIBR_PC):' \ --- @$(SED) -e "s,@rhome,$(rhome)," -e "s,@rincludedir,$(rincludedir)," \ -e 's,@libsprivate,$(STATIC_LIBR_PC),' \ -- Brian D. Ripley, rip...@stats.ox.ac.uk 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] 'make install' fails on Solaris (PR#13946)
Prof Brian Ripley wrote: On Thu, 10 Sep 2009, bow...@gmail.com wrote: Full_Name: Bob Bownes Version: 2.9.2 OS: Solaris 10 Submission from: (NULL) (164.55.254.106) The sed lines in src/unix/Makefile confuse the grep distributed with Solaris that gets configured by ./configure. Well, it calls sed not grep! Which version was that -- it works for me and for several others. I have SED = /usr/xpg4/bin/sed (see file Makeconf), and that is 'distributed with Solaris': perhaps you do not have it installed? The danger of changing R to fix a broken OS tool is that the change may break on other people's tools -- better to fix the tool. Is this a tool problem at all? The most common reason for separator breakage is that one of the substitution strings contains the separator. E.g., the sed line may break if @rhome contains a colon, and after the fix it will break if it contains a comma... Switching from a separator of ':' to a separator of ',' fixes the problem. 76,77c76,77 < @$(SED) -e "s:@rhome:$(rhome):" -e "s:@rincludedir:$(rincludedir):" \ < -e 's:@libsprivate:$(STATIC_LIBR_PC):' \ --- @$(SED) -e "s,@rhome,$(rhome)," -e "s,@rincludedir,$(rincludedir)," \ -e 's,@libsprivate,$(STATIC_LIBR_PC),' \ -- 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 ~~ - (p.dalga...@biostat.ku.dk) FAX: (+45) 35327907 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
