Re: [Rd] R, Rcmdr crash on WinXP PRO laptop (PR#8583)
I had this same issue with Rgui crashing on Windows XP Pro (probably due to conflicting graphics card versions) and solved the problem by disabling NVIDEA GeForce4 in Computer Management: Device Manager: Display Adapters. - Original Message - From: <[EMAIL PROTECTED]> To: Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 09, 2006 11:19 PM Subject: Re: [Rd] R, Rcmdr crash on WinXP PRO laptop (PR#8583) > > I think I might have a workaround now. Originally I had all the scripts > on my desktop, so I came to think about if the problem is with the > shortcuts to the other programs or to My computer or something like > that. I put all the scripts to a folder which is still on my desktop, > and I haven't experienced any crashes since. My best guess is that it is > an explorer/graphics card related issue. > > JE > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: log='z' for image, contour, persp?
> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> > on Tue, 09 May 2006 18:41:09 -0400 writes: Duncan> I've been thinking of adding the possibility of Duncan> including "z" among the axes to be logged in image, Duncan> contour, and persp. In the first two, it would only Duncan> affect where the breaks were set if they are Duncan> calculated automatically; it would have a bigger Duncan> effect in persp. Duncan> For example, Duncan> image(x, y, z, log="z") Duncan> would set 12 colours evenly spaced on a log scale of Duncan> the z values. (12 because that's the default). Duncan> We already support Duncan> image(x, y, z, log="x") Duncan> to scale the x axis (though there's a spurious Duncan> warning; I'll fix that). Duncan> image(z, log="x") Duncan> fails because it tries to take a log of zero. Duncan> Does it seem like a good idea for these 3D functions Duncan> to support log="z" the way 2D functions do? Yes, I think it's a good idea. You forgot to mention filled.contour() which is image() + "color - legend" For that one, it would be particularly useful to automatically get a "evenly space in log-scale" one. Duncan> Duncan Murdoch Note that for things like the above, I have added a simple function lseq() in package 'sfsmisc' -- which I have contemplated moving to R. Maybe this could happen at the same time and you could make use of it for the above. Martin __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Typo in getAllMethods() (PR#8848)
This is a multi-part message in MIME format.
--_=_NextPart_001_01C67389.C6480D9F
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
The function getAllMethods in the methods package uses the non-existent
function packageName where I believe the function getPackageName was
intended.=20
For example:
> getAllMethods("formula")
Error in sprintf(gettext(fmt, domain =3D domain), ...) :=20
could not find function "packageName"
The patch to RMethodUtils.R is here:
238c238
< warning(gettextf("'%s' from '%s' is a non-generic function;
no methods available", f, packageName(gwhere)), domain =3D NA)
---
> warning(gettextf("'%s' from '%s' is a non-generic function;
no methods available", f, getPackageName(gwhere)), domain =3D NA) =20
> R.version
_=20
platform i386-pc-mingw32 =20
arch i386 =20
os mingw32 =20
system i386, mingw32=20
status =20
major 2=20
minor 3.0 =20
year 2006 =20
month 04 =20
day24 =20
svn rev37909=20
language R=20
version.string Version 2.3.0 (2006-04-24)
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor | Boston, MA | 02109
Tel: 617/392-8396Fax:617/476-6389
mailto:[EMAIL PROTECTED]
> This e-mail, and any attachments hereto, are intended for use by the
> addressee(s) only and may contain information that is (i) confidential
> information of Geode Capital Management, LLC and/or its affiliates,
> and/or (ii) proprietary information of Geode Capital Management, LLC
> and/or its affiliates. If you are not the intended recipient of this
> e-mail, or if you have otherwise received this e-mail in error, please
> immediately notify me by telephone (you may call collect), or by
> e-mail, and please permanently delete the original, any print outs and
> any copies of the foregoing. Any dissemination, distribution or
> copying of this e-mail is strictly prohibited.=20
>=20
--_=_NextPart_001_01C67389.C6480D9F
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Typo in getAllMethods()
The function getAllMethods in the =
methods package uses the non-existent function packageName where I =
believe the function getPackageName was intended.
For example:
> =
getAllMethods("formula")
Error in sprintf(gettext(fmt, =
domain =3D domain), ...) :
could not find function =
"packageName"
The patch to RMethodUtils.R is =
here:
238c238
< =
warning(gettextf("'%s' from '%s' is a non-generic function; no =
methods available", f, packageName(gwhere)), domain =3D =
NA)
---
> =
warning(gettextf("'%s' from '%s' is a non-generic function; no =
methods available", f, getPackageName(gwhere)), domain =3D =
NA)
> R.version
&n=
bsp; =
_=
=
platform =
i386-pc-mingw32 &nbs=
p;
arch =
i386 &nb=
sp;
os =
=
mingw32 =
system i386, =
mingw32 =
status &n=
bsp; &nb=
sp; =
major =
2=
=
minor =
3.0 &nbs=
p;
year =
2006 &nb=
sp;
month =
04=
; =
day =
; =
24=
; =
svn =
rev =
37909 &n=
bsp;
language =
R=
=
version.string Version 2.3.0 =
(2006-04-24)
Robert McGehee
Quantitative Analyst
Geode Capital Management, LLC
53 State Street, 5th Floor =
| Boston, MA | 02109
Tel: 617/392-8396 =
Fax:617/476-6389
mailto:[EMAIL PROTECTED]">mailto:[EMAIL PROTECTED]
This e-mail, =
and any attachments hereto, are intended for use by the addressee(s) =
only and may contain information that is (i) confidential information of =
Geode Capital Management, LLC and/or its affiliates, and/or (ii) =
proprietary information of Geode Capital Management, LLC and/or its =
affiliates. If you are not the intended recipient of this e-mail, or if =
you have otherwise received this e-mail in error, please immediately =
notify me by telephone (you may call collect), or by e-mail, and please =
permanently delete the original, any print outs and any copies of the =
foregoing. Any dissemination, distribution or copying of this e-mail is =
strictly prohibited.
--_=_NextPart_001_01C67389.C6480D9F--
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Warning: use of NULL environment is deprecated (in R CMD check)
* checking S3 generic/method consistency ... WARNING Warning: use of NULL environment is deprecated Warning: use of NULL environment is deprecated See section 'Generic functions and methods' of the 'Writing R Extensions' manual. I don't get any other warnings or errors. Can anyone suggest what the problem might be? (R2.3.0, OS X) Thanks, Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] suppressing "global" cppflags in an individual package
Kasper Daniel Hansen wrote: > It is indeed the case that after updating to GCC 4 the package gets > broken using -O2. I agree this needs to be fixed, but the error (which I > believe I have kind of localized, but not really understood) stems from > a C++ library we have little control over, so it would be nice to have a > fix for the time being that does not require a reinstallation of R - > especially since we actually have users who currently (or soon will be) > testing it. I was thus looking for a temporary quick fix allowing me to > disable the optimization level, while I take the time to fix it properly. > > Kurt Hornik have replied of-list that it is possible to do so using a > ~/.R/Makevars file (which I have not had the time to test > unfortunately), but reading your comment about CPPFLAGS and CXXFLAGS > makes me think I can indeed override it using the package Makevars file. > The flags I was passing to the compiler were library locations anyway > which was for the preprocessor. Can't do that with Makevars, because its defines are included first (and get overriden by R's built-time flags later in the command line), as Simon on the list has pointed out. If it is a one-off operation, you can be slightly barbaric and just record all the operations done by R CMD SHLIB/INSTALL e.g. piping them to a file with >& , edit the file manually and exec the operations by "sh file", then copy the differently-built shared library over by hand, over-writing the broken one. Not very elegant, but it will buy you some time until either the compiler or the package get fixed. Hin-Tak Leung __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: log='z' for image, contour, persp?
On 5/10/2006 4:23 AM, Martin Maechler wrote: >> "Duncan" == Duncan Murdoch <[EMAIL PROTECTED]> >> on Tue, 09 May 2006 18:41:09 -0400 writes: > > Duncan> I've been thinking of adding the possibility of > Duncan> including "z" among the axes to be logged in image, > Duncan> contour, and persp. In the first two, it would only > Duncan> affect where the breaks were set if they are > Duncan> calculated automatically; it would have a bigger > Duncan> effect in persp. > > Duncan> For example, > > Duncan> image(x, y, z, log="z") > > Duncan> would set 12 colours evenly spaced on a log scale of > Duncan> the z values. (12 because that's the default). > > Duncan> We already support > > Duncan> image(x, y, z, log="x") > > Duncan> to scale the x axis (though there's a spurious > Duncan> warning; I'll fix that). > > Duncan> image(z, log="x") > > Duncan> fails because it tries to take a log of zero. > > Duncan> Does it seem like a good idea for these 3D functions > Duncan> to support log="z" the way 2D functions do? > > Yes, I think it's a good idea. > > You forgot to mention filled.contour() > which is image() + "color - legend" > For that one, it would be particularly useful to automatically > get a "evenly space in log-scale" one. Thanks for pointing that out. This is a little tricky: I think filled.contour would want evenly spaced contours, but use the axTicks() version of pretty labels on the legend; but contour() would probably want the contours themselves to be at nice round values. It looks as though I'll need to think about adding a log=TRUE option to pretty(), to expose or duplicate the internal code that sets log axes. (axTicks is close, but I don't think it allows for automatic computation of axp[3]). Duncan > > Duncan> Duncan Murdoch > > Note that for things like the above, I have added > a simple function lseq() in package 'sfsmisc' -- which I have > contemplated moving to R. Maybe this could happen at the same > time and you could make use of it for the above. > > Martin > > __ > 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] Warning: use of NULL environment is deprecated (in R CMD check)
On 5/10/2006 5:58 AM, hadley wickham wrote: > * checking S3 generic/method consistency ... WARNING > Warning: use of NULL environment is deprecated > Warning: use of NULL environment is deprecated > See section 'Generic functions and methods' of the 'Writing R Extensions' > manual. > > I don't get any other warnings or errors. Can anyone suggest what the > problem might be? (R2.3.0, OS X) I'd guess you're using a pre-release version of 2.3.0. If that's not it, then it may be an error in your package, using envir=NULL some place you shouldn't (but that doesn't explain why the error arose where it did). If neither of those apply, I'd like to try to duplicate the error. Could you send me a tarball of the package? Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] array dimname argument (was Re: YA S4 method dispatch question)
On Tue, 9 May 2006, Martin Morgan wrote:
> You won't like this ...;)
>
> return(drop(callGeneric(array(x,
> c(1, length(x)),
> val)
> )))
>
> i.e., 'val' is inside 'array'!
>
> I was discouraged from answering sooner by the complexity of your
> example; simplifying it might have provided an immediate answer...
>
> > x <- 1:8
> > foo(array(x, c(1,length(x)), val)
> +
>
Geez... I should have noticed that. Thanks for the catch.
I am rather surprised (never having tried it before) that
array() silently disregards my unintentional dimname
argument.
> x <- 1:8
> matrix(x, 1, length(x), dimnames = "argument used")
Error in matrix(x, 1, dimnames = "argument used") :
'dimnames' must be a list
> array(x, c(1, length(x)), "argument silently ignored")
[,1] [,2] [,3] [,4] [,5] [,6] [,7] [,8]
[1,]12345678
> array
function (data = NA, dim = length(data), dimnames = NULL)
{
data <- as.vector(data)
vl <- prod(dim)
if (length(data) != vl) {
if (vl > .Machine$integer.max)
stop("'dim' specifies too large an array")
data <- rep(data, length.out = vl)
}
if (length(dim))
dim(data) <- dim
if (is.list(dimnames) && length(dimnames)) ##HERE##
dimnames(data) <- dimnames
data
}
The matrix method performs no check prior to assigning
dimnames. Why doesn't array function the same way?
--
SIGSIG -- signature too long (core dumped)
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Warning: use of NULL environment is deprecated (in R CMD check)
> I don't get any other warnings or errors. Can anyone suggest what the > problem might be? (R2.3.0, OS X) For reference: the problem was caused by having dependent packages that been installed prior to R 2.3.0. Hadley __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Mere chat on vectorisation matters
Hi, people. Allow me to chat a tiny bit on two vectorisation-related matters, in the context of R. I'm curious about if the following ideas have ever been considered, and rejected already. First is about using the so-called Duff's device for partially unrolling loops. I did not overly check in R sources, and am not familiar with them anyway, but the only usage I saw is within "src/gnuwin32/malloc.c". Maybe it could be put to good usage in "src/main/arithmetic.c" and elsewhere. Second is about what is called "chaining" on some vector computers, in which one vector operation uses, as an operand, the result of another vector operation, even before that result is sent for register or memory storage; R could use this technique for sparing memory, when it "knows" that the result is going to be discarded anyway. I used and abused Duff's device a good while ago, when I was working in computer graphics; it was routinely used to speed up image-wide operations. With a few properly devised C pre-processor macros, it was made easy to use (I thrown mine away a few years ago, recognizing I lost interest in low-level coding matters, the macros could easily be rethought anyway). Questions existed at the time about unrolled loops fitting or not within specialised fetch-next-instruction caches of some CPUs, but nowadays, memory caches are much bigger then they used to be, I have the prejudice it is just not a problem anymore. Maybe more of a concern might be the conditionals implementing vector recycling (already hidden in macros), as they may disrupt the speed of merely falling through linear code. One might probably do without jumps using clever masking operations, yet I wonder how far we would safely benchmark at configuration time to decide best code to generate, and how good C would be to write masked conditionals. I'm not familiar enough with modern CPUs to judge if this really needs to be addressed or not. I would not doubt that hardware chaining is worth all the efforts the engineers put so the hardware recognises and activates it on the fly. Vectorised chaining implemented in software as a way to spare memory, may be much of a challenge, as it requires sort of half-compilation. One one hand, it might alleviate memory problems which are often the subject of discussions on R-help; through thrashing, going over real memory and into paging may considerably slow down an R application. On the other hand, unless very carefully implemented, chaining overhead might slow down all non-thrashing applications, which is most of them. Nevertheless, being softer on memory requirements is already a concern in R, I vaguely remember having read that R "tries to prove" that a vector being modified will not needed anymore in its original form, and when the proof succeeds, the original vector gets modified without prior copying. Chaining, despite difficult to implement, might be a significant further step, and so, be worth a discussion. -- François Pinard http://pinard.progiciels-bpi.ca __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] What is callGeneric used for?
I've recently come across two pieces of code using calls to callGeneric() inside the definition of a method. In both cases, it appears to me that the callGeneric call could be replaced with a "real" call to the generic, say foo(x) instead of callGeneric(x) inside method foo. My understanding from the docs is that when called with arguments, it is just like calling the actual generic. Clear enough, but what does this provide that just calling the actual generic doesn't? Similarly, when would one want to make the recursive call that results from calling callGeneric with no args? Thanks, + seth __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Allowed quasibinomial links (PR#8851)
Full_Name: Henric Nilsson
Version: 2.3.0 Patched (2006-05-09 r38014)
OS: Windows 2000 SP4
Submission from: (NULL) (83.253.9.137)
When supplying an unavailable link to `quasibinomial', the error message looks
strange. E.g.
> quasibinomial("x")
Error in quasibinomial("x") : 'x' link not available for quasibinomial family,
available links are "logit", ", ""probit" and "cloglog"
Clearly, something's missing. A quick peek in the code reveals that `log' is
allowed, but is missing from the above list.
Furthermore, shouldn't `quasibinomial' also allow the `cauchit' link?
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] 2.3.0 make install fails on solaris
hello r development team,
i'm building R 2.3.0 on solaris and when i run the 'make install' i'm
getting a syntax error during the "installing etc ..." which causes the
installation to fail. i get this error whether i use gnu-make of
sun-make, see the error and reasons below.
gmake[1]: Entering directory `/export/medusa/darin/build/R-2.3.0/etc'
installing etc ...
/bin/bash: -c: line 1: syntax error near unexpected token `;'
/bin/bash: -c: line 1: `for f in ; do /opt/csw/bin/ginstall -c -m 644
${f} "/export/home/darin/build/R-2.3.0/cswstage/opt/csw/lib/R/etc"; done'
gmake[1]: *** [install] Error 2
gmake[1]: Leaving directory `/export/medusa/darin/build/R-2.3.0/etc'
gmake: *** [install] Error 1
in etc/Makefile if i comment lines 60-62 make install continues without
incident, here are those lines.
@for f in $(EXPORTFILES); do \
$(INSTALL_DATA) $${f} "$(rhome)/$(subdir)"; \
done
this has changed from R-2.2.1.
diff etc/Makefile ../R-2.2.1/etc/Makefile"
60c52
< @for f in $(EXPORTFILES); do \
---
> @for f in $(OBJECTS) $(EXPORTFILES); do \
should i open a bug for this issue? i'm also curious as to if this has
come up on other platforms.
--
Darin Perusich
Unix Systems Administrator
Cognigen Corporation
395 Youngs Rd.
Williamsville, NY 14221
[EMAIL PROTECTED]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] RFC: log='z' for image, contour, persp?
Yes, it does. I've needed it more often than not. -Don At 6:41 PM -0400 5/9/06, Duncan Murdoch wrote: >I've been thinking of adding the possibility of including "z" among the >axes to be logged in image, contour, and persp. In the first two, it >would only affect where the breaks were set if they are calculated >automatically; it would have a bigger effect in persp. > >For example, > >image(x, y, z, log="z") > >would set 12 colours evenly spaced on a log scale of the z values. (12 >because that's the default). > >We already support > >image(x, y, z, log="x") > >to scale the x axis (though there's a spurious warning; I'll fix that). > >image(z, log="x") > >fails because it tries to take a log of zero. > >Does it seem like a good idea for these 3D functions to support log="z" >the way 2D functions do? > >Duncan Murdoch > >__ >R-devel@r-project.org mailing list >https://stat.ethz.ch/mailman/listinfo/r-devel -- -- Don MacQueen Environmental Protection Department Lawrence Livermore National Laboratory Livermore, CA, USA __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] 2.3.0 make install fails on solaris
Darin Perusich <[EMAIL PROTECTED]> writes:
> hello r development team,
>
> i'm building R 2.3.0 on solaris and when i run the 'make install' i'm
> getting a syntax error during the "installing etc ..." which causes the
> installation to fail. i get this error whether i use gnu-make of
> sun-make, see the error and reasons below.
>
> gmake[1]: Entering directory `/export/medusa/darin/build/R-2.3.0/etc'
> installing etc ...
> /bin/bash: -c: line 1: syntax error near unexpected token `;'
> /bin/bash: -c: line 1: `for f in ; do /opt/csw/bin/ginstall -c -m 644
> ${f} "/export/home/darin/build/R-2.3.0/cswstage/opt/csw/lib/R/etc"; done'
> gmake[1]: *** [install] Error 2
> gmake[1]: Leaving directory `/export/medusa/darin/build/R-2.3.0/etc'
> gmake: *** [install] Error 1
>
> in etc/Makefile if i comment lines 60-62 make install continues without
> incident, here are those lines.
>
> @for f in $(EXPORTFILES); do \
>$(INSTALL_DATA) $${f} "$(rhome)/$(subdir)"; \
> done
>
> this has changed from R-2.2.1.
>
> diff etc/Makefile ../R-2.2.1/etc/Makefile"
>
> 60c52
> < @for f in $(EXPORTFILES); do \
> ---
> > @for f in $(OBJECTS) $(EXPORTFILES); do \
>
> should i open a bug for this issue? i'm also curious as to if this has
> come up on other platforms.
It only happens if your bash is old enough. I get the
rubin:~/> for f in ; do echo $f ; done
bash: syntax error near unexpected token `;'
rubin:~/>help
GNU bash, version 2.05.0(1)-release (sparc-sun-solaris2.9)
for f in ; do echo $f ; done
but not on Linux boxes with bash 3.x. However, I don't think we assume
bash 3.x (or bash as such for that matter and sh has same issue on
Solaris 9), so it is indeed a bug.
--
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] S4 initialize methods, unexpected recursive callNextMethod
Hi,
Given a simple three class hierarchy: A <-- B <-- C
I want to define an initialize method for each class such that when I
call new("C", x=5), the initialize methods for A and B are used to
incrementally build the object.
When I do what seems obvious to me using callNextMethod, I get an
infinite recursion. An example follows...
setClass("A", representation(a="numeric"))
setClass("B", representation(b="numeric"), contains="A")
setClass("C", representation(c="numeric"), contains="B")
setMethod("initialize", signature(.Object="A"),
function(.Object, x) {
cat("in A\n")
[EMAIL PROTECTED] <- x
.Object
})
setMethod("initialize", signature(.Object="B"),
function(.Object, x) {
cat("in B\n")
.Object <- callNextMethod(.Object=.Object, x=x)
[EMAIL PROTECTED] <- [EMAIL PROTECTED] + 1
.Object
})
setMethod("initialize", signature(.Object="C"),
function(.Object, x) {
cat("in C\n")
.Object <- callNextMethod(.Object=.Object, x=x)
[EMAIL PROTECTED] <- [EMAIL PROTECTED] + [EMAIL PROTECTED] + 1
.Object
})
## Works as I am expecting for B
> myB <- new("B", 4)
in B
in A
## When you create a C, the B method gets called but the appropriate
## next method info seems lost and we end up back in C's method ?!
> myC <- new("C", 5)
in C
in B
in C
in B
in C
C-c C-c
Should this work? Is there a better way to organize the initializers
for a simple hierarchy (perhaps assume that args to the initializers
are not the same for A, B, and C).
Thanks,
+ seth
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] What is callGeneric used for?
In the case of arithmetic methods you might not know or care whether the generic is, say, + or -. On 5/10/06, Seth Falcon <[EMAIL PROTECTED]> wrote: > I've recently come across two pieces of code using calls to > callGeneric() inside the definition of a method. > > In both cases, it appears to me that the callGeneric call could be > replaced with a "real" call to the generic, say foo(x) instead of > callGeneric(x) inside method foo. > > My understanding from the docs is that when called with arguments, it > is just like calling the actual generic. Clear enough, but what does > this provide that just calling the actual generic doesn't? > > Similarly, when would one want to make the recursive call that results > from calling callGeneric with no args? > > Thanks, > > + seth > > __ > 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] suppressing "global" cppflags in an individual package
Thank you Simon, a little comment below On May 9, 2006, at 2:49 PM, Simon Urbanek wrote: > On May 9, 2006, at 1:11 PM, Kasper Daniel Hansen wrote: > >> It is indeed the case that after updating to GCC 4 the package >> gets broken using -O2. I agree this needs to be fixed, but the error >> [...] >> unfortunately), but reading your comment about CPPFLAGS and >> CXXFLAGS makes me think I can indeed override it using the package >> Makevars file. The flags I was passing to the compiler were >> library locations anyway which was for the preprocessor. >> > > AFAIR you cannot override CPPFLAGS/CXXFLAGS in Makevars, because it > gets included first. You can, however, use something like this: > > all: $(SHLIB) > > MYCFLAGS=-O0 > > %.o: %.c > $(CC) $(ALL_CPPFLAGS) $(ALL_CFLAGS) $(MYCFLAGS) -c $< -o $@ > > for C, or for C++ accordingly: > > %.o: %.cc > $(CXX) $(ALL_CPPFLAGS) $(ALL_CXXFLAGS) $(MYCXXFLAGS) -c $< - > o $@ Actually you do not need the all: line, and since I use .cpp as C++ extension, all I needed was %.o: %.cpp $(CXX) $(ALL_CPPFLAGS) -O0 -c $< -o $@ Note that I needed to delete the $(ALL_CXXFLAGS) which basically reads R's flags. Now, is there any way to (in the Makevars file) operate on $ (ALL_CXXFLAGS), since all I want is to delete any -O* flag? Or is defining rules and variables all I can do? Actually, where do I read about the Makevars syntax. Is it from autoconf (of which I only now the name). The section on it in R-exts is useful (hey, I managed to make one in the first place), but not comprehensive. /Kasper > However, don't ask me how portable this is ;). It exploits the fact > that old-style rules .c.o used by Makeconf are overridden by the > new-style rules regardless of their position. Nevertheless, you > could still use specific rules if desired without a full-blown > Makefile. (I always recommend the use of Makevars as far as > possible, because most writers of Makefiles get the shlib > compilation wrong). > > Cheers, > Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
