[Rd] How do I bundle R with my Win32 Application?

2009-11-20 Thread Abhijit Bera
Hi

I have managed to link R with my VC++ Project by generating a lib file from
R.dll using dumpbin.

Reference:
http://www.coderetard.com/2009/01/21/generate-a-lib-from-a-dll-with-visual-studio/

My Win32 front end works perfectly with R provided R, my package and the
dependencies of my package are installed on the target system.

Now I want to bundle R with my application. How do I go about doing this?
Simply copying the R files and creating necessary registry entries from my
installer seems to be a way to do it. But what if the user's system already
has R installed? Then how do I ensure that my package and it's dependencies
work without creating conflict with the version numbers?

Regards

Abhijit Bera

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

2009-11-20 Thread Peter Dalgaard

m...@celos.net wrote:

Arrays of POSIXlt dates always return a length of 9.  This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:

  strings <- paste('2009-1-', 1:31, sep='')
  dates <- strptime(strings, format="%Y-%m-%d")

  print(dates)
  #  [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
  #  [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
  # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
  # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
  # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
  # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
  # [31] "2009-01-31"

  print(length(dates))
  # [1] 9
  
  str(dates)

  # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" 
...

  print(dates[20])
  # [1] "2009-01-20"

  print(length(dates[20]))
  # [1] 9

I've since realised that POSIXct makes date vectors easier,
but could we also have something like:

  length.POSIXlt <- function(x) { length(x$sec) }

in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?



[You need "wishlist" in the title for this sort of stuff.]

I'd be wary of this. Just the other day we found that identical() broke 
on some objects because a package had length() redefined as a class 
method. I.e. the danger is that something wants to use length() with its 
original low-level interpretation.




Thanks,
Mark <><

--

Version:
 platform = i686-pc-linux-gnu
 arch = i686
 os = linux-gnu
 system = i686, linux-gnu
 status = 
 major = 2

 minor = 10.0
 year = 2009
 month = 10
 day = 26
 svn rev = 50208
 language = R
 version.string = R version 2.10.0 (2009-10-26)

Locale:
C

Search Path:
 .GlobalEnv, package:stats, package:graphics, package:grDevices, package:utils, 
package:datasets, package:methods, Autoloads, package:base

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
   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


Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

2009-11-20 Thread Romain Francois

On 11/20/2009 09:54 AM, Peter Dalgaard wrote:


m...@celos.net wrote:

Arrays of POSIXlt dates always return a length of 9. This
is correct (they're really lists of vectors of seconds,
hours, and so forth), but other methods disguise them as
flat vectors, giving superficially surprising behaviour:

strings <- paste('2009-1-', 1:31, sep='')
dates <- strptime(strings, format="%Y-%m-%d")

print(dates)
# [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
# [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
# [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
# [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
# [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
# [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
# [31] "2009-01-31"

print(length(dates))
# [1] 9
str(dates)
# POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03"
"2009-01-04" ...

print(dates[20])
# [1] "2009-01-20"

print(length(dates[20]))
# [1] 9

I've since realised that POSIXct makes date vectors easier,
but could we also have something like:

length.POSIXlt <- function(x) { length(x$sec) }

in datetime.R, to avoid breaking functions (like the
str.POSIXt method) which use length() in this way?



[You need "wishlist" in the title for this sort of stuff.]

I'd be wary of this. Just the other day we found that identical() broke
on some objects because a package had length() redefined as a class
method. I.e. the danger is that something wants to use length() with its
original low-level interpretation.


str is another example

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Suggestion: Clarification in Rd for utils::getAnywhere()

2009-11-20 Thread Henrik Bengtsson
In order to clarify that getAnywhere(str) where str is a character
string object, will look for object with name "str" and not the value
of 'str', I suggest the following Rd updated for utils::getAnywhere():

Update the argument list:

\item{x}{a [literal] character string or name.}

The term 'literal character string' is used in library().

Add to the example code:

str <- "format.dist"
do.call("getAnywhere", list(str))

Alternatively, getAnywhere() should gain an argument 'character.only'
as in library().

/Henrik

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] ISOdate and strptime results are not interoperable (PR#14076)

2009-11-20 Thread mariotomo
Full_Name: Mario Frasca
Version: 2.9.2, 2.10.0, 2.8.1
OS: ubuntu 9.10, Debian sid, MacOSX 10.4
Submission from: (NULL) (194.151.158.193)


The objects being returned by the functions strptime and ISOdate look the same
(to me) but behave differently.  The difference is influenced by the current
timezone of the system.  

> epoch_strptime <- strptime("1970-01-01 00:00:00", "%Y-%m-%d %H:%M:%S",
tz="UTC")
> epoch_isodate <- ISOdate(1970,1,1,0,0,0, tz="UTC")
> epoch_strptime
[1] "1970-01-01 UTC"
> epoch_isodate
[1] "1970-01-01 UTC"
> mode(epoch_strptime)
[1] "list"
> mode(epoch_isodate)
[1] "numeric"
> # the system is currently in timezone CET (Europe/Rome)
> epoch_isodate - epoch_strptime
Time difference of 1 hours
> # using time-admin to move to timezone COT (America/Bogota)
> epoch_isodate - epoch_strptime
Time difference of -5 hours

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

2009-11-20 Thread Mark White
Benilton Carvalho writes:
> I'm no expert on this, but my understanding is that the choice was
> to stick to the definition.
> 
> The help file for length() [1] says:
> 
> "For vectors (including lists) and factors the length is the number
> of elements."
> 
> The help file for POSIXlt [2] (for example) says:
> 
> "Class ?"POSIXlt"? is a named list of vectors representing (...)"
> 
> and then lists the 9 elements (sec / min / hour / mday / mon / year
> / wday / yday / isdst).
> 
> So, by [1] length of POSIXlt objects is 9, because it "is a named
> list of vectors representing (...)".

Thanks, all.  Yes, I'd already read both, and it's obviously
true that a length() of 9 is correct (as I said up-front).

The difficulty is that some functions -- importantly
including "[" -- already have methods which make POSIXlt
behave like a vector.  The documentation for POSIXlt just
says it's a list of 9 elements: it mentions methods for
addition etc, but AFAICT it doesn't say that subsetting won't
behave is "["'s help says for a list-like object.

In the end, "[" sees a different length to "[[" and "$"
here, so a length.POSIXlt() just shuffles the issue around.

Anyhow, I somehow missed there have been other PRs on this,
including discussion on r-devel of "[" and logical vs physical
length() under PR#10507.  I'm sorry for being repetitive.

Mark <><

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

2009-11-20 Thread mark
Benilton Carvalho writes:
> I'm no expert on this, but my understanding is that the choice was
> to stick to the definition.
> 
> The help file for length() [1] says:
> 
> "For vectors (including lists) and factors the length is the number
> of elements."
> 
> The help file for POSIXlt [2] (for example) says:
> 
> "Class ?"POSIXlt"? is a named list of vectors representing (...)"
> 
> and then lists the 9 elements (sec / min / hour / mday / mon / year
> / wday / yday / isdst).
> 
> So, by [1] length of POSIXlt objects is 9, because it "is a named
> list of vectors representing (...)".

Thanks, all.  Yes, I'd already read both, and it's obviously
true that a length() of 9 is correct (as I said up-front).

The difficulty is that some functions -- importantly
including "[" -- already have methods which make POSIXlt
behave like a vector.  The documentation for POSIXlt just
says it's a list of 9 elements: it mentions methods for
addition etc, but AFAICT it doesn't say that subsetting won't
behave is "["'s help says for a list-like object.

In the end, "[" sees a different length to "[[" and "$"
here, so a length.POSIXlt() just shuffles the issue around.

Anyhow, I somehow missed there have been other PRs on this,
including discussion on r-devel of "[" and logical vs physical
length() under PR#10507.  I'm sorry for being repetitive.

Mark <><

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] make fails on R r50499 ( openSuSE 11.0 x86-64)

2009-11-20 Thread Simone Giannerini
Dear all,

I encountered a problem when compiling the source of R patched 2.10.0
r50499 (19-11-2009)
linked to ACML single threaded (4.2.0 or 4.3.0)
OS: openSuSE 11.0 x86-64

make fails when it comes to installing mgcv with the following

[snip]
** R
** inst
** preparing package for lazy loading
Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) :
  non esiste un pacchetto chiamato 'Matrix'
package 'Matrix' does not exist  ## TRANSLATED BY ME
ERROR: lazy loading failed for package ‘mgcv’
* removing ‘/home/giannerini/Desktop/R-patched/library/mgcv’
make[2]: *** [mgcv.ts] Error 1
make[2]: Leaving directory
`/home/giannerini/Desktop/R-patched/src/library/Recommended'
make[1]: *** [recommended-packages] Error 2
make[1]: Leaving directory
`/home/giannerini/Desktop/R-patched/src/library/Recommended'
make: *** [stamp-recommended] Error 2

I think that the source of package Matrix is where it is supposed to
be so that I have no clues.
Compilation and installation on the same machine with both the latest
R devel (2.11.0)  and the following version were successful
> R.version
   _
platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  2
minor  10.0
year   2009
month  10
day26
svn rev50208
language   R
version.string R version 2.10.0 (2009-10-26)

> Sys.getlocale()
[1] 
"LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C"

for the moment we stay with r50208,
any hints appreciated, thanks

regards

Simone

-- 
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] make fails on R r50499 ( openSuSE 11.0 x86-64)

2009-11-20 Thread Prof Brian Ripley
What has happened is that mgcv now depends on Matrix, but the author 
hasn't told us that.  Add to the line in 
src/library/Recommended/Makefile.in so it becomes


mgcv.ts: nlme.ts MASS.ts Matrix.ts

and it should work.

The tarballs will catch up in due course.

On Fri, 20 Nov 2009, Simone Giannerini wrote:


Dear all,

I encountered a problem when compiling the source of R patched 2.10.0
r50499 (19-11-2009)
linked to ACML single threaded (4.2.0 or 4.3.0)
OS: openSuSE 11.0 x86-64

make fails when it comes to installing mgcv with the following

[snip]
** R
** inst
** preparing package for lazy loading
Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) :
 non esiste un pacchetto chiamato 'Matrix'
package 'Matrix' does not exist  ## TRANSLATED BY ME
ERROR: lazy loading failed for package ‘mgcv’
* removing ‘/home/giannerini/Desktop/R-patched/library/mgcv’
make[2]: *** [mgcv.ts] Error 1
make[2]: Leaving directory
`/home/giannerini/Desktop/R-patched/src/library/Recommended'
make[1]: *** [recommended-packages] Error 2
make[1]: Leaving directory
`/home/giannerini/Desktop/R-patched/src/library/Recommended'
make: *** [stamp-recommended] Error 2

I think that the source of package Matrix is where it is supposed to
be so that I have no clues.
Compilation and installation on the same machine with both the latest
R devel (2.11.0)  and the following version were successful

R.version

  _
platform   x86_64-unknown-linux-gnu
arch   x86_64
os linux-gnu
system x86_64, linux-gnu
status
major  2
minor  10.0
year   2009
month  10
day26
svn rev50208
language   R
version.string R version 2.10.0 (2009-10-26)


Sys.getlocale()

[1] 
"LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C"

for the moment we stay with r50208,
any hints appreciated, thanks

regards

Simone

--
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



--
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 fails on R r50499 ( openSuSE 11.0 x86-64)

2009-11-20 Thread Simone Giannerini
Thank you,  now it works

kind regards,

Simone

2009/11/20 Prof Brian Ripley :
> What has happened is that mgcv now depends on Matrix, but the author hasn't
> told us that.  Add to the line in src/library/Recommended/Makefile.in so it
> becomes
>
> mgcv.ts: nlme.ts MASS.ts Matrix.ts
>
> and it should work.
>
> The tarballs will catch up in due course.
>
> On Fri, 20 Nov 2009, Simone Giannerini wrote:
>
>> Dear all,
>>
>> I encountered a problem when compiling the source of R patched 2.10.0
>> r50499 (19-11-2009)
>> linked to ACML single threaded (4.2.0 or 4.3.0)
>> OS: openSuSE 11.0 x86-64
>>
>> make fails when it comes to installing mgcv with the following
>>
>> [snip]
>> ** R
>> ** inst
>> ** preparing package for lazy loading
>> Error in loadNamespace(i[[1L]], c(lib.loc, .libPaths())) :
>>  non esiste un pacchetto chiamato 'Matrix'
>> package 'Matrix' does not exist  ## TRANSLATED BY ME
>> ERROR: lazy loading failed for package ‘mgcv’
>> * removing ‘/home/giannerini/Desktop/R-patched/library/mgcv’
>> make[2]: *** [mgcv.ts] Error 1
>> make[2]: Leaving directory
>> `/home/giannerini/Desktop/R-patched/src/library/Recommended'
>> make[1]: *** [recommended-packages] Error 2
>> make[1]: Leaving directory
>> `/home/giannerini/Desktop/R-patched/src/library/Recommended'
>> make: *** [stamp-recommended] Error 2
>>
>> I think that the source of package Matrix is where it is supposed to
>> be so that I have no clues.
>> Compilation and installation on the same machine with both the latest
>> R devel (2.11.0)  and the following version were successful
>>>
>>> R.version
>>
>>              _
>> platform       x86_64-unknown-linux-gnu
>> arch           x86_64
>> os             linux-gnu
>> system         x86_64, linux-gnu
>> status
>> major          2
>> minor          10.0
>> year           2009
>> month          10
>> day            26
>> svn rev        50208
>> language       R
>> version.string R version 2.10.0 (2009-10-26)
>>
>>> Sys.getlocale()
>>
>> [1]
>> "LC_CTYPE=it_IT.UTF-8;LC_NUMERIC=C;LC_TIME=it_IT.UTF-8;LC_COLLATE=it_IT.UTF-8;LC_MONETARY=C;LC_MESSAGES=it_IT.UTF-8;LC_PAPER=it_IT.UTF-8;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=it_IT.UTF-8;LC_IDENTIFICATION=C"
>>
>> for the moment we stay with r50208,
>> any hints appreciated, thanks
>>
>> regards
>>
>> Simone
>>
>> --
>> __
>>
>> Simone Giannerini
>> Dipartimento di Scienze Statistiche "Paolo Fortunati"
>> Universita' di Bologna
>> Via delle belle arti 41 - 40126  Bologna,  ITALY
>> Tel: +39 051 2098262  Fax: +39 051 232153
>> http://www2.stat.unibo.it/giannerini/
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> --
> 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, UK                Fax:  +44 1865 272595



-- 
__

Simone Giannerini
Dipartimento di Scienze Statistiche "Paolo Fortunati"
Universita' di Bologna
Via delle belle arti 41 - 40126  Bologna,  ITALY
Tel: +39 051 2098262  Fax: +39 051 232153
http://www2.stat.unibo.it/giannerini/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] R Usage Statistics

2009-11-20 Thread Michael Dewey

At 18:47 19/11/2009, Kevin R. Coombes wrote:


Hi,

I got the following comment from the reviewer of a paper (describing 
an algorithm implemented in R) that I submitted to BMC Bioinformatics:


"Finally, which useful for exploratory work and some prototyping, 
neither R nor S-Plus are appropriate environments for deploying user 
applications that would receive much use."


I can certainly respond by pointing out that CRAN contains more than 
2000 packages and Bioconductor contains more than 350. However, does 
anyone have statistics on how often R (and possibly some R packages) 
are downloaded, or on how many people actually use R?


Another point you could make is that BMC supports open access 
publishing so that anyone in the world with an Internet connection 
can download the results of research free gratis and for nothing, 
something especially valuable to residents of resource poor 
countries. Consistent with that would be support for the use of 
methods which anyone can reproduce without having to buy a licence.




Thanks,
   Kevin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Michael Dewey
http://www.aghmed.fsnet.co.uk

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Surprising length() of POSIXlt vector (PR#14073)

2009-11-20 Thread maechler
> "PD" == Peter Dalgaard 
> on Fri, 20 Nov 2009 09:54:34 +0100 writes:

PD> m...@celos.net wrote:
>> Arrays of POSIXlt dates always return a length of 9.  This
>> is correct (they're really lists of vectors of seconds,
>> hours, and so forth), but other methods disguise them as
>> flat vectors, giving superficially surprising behaviour:
>> 
>> strings <- paste('2009-1-', 1:31, sep='')
>> dates <- strptime(strings, format="%Y-%m-%d")
>> 
>> print(dates)
>> #  [1] "2009-01-01" "2009-01-02" "2009-01-03" "2009-01-04" "2009-01-05"
>> #  [6] "2009-01-06" "2009-01-07" "2009-01-08" "2009-01-09" "2009-01-10"
>> # [11] "2009-01-11" "2009-01-12" "2009-01-13" "2009-01-14" "2009-01-15"
>> # [16] "2009-01-16" "2009-01-17" "2009-01-18" "2009-01-19" "2009-01-20"
>> # [21] "2009-01-21" "2009-01-22" "2009-01-23" "2009-01-24" "2009-01-25"
>> # [26] "2009-01-26" "2009-01-27" "2009-01-28" "2009-01-29" "2009-01-30"
>> # [31] "2009-01-31"
>> 
>> print(length(dates))
>> # [1] 9
>> 
>> str(dates)
>> # POSIXlt[1:9], format: "2009-01-01" "2009-01-02" "2009-01-03" 
"2009-01-04" ...
>> 
>> print(dates[20])
>> # [1] "2009-01-20"
>> 
>> print(length(dates[20]))
>> # [1] 9
>> 
>> I've since realised that POSIXct makes date vectors easier,
>> but could we also have something like:
>> 
>> length.POSIXlt <- function(x) { length(x$sec) }
>> 
>> in datetime.R, to avoid breaking functions (like the
>> str.POSIXt method) which use length() in this way?


PD> [You need "wishlist" in the title for this sort of stuff.]

PD> I'd be wary of this. Just the other day we found that identical() broke 
PD> on some objects because a package had length() redefined as a class 
PD> method. I.e. the danger is that something wants to use length() with 
its 
PD> original low-level interpretation.

Yes, of course.
and Romain mentioned  str().  Note that we have needed to define
a "POSIXt" method for str(), partly just *because* of the
current anomaly:
As Tony Plate, e.g., has argued, entirely correctly in my view,
the anomaly is thatlength() and "["   are not compatible;
and while I think no R language definition says that they should
be, I still believe that you need very good reasons for them to
be incompatible, as they are for POSIXlt.

In the current case, for me the only good reason is backwards
compatibility.
My personal taste would be to change it and see what happens.
I would be willing to clean up after that change within R 'base'
and all packages I am coauthoring (quite a few), but of course
there are still a thousand more R packages..
My strong bet would be that less than 1% would be affected,
and my point guess for the percentage affected would be
rather in the order of  1/1000.

The question is if we (you too!), the R community, are willing to
bear the load of cleanup, after such a change which would really
*improve* consistency of that small corner of R.
For me, as I indicated above, I am willing to bear my share
(and actually have got it ready for R-devel)

Martin Maechler, ETH Zurich (and R Core Team)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Suggestion for the reproducibility of R home page figure

2009-11-20 Thread Jean lobry

Dear R-devel,

googling for the single letter R yields R-home page as the firt hit,
which is extremly nice.

By clicking on the figure you get the code of the "Winner of the R
Homepage graphics competition 2004."

By copy/pasting in your R console it doesn't work because it is impossible
to install the mva package.

This is my point.

As documented in ONEWS the reason is simple: since R 1.9.0 the package
mva as been merged into the package stats.

My suggestion is just to change the begining of the code as follows to
neutralize the requirement for the mva package:


### Code by Eric Lecoutre, Universite catholique de Louvain, Belgium
### Winner of the R Homepage graphics competition 2004

### Works in R 1.8.1 ...
### Still works in R 2.10.0 (2009-10-26) by deleting the requirement 
for the mva package ...


require(ade4)
#require(mva) no more needed since R version 1.9.0 as mva was merged 
in the standard stats package.

require(RColorBrewer)
require(pixmap)

etc.


so that reproducibility of the graph is straightforward (at least for 
someone who

is able to install an R package).

This is a minor change. I consider this is important because it may help people
wanting to test quickly the long term reproducibility of R results. For them
installing a package is not a problem, but do not expect them to have time to
dig in old ONEWS

Please take this as a constructive comment, I was amazed how it was easy for me
to run this "old" R code. Just want to share.

Very Best,

Jean
--
Jean R. Lobry(lo...@biomserv.univ-lyon1.fr)
Laboratoire BBE-CNRS-UMR-5558, Univ. C. Bernard - LYON I,
43 Bd 11/11/1918, F-69622 VILLEURBANNE CEDEX, FRANCE
allo  : +33 472 43 27 56 fax: +33 472 43 13 88
http://pbil.univ-lyon1.fr/members/lobry/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Including local dynamic libraries

2009-11-20 Thread Elana Fertig

Hi All,

I am trying to install the package rjags into a local library on a  
machine for which I do not have root permissions.


Using the command: R CMD INSTALL --configure-args="--with-jags-include= 
${JAGSBIN}/include/JAGS --with-jags-lib=${JAGSBIN}/lib/ --with-jags- 
modules=${JAGSBIN}/lib/JAGS/modules" CMD INSTALL -l ${JAGSBIN}/lib/ ../ 
rjags_1.0.3-12.tar.gz


Where ${JAGSBIN} is defined as a local directory, the installation  
seems to be working fine.  Then, I go into R and type the following  
commands:

> .libPaths("${JAGSBIN}/lib/")
> library("rjags")

I get the following error

Loading required package: coda
Loading required package: lattice
Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared library '${JAGSBIN}/lib/rjags/libs/rjags.so':
  libjags.so.1: cannot open shared object file: No such file or  
directory

Error : .onLoad failed in 'loadNamespace' for 'rjags'
Error: package/namespace load failed for 'rjags'

Ideally, I would fix this problem by adding the appropriate libraries  
to /user/local/lib64 .  However, since I do not have root permissions  
I am not able to make this addition.  How can I have R recognize c++  
libraries from my local path?


Thanks so much in advance for your help.

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Including local dynamic libraries

2009-11-20 Thread Romain Francois

On 11/20/2009 08:43 PM, Elana Fertig wrote:

Hi All,

I am trying to install the package rjags into a local library on a
machine for which I do not have root permissions.

Using the command: R CMD INSTALL
--configure-args="--with-jags-include=${JAGSBIN}/include/JAGS
--with-jags-lib=${JAGSBIN}/lib/
--with-jags-modules=${JAGSBIN}/lib/JAGS/modules" CMD INSTALL -l
${JAGSBIN}/lib/ ../rjags_1.0.3-12.tar.gz

Where ${JAGSBIN} is defined as a local directory, the installation seems
to be working fine. Then, I go into R and type the following commands:
 > .libPaths("${JAGSBIN}/lib/")


Maybe this :

.libPaths( file.path( Sys.getenv("JAGSBIN", "lib" ) ) )


 > library("rjags")

I get the following error

Loading required package: coda
Loading required package: lattice
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '${JAGSBIN}/lib/rjags/libs/rjags.so':
libjags.so.1: cannot open shared object file: No such file or directory
Error : .onLoad failed in 'loadNamespace' for 'rjags'
Error: package/namespace load failed for 'rjags'

Ideally, I would fix this problem by adding the appropriate libraries to
/user/local/lib64 . However, since I do not have root permissions I am
not able to make this addition. How can I have R recognize c++ libraries
from my local path?

Thanks so much in advance for your help.



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Including local dynamic libraries

2009-11-20 Thread Simon Urbanek


On Nov 20, 2009, at 3:07 PM, Romain Francois wrote:


On 11/20/2009 08:43 PM, Elana Fertig wrote:

Hi All,

I am trying to install the package rjags into a local library on a
machine for which I do not have root permissions.

Using the command: R CMD INSTALL
--configure-args="--with-jags-include=${JAGSBIN}/include/JAGS
--with-jags-lib=${JAGSBIN}/lib/
--with-jags-modules=${JAGSBIN}/lib/JAGS/modules" CMD INSTALL -l
${JAGSBIN}/lib/ ../rjags_1.0.3-12.tar.gz

Where ${JAGSBIN} is defined as a local directory, the installation  
seems
to be working fine. Then, I go into R and type the following  
commands:

> .libPaths("${JAGSBIN}/lib/")


Maybe this :

.libPaths( file.path( Sys.getenv("JAGSBIN", "lib" ) ) )



Unlikely - it's probably just a matter of setting LD_LIBRARY_PATH  
correctly .. not really an R issue at all ...


Cheers,
S



> library("rjags")

I get the following error

Loading required package: coda
Loading required package: lattice
Error in dyn.load(file, DLLpath = DLLpath, ...) :
unable to load shared library '${JAGSBIN}/lib/rjags/libs/rjags.so':
libjags.so.1: cannot open shared object file: No such file or  
directory

Error : .onLoad failed in 'loadNamespace' for 'rjags'
Error: package/namespace load failed for 'rjags'

Ideally, I would fix this problem by adding the appropriate  
libraries to
/user/local/lib64 . However, since I do not have root permissions I  
am
not able to make this addition. How can I have R recognize c++  
libraries

from my local path?

Thanks so much in advance for your help.



--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/EAD5 : LondonR slides
|- http://tr.im/BcPw : celebrating R commit #5
`- http://tr.im/ztCu : RGG #158:161: examples of package IDPmisc

__
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