[Rd] Removing support for --without-iconv

[Prof Brian Ripley]

We made support for a sufficiently general iconv 'essential' in R 
2.5.0 and have been giving configure warnings on --without-iconv ever 
since.  We originally announced that --without-iconv would be 
available in 2.5.x only.


The delay in making iconv compulsory was down to problems with 
installing GNU iconv from public repositories on AIX and 64-bit 
Solaris, but both are now resolved (see the latest R-admin manual, in 
R-patched or R-devel).


So we now propose to make iconv compulsory as from R 2.10.0.  If 
anyone has a compelling reason why this would cause difficulties, 
please post a deatialed case during the next week.


--
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] beginner's guide to C++ programming with R packages?

[Douglas Bates]

On Fri, Jun 26, 2009 at 2:43 PM, Paul Johnson wrote:
> Hello, again.
>
> I'm interested to learn how programmers develop & test C/C++ code with
> R packages in Linux.  I've been reading R source and the manual on
> Writing R Extensions but there are just a couple of details I can't
> understand.  I wish I could watch over a developer's shoulder to see
> how people actually do this.
>
> I've tested a bit.  I am able to take package.tar.gz file, open it up,
> fiddle the source code, and then run
>
> R CMD check package-dir
>
> from the directory above "package-dir" ,
>
> R CMD build package-dir
>
> and
>
> R CMD INSTALL

For your purposes it is probably better to avoid building a new tar.gz
file and combine the last two steps as

R CMD INSTALL package-dir

The install process uses the make utility which will check which of
the object files need to be recompiled.  If you only modify one source
file it will be the only file recompiled.
> on the tarball that is produced. Then in R, I can load the package and use it.
>
> That part is "all good", but somewhat tedious.  I don't want to
> entirely recompile and reinstall the whole package just to test one
> function.  I notice that R CMD check creates a new directory called
> "package.Rcheck" and the shared objects and example code of the
> package are in there.  Can I force R to use those *.so files instead
> of the ones in /usr/lib/R ?
>
>
> I also wonder "what is wrong with gprof?   In the Writing R Extensions
> manual, it describes "oprofile" and "sprof" for Linux. I will try
> them, but they are unfamilar to me.  I've used gprof in the past in C
> projects, and it is a pretty painless thing to add a compiler flag
> -pg, run the program, and then review gmon.out.  The Writing R
> Extensions manual does not mention gprof in its section on Linux, but
> it does mention it under Solaris.  There is a somewhat ambiguous
> statement:
>
> 3.4.2 Solaris
>
> On 64-bit (only) Solaris, the standard profiling tool gprof collects
> information from shared libraries compiled with -pg.
>
> Does "(only)" here mean to differentiate Solaris from other Linux/Unix
> systems?  Or does it differentiate 64bit Solaris from other Solaris?
>
> But this draws me back to the basic question.  I don't want to run R
> CMD INSTALL 20 times per hour.  How do developers "actually" test
> their code?
>
> pj
> --
> Paul E. Johnson
> Professor, Political Science
> 1541 Lilac Lane, Room 504
> University of Kansas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

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

[Rd] pbeta (PR#13786)

[pokar]

Full_Name: Piotr Pokarowski
Version: 2.9.0
OS: linux or windows
Submission from: (NULL) (212.76.37.160)


Dear R Development Core Team,

I would like to submit a bug in pbeta and, consequently, in  pf.
The function -pbeta(x,.5,2047,lower.tail=F,log.p=T) increases
roughly linearly in [.27, .292], next it is equal to Inf in [.293,.299] and
in [.3,.32] it increases linearly again. Please check:
curve(-pbeta(x,.5,2047,lower.tail=F,log.p=T),.27,.32)

Best regards,

Piotr Pokarowski

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

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Martin Morgan]

Troy Robertson wrote:
> Right you are Martin,
> 
> When you simplify things right down your code below works.
> 
> I had kept getting the error below:
> 
> Error in validObject(.Object) :
>   invalid class "KrillEnvironment" object: class for slot "datafileConn" 
> ("file")
> 
> But now realise that it is when the class extends '.environment' and passes 
> through the .xData slot:

I think the problem now is that the object is not initialized properly,
specifically that the 'datafileConn' slot is NULL, but should be 'file'.
This is true of the simpler case as well

> setClass("Element", representation=representation(datafileConn="file"))
[1] "Element"
> validObject(new("Element"))
Error in validObject(new("Element")) :
  invalid class "Element" object: invalid object for slot "datafileConn"
in class "Element": got class "NULL", should be or extend class "file"

datafileConn needs to be assigned appropriately in the class prototype
(but then all instances would inherit the same connection) or in the
initialize method.

I'm not sure that including a connection in a slot is going to be a good
idea, though -- a connection has reference-like semantics, so you can
end up with multiple objects pointing to the same connection, Also when
an object is garbage collected the connection will not be closed
automatically.

Martin

> 
> setClass("Element",representation=representation(datafileConn="file"), 
> contains=".environment")
> 
> setMethod("initialize", "Element",
>   function(.Object,.xData=new.env(parent=emptyenv())) {
> .Object <- callNextMethod(.Object, .xData=.xData)
> return(.Object)
>   }
> )
> 
> s <- new("Element")
> 
> 
> Not sure why that changes things though?
> 
> Troy
> 
>> -Original Message-
>> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
>> Sent: Monday, 29 June 2009 2:21 PM
>> To: Troy Robertson
>> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>>
>> Troy Robertson wrote:
>>> Hi all,
>>>
>>>
>>>
>>> I am having a problem trying to declare a slot representation to hold a
>> file connection.
>>> With V2.8.0 I had been using:
>>>
>>>
>>>
>>> setClass("Element",
>>>
>>> representation(
>>>
>>> [other slots removed],
>>>
>>> datafileConn= setOldClass(c("file","connection"))
>>>
>>> )
>>>
>>> )
>>>
>> I think
>>
>> setOldClass(c("file", "connection"))
>>
>> setClass("Element",
>>  representation=representation(datafileConn="file"))
>>
>> getClass("file")
>> getClass("Element")
>>
>> but I don't usually use S3 classes so I'm not sure...
>>
>> Martin
>>
>>>
>>> This resulted in a warning but still ran okay.
>>>
>>>
>>>
>>> No however with V2.9.0 I am getting an error:
>>>
>>>
>>>
>>> Error in representation(state = "list", initialState = "list", polygons
>> = "list",  :
>>>   element 12 of the representation was not a single character string
>>>
>>>
>>>
>>> How can I declare a slot of the appropriate class?  The strings
>> "connection", "file" fail.
>>>
>>>
>>> Troy
>>>
>>>
>>>
>>>
>>>
>>> Troy Robertson
>>>
>>> Database and Computing Support Provider
>>>
>>> Southern Ocean Ecosystems, ERM/Fish
>>>
>>> Australian Antarctic Division
>>>
>>> Channel Highway, Kingston 7050
>>>
>>> PH: 03 62323571
>>>
>>> troy.robert...@aad.gov.au
>>>
>>>
>>>
>>>
>>>
>> __
>> _
>>> Australian Antarctic Division - Commonwealth of Australia
>>> IMPORTANT: This transmission is intended for the addressee only. If you
>> are not the
>>> intended recipient, you are notified that use or dissemination of this
>> communication is
>>> strictly prohibited by Commonwealth law. If you have received this
>> transmission in error,
>>> please notify the sender immediately by e-mail or by telephoning +61 3
>> 6232 3209 and
>>> DELETE the message.
>>> Visit our web site at http://www.antarctica.gov.au/
>>>
>> __
>> _
>>>   [[alternative HTML version deleted]]
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ___
> 
> Australian Antarctic Division - Commonwealth of Australia
> IMPORTANT: This transmission is intended for the addressee only. If you are 
> not the
> intended recipient, you are notified that use or dissemination of this 
> communication is
> strictly prohibited by Commonwealth law. If you have received this 
> transmission in error,
> please notify the sender immediately by e-mail or by telephoning +61 3 6232 
> 3209 and
> DELETE the message.
> Visit our web site at http://www.antarctica.gov.au/
> ___

__
R-devel@r-project.org mailing list
https://st

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Stavros Macrakis]

On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  wrote:

> ...I'm not sure that including a connection in a slot is going to be a good
> idea, though -- a connection has reference-like semantics, so you can
> end up with multiple objects pointing to the same connection, Also when
> an object is garbage collected the connection will not be closed
> automatically.


I'm not sure I understand your point here.  Having multiple objects refer to
the same connection seems like a perfectly reasonable and useful thing, and
garbage collection should work just fine -- when *all* of the objects
referring to that connection are unreachable, then the connection is
unreachable and will itself be garbage collected.  No?

   -s

[[alternative HTML version deleted]]

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

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Paul Gilbert]

There may be a problem that objects with slots can persist into new 
sessions (i.e. be saved)  but I think connections die when a session 
ends, so whatever is in the slot is no longer valid.


Paul

Stavros Macrakis wrote:

On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  wrote:



...I'm not sure that including a connection in a slot is going to be a good
idea, though -- a connection has reference-like semantics, so you can
end up with multiple objects pointing to the same connection, Also when
an object is garbage collected the connection will not be closed
automatically.




I'm not sure I understand your point here.  Having multiple objects refer to
the same connection seems like a perfectly reasonable and useful thing, and
garbage collection should work just fine -- when *all* of the objects
referring to that connection are unreachable, then the connection is
unreachable and will itself be garbage collected.  No?

   -s

[[alternative HTML version deleted]]

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



La version française suit le texte anglais.



This email may contain privileged and/or confidential information, and the Bank 
of
Canada does not waive any related rights. Any distribution, use, or copying of 
this
email or the information it contains by other than the intended recipient is
unauthorized. If you received this email in error please delete it immediately 
from
your system and notify the sender promptly by email that you have done so. 




Le présent courriel peut contenir de l'information privilégiée ou 
confidentielle.
La Banque du Canada ne renonce pas aux droits qui s'y rapportent. Toute 
diffusion,
utilisation ou copie de ce courriel ou des renseignements qu'il contient par une
personne autre que le ou les destinataires désignés est interdite. Si vous 
recevez
ce courriel par erreur, veuillez le supprimer immédiatement et envoyer sans 
délai à
l'expéditeur un message électronique pour l'aviser que vous avez éliminé de 
votre
ordinateur toute copie du courriel reçu.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] Installing DLL elsewhere than in \libs?

[Philippe Grosjean]

Hello,

Its a couple of days I am fighting with this problem, and cannot find a 
solution. I need to compile a DLL that is not directly used by R, but 
must be installed elsewhere (it is indeed part of a Tcl/Tk package). So, 
I want to install it in /tklibs/tkpackage/alib.dll (under Windows) in my 
compiled package.


I do manage to compile it in /src, but cannot copy it at the right 
place. I tried using a cleanup.win file that contains:


cp src/alib.dll "${R_PACKAGE_DIR}/tklibs/tkpackage/alib.dll"

but it does not work. The Writing R extensions manual explicitly says 
not to use ${DPKG}. Yet, the following instruction does the job under R 
2.8.0:


cp src/alib.dll "${DPKG}/tklibs/tkpackage/alib.dll"

I become really desperate to get it working!
Thanks for help.
Best,

PhG
--
..<°}))><
 ) ) ) ) )
( ( ( ( (Prof. Philippe Grosjean
 ) ) ) ) )
( ( ( ( (Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons-Hainaut University, Belgium
( ( ( ( (
..

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

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Martin Morgan]

Stavros Macrakis wrote:
> On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  > wrote:
> 
> ...I'm not sure that including a connection in a slot is going to be
> a good
> idea, though -- a connection has reference-like semantics, so you can
> end up with multiple objects pointing to the same connection, Also when
> an object is garbage collected the connection will not be closed
> automatically.
> 
> 
> I'm not sure I understand your point here.  Having multiple objects
> refer to the same connection seems like a perfectly reasonable and
> useful thing, and garbage collection should work just fine -- when *all*
> of the objects referring to that connection are unreachable, then the
> connection is unreachable and will itself be garbage collected.  No?

I meant that, in practice, there were enough additional pitfalls that I
wouldn't choose this route (placing a connection in an S4 slot) for
myself. These little experiments were enough to make me cautious...

setOldClass(c("file", "connection"))

## Attempt one -- prototype
setClass("Element",
 representation=representation(conn="file"),
 prototype=prototype(conn=file()))

## oops, all instances share a single connection

close(new("Element")@conn)
## oops, all new instances now have a closed (invalid) connection


## Attempt two -- initialize
setClass("Element",
 representation=representation(conn="file"))

setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
callNextMethod(.Object, ..., conn=conn)
})

new("Element")
## oops, connection created but not closed; gc() closes (eventually)
## but with an ugly warning
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   717240  38.41166886  62.4  1073225  57.4
## Vcells 3795 284.9   63274729 482.8 60051033 458.2
## > gc()
##used  (Mb) gc trigger  (Mb) max used  (Mb)
## Ncells   715906  38.31166886  62.4  1073225  57.4
## Vcells 37335626 284.9   63274729 482.8 60051033 458.2
## Warning messages:
## 1: closing unused connection 3 ()

setClass("ElementX", contains="Element")
## oops, two connections opened (!)
## > showConnections()
##   description class  mode text   isopen   can read can write
## 3 ""  "file" "w+" "text" "opened" "yes""yes"
## 4 ""  "file" "w+" "text" "opened" "yes""yes"

And while completely expected the action-at-a-distance of references has
the usual risks

> x <- y <- new("Element")
> close(x...@conn)
> y
An object of class "Element"
Slot "conn":
Error in summary.connection(x) : invalid connection

One place I know where S4 and connections are used effectively is in the
AnnotationDbi package in Bioconductor (I did not participate in
developing this package, so am probably misrepresenting its
implementation). Here there is a database connection. But it is stored
in an environment in an S4 class. This part of the class is used
essentially as a singleton -- AnnotationDbi creates packages containing
instances, and users load the package and hence single instance; the
interface never exposes the connection itself to copying. The database
functionality exposed to the user is read-only, and querying the
connection does not change it's state (other than opening it if it were
closed). I think the underlying connection has C code to tidy itself up
appropriately (and quietly) when eventually garbage collected. So yes,
connections and multiple references to them can be useful.

Martin


>-s
>

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

[Rd] active bindings and ls.str

[Romain Francois]

Hello,

Should active binding appear as such in ls.str.

> makeActiveBinding( "xx", function(arg){ Sys.sleep(10) }, .GlobalEnv )
> ls.str() # takes 10 seconds
xx :  NULL

What we see here is the result of the "setter" of the binding.

I'm attaching a patch that prints this instead:

> ls.str()
xx : 

Although a better behaviour would be to show the binding function.

Romain

--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr


Index: src/library/utils/R/str.R
===
--- src/library/utils/R/str.R   (revision 48872)
+++ src/library/utils/R/str.R   (working copy)
@@ -544,14 +544,18 @@
 ##__   str(get(nam, envir = E, mode = M),
 ##__   max.level = max.level, give.attr = give.attr, ...)
 
-   o <- tryCatch(get(nam, envir = E, mode = M), error = function(e)e)
-   if(inherits(o, "error")) {
-   if(length(grep("missing|not found", o$message)))
-   cat("\n")
-   else stop(o$message)
+   if( bindingIsActive( nam, E) ){
+   cat( "\n" )
+   } else{
+   o <- tryCatch(get(nam, envir = E, mode = M), error = 
function(e)e)
+   if(inherits(o, "error")) {
+   if(length(grep("missing|not found", o$message)))
+   cat("\n")
+   else stop(o$message)
+   }
+   else
+   do.call(str, c(list(o), strargs))
+   }
}
-   else
-   do.call(str, c(list(o), strargs))
-}
 invisible(x)
 }
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] should Sys.glob() cope with a UNC windows path beginning with backslashes?

[Tony Plate]

Prof Brian Ripley wrote:

On Fri, 26 Jun 2009, Tony Plate wrote:

I find that Sys.glob() doesn't like UNC paths where the initial 
slashes are backslashes.  The help page for Sys.glob() doesn't 
specificly mention UNC paths, but does say: "File paths in Windows 
are interpreted with separator \ or /."  Is the failure to treat a 
path beginning with a double-backslash as a UNC network drive path 
the intended behavior?


Yes.  There are general warnings about non-POSIX Windows paths in 
several of the help files.


The following comments should alert you to possible restrictions:

  The \code{glob} system call is not part of Windows, and we supply an
  emulation.

  File paths in Windows are interpreted with separator \code{\\} or
  \code{/}.  Paths with a drive but relative (such as \code{c:foo\\bar})
  are tricky, but an attempt is made to handle them correctly.

If you want to submit a well-tested patch, it will be considered.
The problem seems to be in the function dos_wglob() in 
src/gnuwin32/dos_wglob.c.  This function treats backslashes as a escape 
characters when they precede one of the metacharacters []-{}~\.  So, an 
initial double backslash is changed to an initial single backslash. 
Consequently, the existing code does see network drives when the prefix 
is 3 or 4 backslashes.


Here's a patch that adds special treatment for a prefix of exactly two 
backslashes so that Sys.glob() sees a network drive in this case:


/cygdrive/c/Rbuild/R-2.9.1/src/gnuwin32
$ diff -c dos_wglob.c~ dos_wglob.c
*** dos_wglob.c~Sun Sep 21 16:05:28 2008
--- dos_wglob.c Mon Jun 29 12:09:47 2009
***
*** 203,208 
--- 203,222 
   *bufnext++ = BG_SEP;
   patnext += 2;
 }
+ /* Hack to treat UNC network drive specification correctly:
+  * Without this code, '\\' (i.e., literally two backslashes in 
pattern)

+  * at the beginning of a path is not recognized as a network drive,
+  * because the GLOB_QUOTE loop below changes the two backslashes 
to one.

+  * So, in the case where there are two but not three backslashes at
+  * the beginning of the path, transfer these to the output.
+  */
+ if (patnext == pattern && bufend - bufnext > 2 &&
+   pattern[0] == BG_SEP2 && pattern[1] == BG_SEP2 &&
+   pattern[2] != BG_SEP2) {
+   *bufnext++ = pattern[0];
+   *bufnext++ = pattern[1];
+   patnext += 2;
+ }
 #endif

 if (flags & GLOB_QUOTE) {

*** end of patch

This changes behavior in the just the case where the prefix is two 
backslashes.  With the fix, the behavior is:

> Sys.glob("\\jacona\\home\\tplate")
character(0)
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("\\jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"

Without the fix, the behavior is:
> Sys.glob("\\jacona\\home\\tplate")
character(0)
> Sys.glob("jacona\\home\\tplate")
character(0)
> Sys.glob("\\jacona\\home\\tplate")
[1] "jacona\\home\\tplate"
> Sys.glob("jacona\\home\\tplate")
[1] "jacona\\home\\tplate"


Here is a corresponding change to the docs:

tpl...@oberon /cygdrive/c/Rbuild/R-2.9.1/src/library/base/man
*** Sys.glob.Rd~Thu Mar 19 17:05:24 2009
--- Sys.glob.Rd Mon Jun 29 13:52:57 2009
***
*** 89,94 
--- 89,104 
   File paths in Windows are interpreted with separator \code{\\} or
   \code{/}.  Paths with a drive but relative (such as \code{c:foo\\bar})
   are tricky, but an attempt is made to handle them correctly.
+   Backslashes in paths are tricky because they can serve dual purposes:
+   meta-function remover and path separator.  As a result, single or
+   double backslashes can serve as path separators.  UNC network drive
+   paths specified with backslashes (such as \code{foo\\bar}) are
+   treated specially so that the network drive is found when the path
+   begins with two, three, or four backslashes (i.e., paths beginning
+   with \code{foo\\bar}, \code{\\foo\\bar}, and
+   \code{\\foo\\bar} all result in the same output).  UNC network
+   drive paths can also be specified with two forward slashes.
+
 #endif
 }
 \value{
***
*** 117,122 
--- 127,138 
 \examples{
 \dontrun{
 Sys.glob(file.path(R.home(), "library", "*", "R", "*.rdx"))
+ # different ways of seeing the same network drive
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("foobar")
+ Sys.glob("//foo/bar")
 }}
 \keyword{utilities}
 \keyword{file}

*** end of patch

R compiled with this fix passes 'make check-all' (or at least all the 
differences and warnings printed appear to be minor and unrelated to 
this change.)


I suspect that it is a matter of taste whether or not this "fix" is 
desirable.


The argument for it is that it helps Sys.glob() recognize standard UNC 
network drive specificatio

Re: [Rd] S4 and connection slot [Sec=Unclassified]

[Troy Robertson]

Thanks guys,

I wasn't having a problem storing active connections in slots initially.  They 
were opened during initialisation of the object and then a routine ran through 
and closed them all before the program exited.

I have now implemented them as environment stored objects as a way around the 
slot problem (along with all the rest of the class data members so that object 
passing is more efficient without all the memcpying).  So much for S4 slots.

Troy


> -Original Message-
> From: Martin Morgan [mailto:mtmor...@fhcrc.org]
> Sent: Tuesday, 30 June 2009 5:12 AM
> To: Stavros Macrakis
> Cc: Troy Robertson; r-devel@R-project.org
> Subject: Re: [Rd] S4 and connection slot [Sec=Unclassified]
>
> Stavros Macrakis wrote:
> > On Mon, Jun 29, 2009 at 9:19 AM, Martin Morgan  > > wrote:
> >
> > ...I'm not sure that including a connection in a slot is going to be
> > a good
> > idea, though -- a connection has reference-like semantics, so you
> can
> > end up with multiple objects pointing to the same connection, Also
> when
> > an object is garbage collected the connection will not be closed
> > automatically.
> >
> >
> > I'm not sure I understand your point here.  Having multiple objects
> > refer to the same connection seems like a perfectly reasonable and
> > useful thing, and garbage collection should work just fine -- when *all*
> > of the objects referring to that connection are unreachable, then the
> > connection is unreachable and will itself be garbage collected.  No?
>
> I meant that, in practice, there were enough additional pitfalls that I
> wouldn't choose this route (placing a connection in an S4 slot) for
> myself. These little experiments were enough to make me cautious...
>
> setOldClass(c("file", "connection"))
>
> ## Attempt one -- prototype
> setClass("Element",
>  representation=representation(conn="file"),
>  prototype=prototype(conn=file()))
>
> ## oops, all instances share a single connection
>
> close(new("Element")@conn)
> ## oops, all new instances now have a closed (invalid) connection
>
>
> ## Attempt two -- initialize
> setClass("Element",
>  representation=representation(conn="file"))
>
> setMethod(initialize, "Element", function(.Object, ..., conn=file()) {
> callNextMethod(.Object, ..., conn=conn)
> })
>
> new("Element")
> ## oops, connection created but not closed; gc() closes (eventually)
> ## but with an ugly warning
> ## > gc()
> ##used  (Mb) gc trigger  (Mb) max used  (Mb)
> ## Ncells   717240  38.41166886  62.4  1073225  57.4
> ## Vcells 3795 284.9   63274729 482.8 60051033 458.2
> ## > gc()
> ##used  (Mb) gc trigger  (Mb) max used  (Mb)
> ## Ncells   715906  38.31166886  62.4  1073225  57.4
> ## Vcells 37335626 284.9   63274729 482.8 60051033 458.2
> ## Warning messages:
> ## 1: closing unused connection 3 ()
>
> setClass("ElementX", contains="Element")
> ## oops, two connections opened (!)
> ## > showConnections()
> ##   description class  mode text   isopen   can read can write
> ## 3 ""  "file" "w+" "text" "opened" "yes""yes"
> ## 4 ""  "file" "w+" "text" "opened" "yes""yes"
>
> And while completely expected the action-at-a-distance of references has
> the usual risks
>
> > x <- y <- new("Element")
> > close(x...@conn)
> > y
> An object of class "Element"
> Slot "conn":
> Error in summary.connection(x) : invalid connection
>
> One place I know where S4 and connections are used effectively is in the
> AnnotationDbi package in Bioconductor (I did not participate in
> developing this package, so am probably misrepresenting its
> implementation). Here there is a database connection. But it is stored
> in an environment in an S4 class. This part of the class is used
> essentially as a singleton -- AnnotationDbi creates packages containing
> instances, and users load the package and hence single instance; the
> interface never exposes the connection itself to copying. The database
> functionality exposed to the user is read-only, and querying the
> connection does not change it's state (other than opening it if it were
> closed). I think the underlying connection has C code to tidy itself up
> appropriately (and quietly) when eventually garbage collected. So yes,
> connections and multiple references to them can be useful.
>
> Martin
>
>
> >-s
> >

___

Australian Antarctic Division - Commonwealth of Australia
IMPORTANT: This transmission is intended for the addressee only. If you are not 
the
intended recipient, you are notified that use or dissemination of this 
communication is
strictly prohibited by Commonwealth law. If you have received this transmission 
in error,
please notify the sender immediately by e-mail or by telephoning +61 3 6232 
3209 and
DELETE the message.
Visit our web site at http://www.antarctica.gov.au/

Re: [Rd] Installing DLL elsewhere than in \libs?

[Dirk Eddelbuettel]

Philippe,

On 29 June 2009 at 19:59, Philippe Grosjean wrote:
| Its a couple of days I am fighting with this problem, and cannot find a 
| solution. I need to compile a DLL that is not directly used by R, but 
| must be installed elsewhere (it is indeed part of a Tcl/Tk package). So, 
| I want to install it in /tklibs/tkpackage/alib.dll (under Windows) in my 
| compiled package.
| 
| I do manage to compile it in /src, but cannot copy it at the right 
| place. I tried using a cleanup.win file that contains:
| 
| cp src/alib.dll "${R_PACKAGE_DIR}/tklibs/tkpackage/alib.dll"
| 
| but it does not work. The Writing R extensions manual explicitly says 
| not to use ${DPKG}. Yet, the following instruction does the job under R 
| 2.8.0:
| 
| cp src/alib.dll "${DPKG}/tklibs/tkpackage/alib.dll"
| 
| I become really desperate to get it working!
| Thanks for help.

I think I am doing something similar to what you are trying to do inside the
Rcpp package [cf r-forge].  There my goal is to provide a package for
'external linking' and I do this in via src/Makevars:

1)  Main target is 'all:' and includes the SHLIB the package would build any
way, as well as an added target userLibrary:

2)  Couple of variable including an extension for the shared lib which gets
filled only on OS X

3)  In the userLibrary target, create (if need be) the target dir and copy
the previously created library over.

4)  Targets for the shared and static user library that userLibrary target
depends upon.

This is essentially the same under Windows. Credit for a lot of this setup
goes to Simon who helped with this while addressing an issue I had on OS X.

Hope this helps,  Dirk



all:$(SHLIB) userLibrary

USERLIB =   libRcpp$(DYLIB_EXT)
USERLIBST = libRcpp.a
USERDIR =   ../inst/lib

userLibrary:$(USERLIB) $(USERLIBST)
-...@if test ! -e $(USERDIR)$(R_ARCH); then mkdir -p 
$(USERDIR)$(R_ARCH); fi
cp $(USERLIB) $(USERDIR)$(R_ARCH)
cp Rcpp.h $(USERDIR)$(R_ARCH)
cp $(USERLIBST) $(USERDIR)$(R_ARCH)
rm $(USERLIB) $(USERLIBST)

$(USERLIB): Rcpp.o
$(SHLIB_CXXLD) -o $(USERLIB) $^ $(SHLIB_CXXLDFLAGS) $(ALL_LIBS)
@if test -e "/usr/bin/install_name_tool"; then 
/usr/bin/install_name_tool -id $(R_PACKAGE_DIR)/lib$(R_ARCH)/$(USERLIB) 
$(USERLIB); fi

$(USERLIBST):   Rcpp.o
$(AR) qc $(USERLIBST) Rcpp.o
@if test -n "$(RANLIB)"; then $(RANLIB) $(USERLIBST); fi

.PHONY: all clean userLibrary

clean:
rm -f $(OBJECTS) $(SHLIB) $(USERLIB) $(USERLIBST)




-- 
Three out of two people have difficulties with fractions.

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

Re: [Rd] beginner's guide to C++ programming with R packages?

[Mathieu Ribatet]

An other possibility is to insert new features in your package once you
feel pretty confident with your new code. "R CMD SHLIB myfile.c" will
build the SHared LIBrary and then load it in R by invoking
"dyn.load("myfile.so")" in an R console.

Once you're satisfied with your code, just do as you did before - R CMD
build mypkg".

Cheers,
Mathieu

Le lundi 29 juin 2009 à 11:49 +0200, Douglas Bates a écrit :
> On Fri, Jun 26, 2009 at 2:43 PM, Paul Johnson wrote:
> > Hello, again.
> >
> > I'm interested to learn how programmers develop & test C/C++ code with
> > R packages in Linux.  I've been reading R source and the manual on
> > Writing R Extensions but there are just a couple of details I can't
> > understand.  I wish I could watch over a developer's shoulder to see
> > how people actually do this.
> >
> > I've tested a bit.  I am able to take package.tar.gz file, open it up,
> > fiddle the source code, and then run
> >
> > R CMD check package-dir
> >
> > from the directory above "package-dir" ,
> >
> > R CMD build package-dir
> >
> > and
> >
> > R CMD INSTALL
> 
> For your purposes it is probably better to avoid building a new tar.gz
> file and combine the last two steps as
> 
> R CMD INSTALL package-dir
> 
> The install process uses the make utility which will check which of
> the object files need to be recompiled.  If you only modify one source
> file it will be the only file recompiled.
> > on the tarball that is produced. Then in R, I can load the package and use 
> > it.
> >
> > That part is "all good", but somewhat tedious.  I don't want to
> > entirely recompile and reinstall the whole package just to test one
> > function.  I notice that R CMD check creates a new directory called
> > "package.Rcheck" and the shared objects and example code of the
> > package are in there.  Can I force R to use those *.so files instead
> > of the ones in /usr/lib/R ?
> >
> >
> > I also wonder "what is wrong with gprof?   In the Writing R Extensions
> > manual, it describes "oprofile" and "sprof" for Linux. I will try
> > them, but they are unfamilar to me.  I've used gprof in the past in C
> > projects, and it is a pretty painless thing to add a compiler flag
> > -pg, run the program, and then review gmon.out.  The Writing R
> > Extensions manual does not mention gprof in its section on Linux, but
> > it does mention it under Solaris.  There is a somewhat ambiguous
> > statement:
> >
> > 3.4.2 Solaris
> >
> > On 64-bit (only) Solaris, the standard profiling tool gprof collects
> > information from shared libraries compiled with -pg.
> >
> > Does "(only)" here mean to differentiate Solaris from other Linux/Unix
> > systems?  Or does it differentiate 64bit Solaris from other Solaris?
> >
> > But this draws me back to the basic question.  I don't want to run R
> > CMD INSTALL 20 times per hour.  How do developers "actually" test
> > their code?
> >
> > pj
> > --
> > Paul E. Johnson
> > Professor, Political Science
> > 1541 Lilac Lane, Room 504
> > University of Kansas
> >
> > __
> > 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
-- 
Institute of Mathematics
Ecole Polytechnique Fédérale de Lausanne
STAT-IMA-FSB-EPFL, Station 8
CH-1015 Lausanne   Switzerland
http://stat.epfl.ch/
Tel: + 41 (0)21 693 7907

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