Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
> A J Rossini writes:
> On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
> <[EMAIL PROTECTED]> wrote:
>> > Peter Dalgaard writes:
>>
>> > Kurt Hornik <[EMAIL PROTECTED]> writes:
>> >> > A J Rossini writes:
>> >>
>> >> > But I don't see a problem with "package("package")", though I'm sure
>> >> > I'm missing something.
>> >>
>> >> package() [sic] might be the creator for package objects, provided we
>> >> can decide on what they are (and what kind of packages [source,
>> >> installed, ...] they are used for).
>> >>
>> >> usePackage() or use_package() otoh would indicate to "use" a package
>> >> (i.e., load and attach it). The tricky part is deciding about the
>> >> interface (e.g., finally disallowing non-standard evaluation as it is a
>> >> programmer's nightmare) and what it should return. And that is work in
>> >> progress ...
>>
>> > Any information on the rate...? (I still vote for usepackage() btw.)
>>
>> Why not use(), as the GCD?
> Excellent suggestion, Kurt.
And so obvious :-)
>> > It would be good if we could at least have an outline of the intended
>> > functionality and see if we could forge ahead and get a preliminary
>> > version done in time for 2.1.x
>>
>> Help us out.
>>
>> use <- function(package, pos = 2, lib.loc, ...)
> use <- function(packageName,pos=2,library, ...)
> I could argue that "library" and "lib.loc" try to describe the same
> thing (a name and its pointer).
We need to decide whether to stay with the "library" concept, or maybe
go for another one alongside.
>> where 'package' is either a character string or some sort of package
>> object/reference, to be specified later. And 'lib.loc' needs to have a
>> different name if we rename libraries into stores or whatever ...
> I think package ought to be a character string. Unless you want to
> combine the packageName and libraryLocation into some form of data
> object, or packageName, libraryLocation, and an environment containing
> the erstwhile contents?
For the time being, the package would definitely be specified as a
character string with its name. But [RG will like this] I find it
rather clumsy to have tons of equal-level arguments which in fact could
use some hierarchical structure. What we really want is some
SPECIFICATION of the package to be used, definitely including its name,
but maybe also where it should come from (library location) or which
version it should have at least or at most, etc. So something like
use(package_spec("foo", version = ~ > "1.5.8"), pos = 12, ...)
>> What should this return? Currently, 'library' returns the list of
>> loaded (or available) packages by default, as a list of names, which is
>> not good enough. So we need something like the DLLInfoList returned by
>> getLoadedDLLs() (and the docs should actually mention that class), or
>> something usable by the package management tools ... and this is under
>> redesign as well.
> Perhaps "use" should incorporate "require" functionality, i.e. TRUE or
> FALSE depending on whether you can use it after the "use" function
> call.
As Brian said, we would most likely get rid of library() alongside.
I would condiser the TRUE/FALSE paradigm outdated. The FALSE case
really consists of a variety or error conditions, and we should return
these as such (rather than indicating "oh there was some problem but
were not telling you which one, unless you are a human reader and look
at the condition message ...").
>>
>> But why should this really return info on all loaded/attached packages?
>> An alternative might be just returning the package meta-data in some
>> form. Or nothing, which would fit into the idea that it really does
>> nothing apart from loading and attaching a package.
> I like "libraryContents()" or similar to figure out loaded and
> potentially loadable packages.
installed.packages() for the time being.
>> (And maybe a condition object inheriting from packageLoadAndAttachError
>> in case of failure? :-))
> Yes. whatever.
-k
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Compiler-specific flags with PKG_CFLAGS
> Paul Roebuck writes:
> On Wed, 9 Feb 2005, Kurt Hornik wrote:
>> > Paul Roebuck writes:
>>
>> > On Wed, 9 Feb 2005, Kurt Hornik wrote:
>> >> > Paul Roebuck writes:
>> >>
>> >> > On Tue, 8 Feb 2005, Kurt Hornik wrote:
>> >> >> This concerns the packages...
>> >> >> for which current versions of r-devel now report problems with
>> >> >> non-portable compilation flags in Makevars[.in] files:
>> >> >>
>> >> >> Problems in package 'rwt':
>> >> >> Non-portable flags in variable 'PKG_CFLAGS':
>> >> >> -Wall -ansi -pedantic
>> >> >>
>> >> >> These flags are mostly GCC specific and not portable.
>> >> >> (Do not assume that any -Ox will work.)
>> >> >>
>> >> >> Can you please fix these problems, and provide an update of your
>> >> >> package?
>> >>
>> >> > It has been on my todo list since Ripley brought it up
>> >> > several weeks ago in r-devel but hadn't exactly figured
>> >> > out how to package it as such. Someone have an example
>> >> > of how to add compiler flags for GCC when it is being
>> >> > used and otherwise not? I'm assuming Makevars isn't being
>> >> > passed through cpp and I can't just use #ifdef. In this case,
>> >> > I could just leave them out but I hate to lose the warnings
>> >> > for development. Using 'configure' is probably the only
>> >> > option but really didn't want to use it for just stricter
>> >> > error checking during compilation.
>> >>
>> >> I think the simplest way to achieve this is to configure R
>> >> locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but
>> >> leave the corresponding PKG_CFLAGS etc variables in package
>> >> src/Makevars alone.
>>
>> > I can do that for workstations which I have admin priviledges
>> > and have a private version of R; how about the ones I don't?
>>
>> It depends: R-exts says
>>
>> Flags which are set in file `etc/Makeconf' can be overridden by
>> the environment variable `MAKEFLAGS' (at least for systems using
>> GNU `make'), as in (Bourne shell syntax)
>>
>> MAKEFLAGS="CFLAGS=-O3" R CMD SHLIB *.c
>>
>> or by using a `Makefile'.
>>
>> so if you have GNU Make, you can actually set MAKEFLAGS accordingly in
>> your R_ENVIRON file.
>>
>> What you can also try is to have a make (Sys.getenv("MAKE")) script in
>> your PATH which does something like
>>
>> /path/to/real/make $* CFLAGS=-O3
>>
>> (but I am never sure whether command line vars override the ones in
>> files?)
> Thanks for the suggestions. Setting the environment prior to running
> R CMD is not practical for me, typing-wise. I guess if made my
> .Renviron file architecture-specific it might work, but that seems
> overkill.
Also, I forgot that it does not work, because R CMD only sources
R_HOME/etc/Renviron, but not the user level Renviron file.
This is really why we need the new mechanism ...
-k
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] install issue | suse 9.2
that seems to have been it... i installed 32bit gcc-g77... replaced everything with 64it version and it configure completes... thank you for your help... -Original Message- From: Peter Dalgaard [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:54 PM To: Dale Ryon Wilhelm Cc: Prof Brian Ripley; r-devel@stat.math.ethz.ch Subject: Re: [Rd] install issue | suse 9.2 It's not endemic to suse 9.2 (compile running as I write this). Google finds some messages from the amd64 list with similar error messages. Any chance you are running a 64bit OS and mixing up 32 and 64bit tool chains? rpm -qf `which gas` rpm -qf `which g77` could be revealing. "Dale Ryon Wilhelm" <[EMAIL PROTECTED]> writes: > looked thru config.log and got the following ( see below )... not > knowing much about fortran, this doesn't make much sense to me... my > apologies for the initial html message... > > configure:25460: checking how to get verbose linking output from g77 > configure:25471: g77 -c conftest.f >&5 > /tmp/ccK3gsfu.s: Assembler messages: > /tmp/ccK3gsfu.s:8: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:12: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:13: Error: suffix or operands invalid for `push' > configure:25477: $? = 1 > configure: failed program was: > | program main > | > | end > configure:25556: WARNING: compilation failed > configure:25562: result: > configure:25564: checking for Fortran libraries of g77 > configure:25585: g77 -o conftest -L/usr/local/lib conftest.f >&5 > /tmp/cclyaHyt.s: Assembler messages: > /tmp/cclyaHyt.s:8: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:12: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:13: Error: suffix or operands invalid for `push' > configure:25746: result: > configure:25785: checking for dummy main to link with Fortran libraries > configure:25824: gcc -o conftest -g -O2 -I/usr/local/include > -L/usr/local/lib co > nftest.c -ldl -lm >&5 > configure:25830: $? = 0 > configure:25834: test -z > || test ! -s conftest.err > configure:25837: $? = 0 > configure:25840: test -s conftest > configure:25843: $? = 0 > configure:25921: result: none > configure:25958: checking for Fortran name-mangling scheme > configure:25972: g77 -c conftest.f >&5 > /tmp/ccpZMdHB.s: Assembler messages: > /tmp/ccpZMdHB.s:6: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:8: Error: suffix or operands invalid for `pop' > /tmp/ccpZMdHB.s:14: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:16: Error: suffix or operands invalid for `pop' > configure:25978: $? = 1 > configure: failed program was: > | subroutine foobar() > | return > | end > | subroutine foo_bar() > | return > | end > configure:26186: error: cannot compile a simple Fortran program > See `config.log' for more details. > > > > > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 09, 2005 2:08 PM > To: Dale Ryon Wilhelm > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] install issue | suse 9.2 > > It says > > > See `config.log' for more details > > Please look there and extract the information (and see the comment about > > HTML mail below). > > > On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: > > > i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run > > configure, i get the following error: > > > > > > > > checking how to get verbose linking output from g77... configure: > > WARNING: compilation failed > > > > > > > > checking for Fortran libraries of g77... > > > > checking for dummy main to link with Fortran libraries... none > > > > checking for Fortran name-mangling scheme... configure: error: cannot > > compile a simple Fortran program > > > > See `config.log' for more details > > > > > > > > anybody know why i am getting this error? g77 is installed correctly > and > > working properly... > > > > > > > > > > > > -<0>- > > > > d. ryon wilhelm > > > > EVNINE-VAUGHAN ASSOCIATES, INC. > > > > 415.835.7855 > > > > > > > > > > [[alternative HTML version deleted]] > > The posting guide does ask you not to send HTML mail. > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > > __ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
Re: [Rd] install issue | suse 9.2
It's not endemic to suse 9.2 (compile running as I write this). Google finds some messages from the amd64 list with similar error messages. Any chance you are running a 64bit OS and mixing up 32 and 64bit tool chains? rpm -qf `which gas` rpm -qf `which g77` could be revealing. "Dale Ryon Wilhelm" <[EMAIL PROTECTED]> writes: > looked thru config.log and got the following ( see below )... not > knowing much about fortran, this doesn't make much sense to me... my > apologies for the initial html message... > > configure:25460: checking how to get verbose linking output from g77 > configure:25471: g77 -c conftest.f >&5 > /tmp/ccK3gsfu.s: Assembler messages: > /tmp/ccK3gsfu.s:8: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:12: Error: suffix or operands invalid for `push' > /tmp/ccK3gsfu.s:13: Error: suffix or operands invalid for `push' > configure:25477: $? = 1 > configure: failed program was: > | program main > | > | end > configure:25556: WARNING: compilation failed > configure:25562: result: > configure:25564: checking for Fortran libraries of g77 > configure:25585: g77 -o conftest -L/usr/local/lib conftest.f >&5 > /tmp/cclyaHyt.s: Assembler messages: > /tmp/cclyaHyt.s:8: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:12: Error: suffix or operands invalid for `push' > /tmp/cclyaHyt.s:13: Error: suffix or operands invalid for `push' > configure:25746: result: > configure:25785: checking for dummy main to link with Fortran libraries > configure:25824: gcc -o conftest -g -O2 -I/usr/local/include > -L/usr/local/lib co > nftest.c -ldl -lm >&5 > configure:25830: $? = 0 > configure:25834: test -z > || test ! -s conftest.err > configure:25837: $? = 0 > configure:25840: test -s conftest > configure:25843: $? = 0 > configure:25921: result: none > configure:25958: checking for Fortran name-mangling scheme > configure:25972: g77 -c conftest.f >&5 > /tmp/ccpZMdHB.s: Assembler messages: > /tmp/ccpZMdHB.s:6: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:8: Error: suffix or operands invalid for `pop' > /tmp/ccpZMdHB.s:14: Error: suffix or operands invalid for `push' > /tmp/ccpZMdHB.s:16: Error: suffix or operands invalid for `pop' > configure:25978: $? = 1 > configure: failed program was: > | subroutine foobar() > | return > | end > | subroutine foo_bar() > | return > | end > configure:26186: error: cannot compile a simple Fortran program > See `config.log' for more details. > > > > > -Original Message- > From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 09, 2005 2:08 PM > To: Dale Ryon Wilhelm > Cc: r-devel@stat.math.ethz.ch > Subject: Re: [Rd] install issue | suse 9.2 > > It says > > > See `config.log' for more details > > Please look there and extract the information (and see the comment about > > HTML mail below). > > > On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: > > > i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run > > configure, i get the following error: > > > > > > > > checking how to get verbose linking output from g77... configure: > > WARNING: compilation failed > > > > > > > > checking for Fortran libraries of g77... > > > > checking for dummy main to link with Fortran libraries... none > > > > checking for Fortran name-mangling scheme... configure: error: cannot > > compile a simple Fortran program > > > > See `config.log' for more details > > > > > > > > anybody know why i am getting this error? g77 is installed correctly > and > > working properly... > > > > > > > > > > > > -<0>- > > > > d. ryon wilhelm > > > > EVNINE-VAUGHAN ASSOCIATES, INC. > > > > 415.835.7855 > > > > > > > > > > [[alternative HTML version deleted]] > > The posting guide does ask you not to send HTML mail. > > > -- > Brian D. Ripley, [EMAIL PROTECTED] > Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ > University of Oxford, Tel: +44 1865 272861 (self) > 1 South Parks Road, +44 1865 272866 (PA) > Oxford OX1 3TG, UKFax: +44 1865 272595 > > __ > R-devel@stat.math.ethz.ch mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > -- O__ Peter Dalgaard Blegdamsvej 3 c/ /'_ --- Dept. of Biostatistics 2200 Cph. N (*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918 ~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] install issue | suse 9.2
Your assembler and your g77 don't match. What platform is this, and is the g77 for the right platform (e.g. not x86_64 on ix86)? We can only guess why, but your Fortran compiler is not working correctly and you need to seek SuSE-specific help. On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: looked thru config.log and got the following ( see below )... not knowing much about fortran, this doesn't make much sense to me... my apologies for the initial html message... configure:25460: checking how to get verbose linking output from g77 configure:25471: g77 -c conftest.f >&5 /tmp/ccK3gsfu.s: Assembler messages: /tmp/ccK3gsfu.s:8: Error: suffix or operands invalid for `push' /tmp/ccK3gsfu.s:12: Error: suffix or operands invalid for `push' /tmp/ccK3gsfu.s:13: Error: suffix or operands invalid for `push' configure:25477: $? = 1 configure: failed program was: | program main | | end configure:25556: WARNING: compilation failed configure:25562: result: configure:25564: checking for Fortran libraries of g77 configure:25585: g77 -o conftest -L/usr/local/lib conftest.f >&5 /tmp/cclyaHyt.s: Assembler messages: /tmp/cclyaHyt.s:8: Error: suffix or operands invalid for `push' /tmp/cclyaHyt.s:12: Error: suffix or operands invalid for `push' /tmp/cclyaHyt.s:13: Error: suffix or operands invalid for `push' configure:25746: result: configure:25785: checking for dummy main to link with Fortran libraries configure:25824: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib co nftest.c -ldl -lm >&5 configure:25830: $? = 0 configure:25834: test -z || test ! -s conftest.err configure:25837: $? = 0 configure:25840: test -s conftest configure:25843: $? = 0 configure:25921: result: none configure:25958: checking for Fortran name-mangling scheme configure:25972: g77 -c conftest.f >&5 /tmp/ccpZMdHB.s: Assembler messages: /tmp/ccpZMdHB.s:6: Error: suffix or operands invalid for `push' /tmp/ccpZMdHB.s:8: Error: suffix or operands invalid for `pop' /tmp/ccpZMdHB.s:14: Error: suffix or operands invalid for `push' /tmp/ccpZMdHB.s:16: Error: suffix or operands invalid for `pop' configure:25978: $? = 1 configure: failed program was: | subroutine foobar() | return | end | subroutine foo_bar() | return | end configure:26186: error: cannot compile a simple Fortran program See `config.log' for more details. -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:08 PM To: Dale Ryon Wilhelm Cc: r-devel@stat.math.ethz.ch Subject: Re: [Rd] install issue | suse 9.2 It says See `config.log' for more details Please look there and extract the information (and see the comment about HTML mail below). On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run configure, i get the following error: checking how to get verbose linking output from g77... configure: WARNING: compilation failed checking for Fortran libraries of g77... checking for dummy main to link with Fortran libraries... none checking for Fortran name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details anybody know why i am getting this error? g77 is installed correctly and working properly... -<0>- d. ryon wilhelm EVNINE-VAUGHAN ASSOCIATES, INC. 415.835.7855 [[alternative HTML version deleted]] The posting guide does ask you not to send HTML mail. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
RE: [Rd] install issue | suse 9.2
looked thru config.log and got the following ( see below )... not knowing much about fortran, this doesn't make much sense to me... my apologies for the initial html message... configure:25460: checking how to get verbose linking output from g77 configure:25471: g77 -c conftest.f >&5 /tmp/ccK3gsfu.s: Assembler messages: /tmp/ccK3gsfu.s:8: Error: suffix or operands invalid for `push' /tmp/ccK3gsfu.s:12: Error: suffix or operands invalid for `push' /tmp/ccK3gsfu.s:13: Error: suffix or operands invalid for `push' configure:25477: $? = 1 configure: failed program was: | program main | | end configure:25556: WARNING: compilation failed configure:25562: result: configure:25564: checking for Fortran libraries of g77 configure:25585: g77 -o conftest -L/usr/local/lib conftest.f >&5 /tmp/cclyaHyt.s: Assembler messages: /tmp/cclyaHyt.s:8: Error: suffix or operands invalid for `push' /tmp/cclyaHyt.s:12: Error: suffix or operands invalid for `push' /tmp/cclyaHyt.s:13: Error: suffix or operands invalid for `push' configure:25746: result: configure:25785: checking for dummy main to link with Fortran libraries configure:25824: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib co nftest.c -ldl -lm >&5 configure:25830: $? = 0 configure:25834: test -z || test ! -s conftest.err configure:25837: $? = 0 configure:25840: test -s conftest configure:25843: $? = 0 configure:25921: result: none configure:25958: checking for Fortran name-mangling scheme configure:25972: g77 -c conftest.f >&5 /tmp/ccpZMdHB.s: Assembler messages: /tmp/ccpZMdHB.s:6: Error: suffix or operands invalid for `push' /tmp/ccpZMdHB.s:8: Error: suffix or operands invalid for `pop' /tmp/ccpZMdHB.s:14: Error: suffix or operands invalid for `push' /tmp/ccpZMdHB.s:16: Error: suffix or operands invalid for `pop' configure:25978: $? = 1 configure: failed program was: | subroutine foobar() | return | end | subroutine foo_bar() | return | end configure:26186: error: cannot compile a simple Fortran program See `config.log' for more details. -Original Message- From: Prof Brian Ripley [mailto:[EMAIL PROTECTED] Sent: Wednesday, February 09, 2005 2:08 PM To: Dale Ryon Wilhelm Cc: r-devel@stat.math.ethz.ch Subject: Re: [Rd] install issue | suse 9.2 It says > See `config.log' for more details Please look there and extract the information (and see the comment about HTML mail below). On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: > i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run > configure, i get the following error: > > > > checking how to get verbose linking output from g77... configure: > WARNING: compilation failed > > > > checking for Fortran libraries of g77... > > checking for dummy main to link with Fortran libraries... none > > checking for Fortran name-mangling scheme... configure: error: cannot > compile a simple Fortran program > > See `config.log' for more details > > > > anybody know why i am getting this error? g77 is installed correctly and > working properly... > > > > > > -<0>- > > d. ryon wilhelm > > EVNINE-VAUGHAN ASSOCIATES, INC. > > 415.835.7855 > > > > > [[alternative HTML version deleted]] The posting guide does ask you not to send HTML mail. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Environment with no parent?
On 09 Feb 2005 00:29:37 +0100, Peter Dalgaard
<[EMAIL PROTECTED]> wrote :
>Duncan Murdoch <[EMAIL PROTECTED]> writes:
>
>> >(a) efficiency. Is it expensive no longer to have the base functions
>> >bound directly to their symbol? (My gut feeling is that with suitable
>> >hashing and cacheing, the penalty is minimal.)
>> >
>> >(b) you can *only* use get and simple variable retrieval in a non-base
>> >environment with a NULL parent (eval(x <- 1, envir=foo) would give
>> >'couldn't find function "<-"' or so). This could cause some confusion.
>>
>> (b) means that the default should stay the way it is, but I think
>> there should be a way to set up a truly empty environment. We have a
>> fair number of cases where envir=NULL is used, so it would be safest
>> to make it a different value -- even if NULL is the obvious value for
>> an empty environment.
>
>Not necessarily. It just means that you should think about it. It is
>not a given that envir=NULL really means what the author expected, and
>fixing them up to read envir=.BaseEnv is probably quite doable.
For the benefit of the archives:
Setting the NULL environment to contain nothing is nontrivial; even
creating a new magic environment that appeared to be empty would
require a surprising number of low-level changes. So, rather than
take this on, I've decided on this R-only solution to my problem: a
version of exists() that treats NULL as if it were empty:
# Modified exists function: like exists(x, envir, inherits = TRUE),
except that a
# NULL parent is considered empty
myexists <- function(x, envir) {
result <- FALSE
while (!result && !is.null(envir)) {
result <- exists(x, envir=envir, inherits = FALSE)
envir <- parent.env(envir)
}
result
}
Duncan Murdoch
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] install issue | suse 9.2
It says See `config.log' for more details Please look there and extract the information (and see the comment about HTML mail below). On Wed, 9 Feb 2005, Dale Ryon Wilhelm wrote: i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run configure, i get the following error: checking how to get verbose linking output from g77... configure: WARNING: compilation failed checking for Fortran libraries of g77... checking for dummy main to link with Fortran libraries... none checking for Fortran name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details anybody know why i am getting this error? g77 is installed correctly and working properly... -<0>- d. ryon wilhelm EVNINE-VAUGHAN ASSOCIATES, INC. 415.835.7855 [[alternative HTML version deleted]] The posting guide does ask you not to send HTML mail. -- Brian D. Ripley, [EMAIL PROTECTED] Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UKFax: +44 1865 272595 __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] install issue | suse 9.2
hello all... i am trying to install r v2.0.1 on my suse 9.2 pro box... when i run configure, i get the following error: checking how to get verbose linking output from g77... configure: WARNING: compilation failed checking for Fortran libraries of g77... checking for dummy main to link with Fortran libraries... none checking for Fortran name-mangling scheme... configure: error: cannot compile a simple Fortran program See `config.log' for more details anybody know why i am getting this error? g77 is installed correctly and working properly... -<0>- d. ryon wilhelm EVNINE-VAUGHAN ASSOCIATES, INC. 415.835.7855 [[alternative HTML version deleted]] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Compiler-specific flags with PKG_CFLAGS
On Wed, 9 Feb 2005, Kurt Hornik wrote:
> > Paul Roebuck writes:
>
> > On Wed, 9 Feb 2005, Kurt Hornik wrote:
> >> > Paul Roebuck writes:
> >>
> >> > On Tue, 8 Feb 2005, Kurt Hornik wrote:
> >> >> This concerns the packages...
> >> >> for which current versions of r-devel now report problems with
> >> >> non-portable compilation flags in Makevars[.in] files:
> >> >>
> >> >> Problems in package 'rwt':
> >> >> Non-portable flags in variable 'PKG_CFLAGS':
> >> >> -Wall -ansi -pedantic
> >> >>
> >> >> These flags are mostly GCC specific and not portable.
> >> >> (Do not assume that any -Ox will work.)
> >> >>
> >> >> Can you please fix these problems, and provide an update of your
> >> >> package?
> >>
> >> > It has been on my todo list since Ripley brought it up
> >> > several weeks ago in r-devel but hadn't exactly figured
> >> > out how to package it as such. Someone have an example
> >> > of how to add compiler flags for GCC when it is being
> >> > used and otherwise not? I'm assuming Makevars isn't being
> >> > passed through cpp and I can't just use #ifdef. In this case,
> >> > I could just leave them out but I hate to lose the warnings
> >> > for development. Using 'configure' is probably the only
> >> > option but really didn't want to use it for just stricter
> >> > error checking during compilation.
> >>
> >> I think the simplest way to achieve this is to configure R
> >> locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but
> >> leave the corresponding PKG_CFLAGS etc variables in package
> >> src/Makevars alone.
>
> > I can do that for workstations which I have admin priviledges
> > and have a private version of R; how about the ones I don't?
>
> It depends: R-exts says
>
> Flags which are set in file `etc/Makeconf' can be overridden by
> the environment variable `MAKEFLAGS' (at least for systems using
> GNU `make'), as in (Bourne shell syntax)
>
>MAKEFLAGS="CFLAGS=-O3" R CMD SHLIB *.c
>
> or by using a `Makefile'.
>
> so if you have GNU Make, you can actually set MAKEFLAGS accordingly in
> your R_ENVIRON file.
>
> What you can also try is to have a make (Sys.getenv("MAKE")) script in
> your PATH which does something like
>
> /path/to/real/make $* CFLAGS=-O3
>
> (but I am never sure whether command line vars override the ones in
> files?)
Thanks for the suggestions. Setting the environment prior to running
R CMD is not practical for me, typing-wise. I guess if made my
.Renviron file architecture-specific it might work, but that seems
overkill. That leaves writing a makefile, a script to rename
'src/Makevars' as 'src/Makevars_d' prior to upload, or adding the
file to my .Rbuildignore as I only really need to see the additional
warnings when running R CMD check.
> >> R 2.1.0 will provide a portable way of overriding the configured
> >> "site" compilation flags via user-level ~/.R/Makevars files.
>
> > Will this also cover how to merge or augment compilation
> > flags with the site-specified ones? And how will it handle
> > the situation where one's home directory is NFS mounted
> > across several architectures? There will be a variable to
> > override the default location, right?.
>
> No but there is
>
> ~/.R/Makeconf-$platform
>
> where $platform is the same as in R_PLATFORM, which is looked for ahead
> of ~/.R/Makeconf. (That should be better than having an R_MAKECONF env
> var.)
>
> Btw, I assume that if all Makes are GNU Make you might actually be able
> to conditionalize inside.
GNU make availability is unlikely at best. And I don't think
this approach is going to be much help for me. I only wanted
to augment the compiler settings for the packages I'm developing,
not override the ones for the R itself. You've managed to make
me think a package configure script might not be so hard after
all :)
Thanks for your insight.
--
SIGSIG -- signature too long (core dumped)
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Please read.
Hello! I have something to share with you today - something that has made my difficult life easy and exciting. Click this 7-minute flash presentation and find out how this simple thing can change people's lives: http://yourfamilygoal.ws/show Make sure to turn on your speakers or put on your headphone.. I will be very glad to share with you my story. Don't hesitate to write me back for any question or help you need. All the best, Julia __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
On Wed, 9 Feb 2005 17:14:08 +0100, Kurt Hornik
<[EMAIL PROTECTED]> wrote:
> > Peter Dalgaard writes:
>
> > Kurt Hornik <[EMAIL PROTECTED]> writes:
> >> > A J Rossini writes:
> >>
> >> > But I don't see a problem with "package("package")", though I'm sure
> >> > I'm missing something.
> >>
> >> package() [sic] might be the creator for package objects, provided we
> >> can decide on what they are (and what kind of packages [source,
> >> installed, ...] they are used for).
> >>
> >> usePackage() or use_package() otoh would indicate to "use" a package
> >> (i.e., load and attach it). The tricky part is deciding about the
> >> interface (e.g., finally disallowing non-standard evaluation as it is a
> >> programmer's nightmare) and what it should return. And that is work in
> >> progress ...
>
> > Any information on the rate...? (I still vote for usepackage() btw.)
>
> Why not use(), as the GCD?
Excellent suggestion, Kurt.
> > It would be good if we could at least have an outline of the intended
> > functionality and see if we could forge ahead and get a preliminary
> > version done in time for 2.1.x
>
> Help us out.
>
> use <- function(package, pos = 2, lib.loc, ...)
use <- function(packageName,pos=2,library, ...)
I could argue that "library" and "lib.loc" try to describe the same
thing (a name and its pointer).
> where 'package' is either a character string or some sort of package
> object/reference, to be specified later. And 'lib.loc' needs to have a
> different name if we rename libraries into stores or whatever ...
I think package ought to be a character string. Unless you want to
combine the packageName and libraryLocation into some form of data
object, or packageName, libraryLocation, and an environment containing
the erstwhile contents?
> What should this return? Currently, 'library' returns the list of
> loaded (or available) packages by default, as a list of names, which is
> not good enough. So we need something like the DLLInfoList returned by
> getLoadedDLLs() (and the docs should actually mention that class), or
> something usable by the package management tools ... and this is under
> redesign as well.
Perhaps "use" should incorporate "require" functionality, i.e. TRUE or
FALSE depending on whether you can use it after the "use" function
call.
>
> But why should this really return info on all loaded/attached packages?
> An alternative might be just returning the package meta-data in some
> form. Or nothing, which would fit into the idea that it really does
> nothing apart from loading and attaching a package.
I like "libraryContents()" or similar to figure out loaded and
potentially loadable packages.
> (And maybe a condition object inheriting from packageLoadAndAttachError
> in case of failure? :-))
Yes. whatever.
--
best,
-tony
"Commit early,commit often, and commit in a repository from which we can easily
roll-back your mistakes" (AJR, 4Jan05).
A.J. Rossini
[EMAIL PROTECTED]
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Please read.
Hello! I have something to share with you today - something that has made my difficult life easy and exciting. Click this 7-minute flash presentation and find out how this simple thing can change people's lives: http://yourfamilygoal.ws/show Make sure to turn on your speakers or put on your headphone.. I will be very glad to share with you my story. Don't hesitate to write me back for any question or help you need. All the best, Julia __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Compiler-specific flags with PKG_CFLAGS
On Feb 9, 2005, at 12:21 PM, Paul Roebuck wrote: On Wed, 9 Feb 2005, Kurt Hornik wrote: I think the simplest way to achieve this is to configure R locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but leave the corresponding PKG_CFLAGS etc variables in package src/Makevars alone. I can do that for workstations which I have admin priviledges and have a private version of R; how about the ones I don't? I don't get your point - if you are not admin and don't use your own R version, how do you expect to change behavior of the R you don't have write access to? You can't, as admin doesn't want you to. This still doesn't prevent you from compiling the package for yourself in your home, including any flags you like. R allows you to change whatever you like for the package you compile. Adding such flags as above in the package itself doesn't make any sense IMHO, as you should expect that whatever flags R was compiled with were specifically provided to steer optimizations etc. There are platform/compiler version combinations where -O2 breaks numerical computations, so overriding this for your package will override a choice which was done deliberately and you're not even aware of. In addition -Ox may have been specified already, so you may in fact downgrade the optimizations. At the time of compilation of the package the user is free to override any flags, so he can do so if he knows what he's doing. The current approach is good at preventing the user from doing bad things by default and producing consistent code. What Kurt mentioned was just a way to reduce typing effort (and achieve more consistency) when specifying flags for packages you compile for yourself - you're still responsible for the content of the files you put there, so it's up to you to be aware of the issues you mentioned - R can't do that for you. You get what you tell R to do - there is no automatic protection against misuse ;). Cheers, Simon __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Compiler-specific flags with PKG_CFLAGS
> Paul Roebuck writes:
> On Wed, 9 Feb 2005, Kurt Hornik wrote:
>> > Paul Roebuck writes:
>>
>> > On Tue, 8 Feb 2005, Kurt Hornik wrote:
>> >> This concerns the packages...
>> >> for which current versions of r-devel now report problems with
>> >> non-portable compilation flags in Makevars[.in] files:
>> >>
>> >> Problems in package 'rwt':
>> >> Non-portable flags in variable 'PKG_CFLAGS':
>> >> -Wall -ansi -pedantic
>> >>
>> >> These flags are mostly GCC specific and not portable.
>> >> (Do not assume that any -Ox will work.)
>> >>
>> >> Can you please fix these problems, and provide an update of your
>> >> package?
>>
>> > It has been on my todo list since Ripley brought it up
>> > several weeks ago in r-devel but hadn't exactly figured
>> > out how to package it as such. Someone have an example
>> > of how to add compiler flags for GCC when it is being
>> > used and otherwise not? I'm assuming Makevars isn't being
>> > passed through cpp and I can't just use #ifdef. In this case,
>> > I could just leave them out but I hate to lose the warnings
>> > for development. Using 'configure' is probably the only
>> > option but really didn't want to use it for just stricter
>> > error checking during compilation.
>>
>> I think the simplest way to achieve this is to configure R
>> locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but
>> leave the corresponding PKG_CFLAGS etc variables in package
>> src/Makevars alone.
> I can do that for workstations which I have admin priviledges
> and have a private version of R; how about the ones I don't?
It depends: R-exts says
Flags which are set in file `etc/Makeconf' can be overridden by
the environment variable `MAKEFLAGS' (at least for systems using
GNU `make'), as in (Bourne shell syntax)
MAKEFLAGS="CFLAGS=-O3" R CMD SHLIB *.c
or by using a `Makefile'.
so if you have GNU Make, you can actually set MAKEFLAGS accordingly in
your R_ENVIRON file.
What you can also try is to have a make (Sys.getenv("MAKE")) script in
your PATH which does something like
/path/to/real/make $* CFLAGS=-O3
(but I am never sure whether command line vars override the ones in
files?)
>> R 2.1.0 will provide a portable way of overriding the configured
>> "site" compilation flags via user-level ~/.R/Makevars files.
> Will this also cover how to merge or augment compilation
> flags with the site-specified ones? And how will it handle
> the situation where one's home directory is NFS mounted
> across several architectures? There will be a variable to
> override the default location, right?.
No but there is
~/.R/Makeconf-$platform
where $platform is the same as in R_PLATFORM, which is looked for ahead
of ~/.R/Makeconf. (That should be better than having an R_MAKECONF env
var.)
Btw, I assume that if all Makes are GNU Make you might actually be able
to conditionalize inside.
Best
-k
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: Compiler-specific flags with PKG_CFLAGS
On Wed, 9 Feb 2005, Kurt Hornik wrote: > > Paul Roebuck writes: > > > On Tue, 8 Feb 2005, Kurt Hornik wrote: > >> This concerns the packages... > >> for which current versions of r-devel now report problems with > >> non-portable compilation flags in Makevars[.in] files: > >> > >> Problems in package 'rwt': > >> Non-portable flags in variable 'PKG_CFLAGS': > >> -Wall -ansi -pedantic > >> > >> These flags are mostly GCC specific and not portable. > >> (Do not assume that any -Ox will work.) > >> > >> Can you please fix these problems, and provide an update of your > >> package? > > > It has been on my todo list since Ripley brought it up > > several weeks ago in r-devel but hadn't exactly figured > > out how to package it as such. Someone have an example > > of how to add compiler flags for GCC when it is being > > used and otherwise not? I'm assuming Makevars isn't being > > passed through cpp and I can't just use #ifdef. In this case, > > I could just leave them out but I hate to lose the warnings > > for development. Using 'configure' is probably the only > > option but really didn't want to use it for just stricter > > error checking during compilation. > > I think the simplest way to achieve this is to configure R > locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but > leave the corresponding PKG_CFLAGS etc variables in package > src/Makevars alone. I can do that for workstations which I have admin priviledges and have a private version of R; how about the ones I don't? > R 2.1.0 will provide a portable way of overriding the configured > "site" compilation flags via user-level ~/.R/Makevars files. Will this also cover how to merge or augment compilation flags with the site-specified ones? And how will it handle the situation where one's home directory is NFS mounted across several architectures? There will be a variable to override the default location, right?. -- SIGSIG -- signature too long (core dumped) __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Re: Compiler-specific flags with PKG_CFLAGS
> Paul Roebuck writes: > On Tue, 8 Feb 2005, Kurt Hornik wrote: >> This concerns the packages... >> for which current versions of r-devel now report problems with >> non-portable compilation flags in Makevars[.in] files: >> >> Problems in package 'rwt': >> Non-portable flags in variable 'PKG_CFLAGS': >> -Wall -ansi -pedantic >> >> These flags are mostly GCC specific and not portable. >> (Do not assume that any -Ox will work.) >> >> Can you please fix these problems, and provide an update of your >> package? > It has been on my todo list since Ripley brought it up > several weeks ago in r-devel but hadn't exactly figured > out how to package it as such. Someone have an example > of how to add compiler flags for GCC when it is being > used and otherwise not? I'm assuming Makevars isn't being > passed through cpp and I can't just use #ifdef. In this case, > I could just leave them out but I hate to lose the warnings > for development. Using 'configure' is probably the only > option but really didn't want to use it for just stricter > error checking during compilation. I think the simplest way to achieve this is to configure R locally (for yourself) with CFLAGS="-O2 -Wall -pedantic" but leave the corresponding PKG_CFLAGS etc variables in package src/Makevars alone. R 2.1.0 will provide a portable way of overriding the configured "site" compilation flags via user-level ~/.R/Makevars files. > One other question - if package update happens for something > like the above but with no change to contents of package, > should the version number be incremented? Yes. -k __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Compiler-specific flags with PKG_CFLAGS
On Tue, 8 Feb 2005, Kurt Hornik wrote: > This concerns the packages... > for which current versions of r-devel now report problems with > non-portable compilation flags in Makevars[.in] files: > >Problems in package 'rwt': >Non-portable flags in variable 'PKG_CFLAGS': > -Wall -ansi -pedantic > > These flags are mostly GCC specific and not portable. > (Do not assume that any -Ox will work.) > > Can you please fix these problems, and provide an update of your > package? It has been on my todo list since Ripley brought it up several weeks ago in r-devel but hadn't exactly figured out how to package it as such. Someone have an example of how to add compiler flags for GCC when it is being used and otherwise not? I'm assuming Makevars isn't being passed through cpp and I can't just use #ifdef. In this case, I could just leave them out but I hate to lose the warnings for development. Using 'configure' is probably the only option but really didn't want to use it for just stricter error checking during compilation. One other question - if package update happens for something like the above but with no change to contents of package, should the version number be incremented? -- SIGSIG -- signature too long (core dumped) __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
> Peter Dalgaard writes:
> Kurt Hornik <[EMAIL PROTECTED]> writes:
>> > A J Rossini writes:
>>
>> > But I don't see a problem with "package("package")", though I'm sure
>> > I'm missing something.
>>
>> package() [sic] might be the creator for package objects, provided we
>> can decide on what they are (and what kind of packages [source,
>> installed, ...] they are used for).
>>
>> usePackage() or use_package() otoh would indicate to "use" a package
>> (i.e., load and attach it). The tricky part is deciding about the
>> interface (e.g., finally disallowing non-standard evaluation as it is a
>> programmer's nightmare) and what it should return. And that is work in
>> progress ...
> Any information on the rate...? (I still vote for usepackage() btw.)
Why not use(), as the GCD?
> It would be good if we could at least have an outline of the intended
> functionality and see if we could forge ahead and get a preliminary
> version done in time for 2.1.x
Help us out.
use <- function(package, pos = 2, lib.loc, ...)
where 'package' is either a character string or some sort of package
object/reference, to be specified later. And 'lib.loc' needs to have a
different name if we rename libraries into stores or whatever ...
What should this return? Currently, 'library' returns the list of
loaded (or available) packages by default, as a list of names, which is
not good enough. So we need something like the DLLInfoList returned by
getLoadedDLLs() (and the docs should actually mention that class), or
something usable by the package management tools ... and this is under
redesign as well.
But why should this really return info on all loaded/attached packages?
An alternative might be just returning the package meta-data in some
form. Or nothing, which would fit into the idea that it really does
nothing apart from loading and attaching a package.
(And maybe a condition object inheriting from packageLoadAndAttachError
in case of failure? :-))
-k
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc ..)
Kurt Hornik <[EMAIL PROTECTED]> writes:
> > A J Rossini writes:
>
> > But I don't see a problem with "package("package")", though I'm sure
> > I'm missing something.
>
> package() [sic] might be the creator for package objects, provided we
> can decide on what they are (and what kind of packages [source,
> installed, ...] they are used for).
>
> usePackage() or use_package() otoh would indicate to "use" a package
> (i.e., load and attach it). The tricky part is deciding about the
> interface (e.g., finally disallowing non-standard evaluation as it is a
> programmer's nightmare) and what it should return. And that is work in
> progress ...
Any information on the rate...? (I still vote for usepackage() btw.)
It would be good if we could at least have an outline of the intended
functionality and see if we could forge ahead and get a preliminary
version done in time for 2.1.x
> Even if we don't like the current semantics, the *name* of library() in
> itself should not be a problem. After all, calling summary() does not
> imply that your primary argument is a summary, so why should calling
> library() imply that its primary argument is a "library"?
More likely it would imply that the *result* is a library...
Anyway, it was introduced at a time where we considered it important
to be "prototype compatible" as long as there was no good reason not
to. With 20-20 hindsight, we could probably have afforded to think up
a better name.
> > It really would end this constant confusion and save various folks
> > approx 15 minutes/week in knee-jerk responses, eh?
>
> Afaic, one of the issues is that it seems common practice to refer to
> collections of code as "libraries" or "packages", and we're trying to
> use these rather general-purpose terms in a very precise meaning, and
> obviously not very successful, in particular because the use of
> "library" is highly non-standard. One idea might be to replace the
> "library" by something else like ... "a place where R knows where to
> find packages" ... hmm, now that's too long, so ...
"store", or "depot" springs to mind. The latter might cause baz to go
postal, though...
--
O__ Peter Dalgaard Blegdamsvej 3
c/ /'_ --- Dept. of Biostatistics 2200 Cph. N
(*) \(*) -- University of Copenhagen Denmark Ph: (+45) 35327918
~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Please read.
Hello! I have something to share with you today - something that has made my difficult life easy and exciting. Click this 7-minute flash presentation and find out how this simple thing can change people's lives: http://yourfamilygoal.ws/show Make sure to turn on your speakers or put on your headphone.. I will be very glad to share with you my story. Don't hesitate to write me back for any question or help you need. All the best, Julia __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] link to an alias in another package
In summary
In some documentation for a package I am working on I have
\code{\link[stats]{varimax}}
\code{\link[stats]{promax}}
The link to varimax works, but not the one to promax. Promax is an
alias under \name{varimax}. ...
\code(\link[stats:varimax]{promax}}
works but will probably break if promax is ever moved to its own Rd
file. (From the discussion there is probably not a better general solution.)
\code(\link{promax}}
works because stats is always installed, but is not a general solution
because I have other cases where the package may not be installed.
\code(\link[stats:promax]{varimax}}
which might be another (but presumably mistaken) interpretation of the
Writing R Extensions documentation
\link[pkg:bar]{foo} to link to the package pkg with topic (file?)
foo and bar respectively.
does not work and also displays "varimax" in the text (which is not what
I want).
Paul Gilbert
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries
or libraries being postOffices, with packages being packages, In my recent experience, a post office is somewhere that packages are *lost* rather than found :) Baz [I had a card from the PO saying they'd tried to deliver a package but I was out, I went to the depot and they couldn't find it...] __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Linux: /usr/shar/doc/R-2.0.1/*.pdf all have bad fonts (PR#7677)
I have forwarded the message to Matthew Cox, who built the RPMS for Red Hat Enterprise Linux. But if you get the same problem building from source then it must be a platform-specific problem and you should probably get support from Red Hat. Martyn On Wed, 2005-02-09 at 08:32 +0100, [EMAIL PROTECTED] wrote: > Please report this to the RPM provider: it is not true of R in general. > This is the R bug repository, not the CRAN error address. > > On Wed, 9 Feb 2005 [EMAIL PROTECTED] wrote: > > > Full_Name: Bruce Foster > > Version: 2.0.1 > > OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 4) > > Submission from: (NULL) (129.105.110.38) > > > > > > All of the pdf files in /usr/share/doc/R-2.0.1 from the CRAN RedHat RPM have > > invalid fonts. A build from source yields the same problem. > > > > [EMAIL PROTECTED] R-2.0.1]# ll *.pdf > > -rw-r--r--1 root root 259886 Nov 19 10:50 R-FAQ.pdf > > -rw-r--r--1 root root 127067 Nov 19 10:50 R-admin.pdf > > -rw-r--r--1 root root 143761 Nov 19 10:50 R-data.pdf > > -rw-r--r--1 root root 374269 Nov 19 10:50 R-exts.pdf > > -rw-r--r--1 root root 435252 Nov 19 10:50 R-intro.pdf > > -rw-r--r--1 root root 268142 Nov 19 10:50 R-lang.pdf > > > > The files are unreadable with xpdf and acroread, and pdf2ps shows this: > > [EMAIL PROTECTED] R-2.0.1]# pdf2ps R-admin.pdf > > Error: /invalidfont in /F72 > > Operand stack: > > --dict:5/5(L)-- F72 20.659 > > Execution stack: > > %interp_exit .runexec2 --nostringval-- --nostringval-- > > --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- > > --nostringval-- false 1 %stopped_push 1 3 %oparray_pop 1 3 > > %oparray_pop --nostringval-- 2 1 29 --nostringval-- > > %for_pos_int_continue --nostringval-- --nostringval-- --nostringval-- > > --nostringval-- %array_continue --nostringval-- false 1 > > %stopped_push > > --nostringval-- %loop_continue --nostringval-- --nostringval-- > > --nostringval-- > > Dictionary stack: > > --dict:1051/1123(ro)(G)-- --dict:0/20(G)-- --dict:92/200(L)-- > > --dict:92/200(L)-- --dict:97/127(ro)(G)-- --dict:229/230(ro)(G)-- > > --dict:19/24(L)-- --dict:4/6(L)-- --dict:23/31(L)-- > > Current allocation mode is local > > GNU Ghostscript 7.05: Unrecoverable error, exit code 1 > > > > __ > > R-devel@stat.math.ethz.ch mailing list > > https://stat.ethz.ch/mailman/listinfo/r-devel > > > > > __ R-devel@stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Re: Packages and Libraries (was: Re: lme4 "package" etc
On Tue, 8 Feb 2005, Jeff Gentry wrote:
On Wed, 9 Feb 2005, Achim Zeileis wrote:
A *library* is a directory in which you can find R *packages* (just as
in real life you can find books in a library) and with
library("foo", lib.loc = "/path/to/bar")
you want to get the package (book) "foo" from the library "bar" located
at "/path/to/bar".
Out of pure curiosity, could anyone tell me the historical reason that
library() is used here? Does it tie in to the S ancestry of R?
It's been the way S does it since ca 1987 (when the Blue Book version of S
first made S extensible via functions as today). See the 1988 Blue Book
p.58. The only difference (as I have already noted) is that the S library
has `sections' not `packages'.
--
Brian D. Ripley, [EMAIL PROTECTED]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
