Re: [Rd] how to control which version of a package library() installs?
On Fri, 13 Apr 2007, Tony Plate wrote:
> Prof Brian Ripley wrote:
>> On Fri, 13 Apr 2007, Tony Plate wrote:
>>
>>> Thank you! I had not realized that the name space remained loaded.
>>> When I did unloadNamespace("ExamplePackage") after the detach() I got
>>> what I wanted.
Seth Falcon mentioned detach(unload=TRUE) (needs R 2.5.x, I think), but
unloadNamespace() does detach() if needed.
>>> Maybe the following sentence might be a useful addition to the
>>> "Details" or "Notes" section of the help page for detach?:
>>> To detach() and reattach() a package you will probably need to use
>>> unloadNamespace("somePackage") after detach("package:somePackage")
>>
>> We should try to explain this, but there is another level of complexity.
>> If a package has compiled code, unloading the namespace is unlikely to
>> unload the DLL (it would need to be done explicitly in .onUnload).
>> And even then, as I understand it there are OSes on which you cannot
>> really unload DLLs, and certainly cannot load another DLL of the same
>> name into the process: you get the previously loaded one.
>>
>> Given all the issues, I always work on the assumption that re-loading a
>> package into a R session is not going to do what I intend.
>
> Ok, but will it work for packages with pure R code? (disregarding things
> a package might do in its load hooks).
Not necessarily, because registered S3 methods are not removed.
Also, you cannot unload a name space from which there are imports in use.
Also, exported S4 methods from a name space are cached, so the S4 methods
cache needs to be rebuilt (which would happen if the new version of the
package had S4 methods, and is done by detach(unload=TRUE)). However, the
S4 story is worse: setting S4 generics in a package on an existing
function captures the definition at package install time, so changing the
version of one package may require others to be re-installed. (That is
not hypothetical: it has happened in R-devel several times in the last two
weeks.)
I won't even start to mention versioned installs
--
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
__
[EMAIL PROTECTED] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R on Solaris 10 x64
Peter, Thanks for the hints. > 2 things caught my eye (except that their "R code" is clearly C): The > dbx output doesn't show off[curr_seq], which could actually be the > culprit, (dbx) p off[curr_seq] off[curr_seq] = 0 > and the _memcpy call on the stack looks odd: > > _memcpy(0x0, 0xfdebc707, 0x9f5c4f0) It shows the register values, which are not necessarily the arguments to memcpy(), apparently not in this case. The "guilty" line of code HDmemcpy(tgath_buf,buf+off[curr_seq],curr_len); translates into (due to macro "#define HDmemcpy(X,Y,Z) memcpy((char*)(X),(const char*)(Y),Z)") memcpy((char*)(tgath_buf),(const char*)(buf+off[curr_seq]),curr_len); and (dbx) p tgath_buf tgath_buf = 0x9f5c4f0 (definitely not NULL) We've also asked for help at [EMAIL PROTECTED] regarding the HDF5 package. This is under Solaris 10 x86, using the latest Sun Studio compiler/tools. -Greg > > > (What happened to the length and how did NULL get in there.) If memcpy() > is a macro, I think I'd take a closer look at the include files and see > if something is getting expanded in an unintended way. __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R on Solaris 10 x64
> Hmm, and can you see "both ends" of tgath_buf and buf (in particular > tgath_but[curr_len - 1] and buf[curr_len-1])? (dbx) p tgath_buf[curr_len - 1] tgath_buf[curr_len-1] = '\0' (dbx) p buf[curr_len-1] dbx: cannot access address 0x9f7f6ff (dbx) p tgath_buf[curr_len - 2] tgath_buf[curr_len-2] = '\0' (dbx) p buf[curr_len-2] dbx: cannot access address 0x9f7f6fe (dbx) Something is definitely wrong with this memcpy() operation. I suppose we'll need some help from the HDF5 folks to figure out what the buf memory buffer is supposed contain in this case. > If only to "eliminate from our inquiries", I'd try running CPP over the > code and see if the full macro expansion (including that from memcpy to > _memcpy) is working as intended. After the macro expansion, this code looks like this: for(curr_seq=0; curr_seq I take it that you've already tried compiling the module at maximal > warning level? No. We can try that, as well as lint. Thanks. -Greg __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] CRAN packages with invalid maintainer email addresses
As part of the process for the upcoming release of 2.5.0, we recently contacted all maintainers of CRAN packages which give R CMD check warnings or errors for a current prerelease of R 2.5.0. Emails to the following addresses bounced: "Jens Henrik Badsberg" <[EMAIL PROTECTED]> [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] meaning that the packages BHH2 Bolstad CoCo LoopAnalyst depmix dynamicGraph giRaph mathgraph pheno riv segmented svcm are to be considered unmaintained. If you maintain one of these package, pls do provide an update fixing the problems indicated on http://cran.r-project.org/src/contrib/checkSummary.html, and provide a valid email address. If you know how to contact the respective maintainers, pls let me know. If we receive no new information regarding these packages/maintainers, we need to start orphaning these packages when 2.5.0 is released (Apr 24, 10 days from now). Thanks! -k __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Rinterface.h on Windows
On 4/13/07, Prof Brian Ripley <[EMAIL PROTECTED]> wrote: > On Fri, 13 Apr 2007, Deepayan Sarkar wrote: > > > Hi, > > > > it looks like Rinterface.h is not available on Windows. Does this mean > > I can not reset the various ptr_R_* callbacks? Is there an > > alternative? Is this something fundamentally difficult or something > > not done because no one needs it? > > To my knowledge no one has asked for it, so I assume the latter. > At a glance, it does not look too difficult, as similar things are going > on in src/gnuwin32/system.c. Hmm, so I guess the good long term strategy would be to convert that to using the Rinterface.h API. I'll take a look some day when I'm feeling more adventurous. -Deepayan __ [EMAIL PROTECTED] mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
