similar to: Bug in parseNamespaceFile or switch( , ... ) ?

I'm trying to compile R 2.10.1 on AIX 5.3, and am getting the following error: Error in read.dcf(file = descfile) : Line starting 'Package: tools ...' is malformed! Calls: makeLazyLoading ... code2LazyLoadDB -> loadNamespace -> parseNamespaceFile -> read.dcf Execution halted make[3]: *** [all] Error 1 make[3]: Leaving directory

Dear all, I have defined a generic as.ff(x, ...) and a method as.ff.function(x, ...) which converts a standard R function x into a chunked version operating on large ff objects. Everything works fine, but when registering S3method("as.ff",function) in NAMESPACE, the installation fails with some kind of parsing error: adding build stamp to DESCRIPTION installing NAMESPACE file

Dear All, I recently got a laptop upgrade, and had to re-install the tools I used for building R packages on Windows (XP SP2). I'm running into a strange problem that I can't resolve. Can anyone shed on light? This is with R-2.7.2 patched 2008-09-20 r46576, Rtools.zip downloaded a couple of weeks ago, and MikTeX 2.7. The output below was from a cygwin shell (PATH modified

I'm rather puzzled by this behavior: e export("caption<-", "caption", "label", "label<-", "align<-", "align", "digits<-", "digits", "display<-", "display", "xtable", "print.xtable", "toLatex.xtable") > e[[1L]] e[[1L]] export >

Dear list members, I've encountered the following problem trying to build a package under Windows Vista (SP1). The problem occurs with both R 2.6.2 and R 2.7.0 RC (from which this output was produced). The package builds just fine on my XP (SP2) machine. Please see some further comments below. ---------- snip ------------- Microsoft Windows [Version 6.0.6001] Copyright (c) 2006 Microsoft

Dear R-developers: I'm trying to build a 64-bit R-patched_2006-07-24 on SunFire V40z with on Solaris OS 10 64-bit kernel and using Sun Studio 11 compilers. Everything runs OK until it gets to building package tools (all.R) where it fails. Bellow is how I tried it (I can provide any other additional info if needed). Any help please? Thank you very much Latchezar Dimitrov Wake Forest Univ.

Dear All, I was trying to format a numeric vector (100*1) by using outd <- format(x=m, sci=F, digits=2) > outd[1:10] [1] " 0.01787758" "-0.14760306" "-0.45806041" "-0.67858525" "-0.64591748" [6] "-0.05918100" "-0.25632276" "-0.15980138" "-0.08359873" "-0.37866688" >m[1:10] [1]

For the purpose of automatic documentation, I want to parse a NAMESPACE file of the package to be documented. I want to know the contents: exportedClasses , exportedMethods and so on to be able to hide the part of the documentation not exposed in the NAMESPACE file. Up to now I am parsing the file myself and do some regexpr stuff to get what i want. It would however be much nicer to use the

Circa 80 CRAN and core-R packages have duplicate export entries in their NAMESPACE files. E.g., bit 1.1.9 : c("as.bit", "as.bitwhich", "as.which", "physical", "virtual") forecast 4.1 : "forecast.lm" graphics 2.15.3 : "barplot" mcmc 0.9.1 : "morph" RCurl 1.95.3 : "curlOptions" utils 2.15.3 :

I find system.file() handy for writing examples, but if the user mistypes its arguments or if a package is not up to date its return value of "" can lead to trouble. This forces the example to be wordier than I'd like. E.g., the following example works > scan(what="", sep="\n", system.file("DESCRIPTION")) Read 9 items [1] "Package:

I think it would be a good idea. Several versions of the survival package had a duplicate line in the S3methods, and were missing a line that should have been there, due to a cut/paste error. Terry T. On 03/13/2013 06:00 AM, r-devel-request at r-project.org wrote: > Circa 80 CRAN and core-R packages have duplicate export entries in their NAMESPACE files. E.g., > bit 1.1.9 :

I'm trying to compile R 2.10.1 on AIX, and getting the following errors when it is trying to build the tools package: Error in read.dcf(file = descfile) : Line starting 'Package: tools ...' is malformed! Calls: makeLazyLoading ... code2LazyLoadDB -> loadNamespace -> parseNamespaceFile -> read.dcf Execution halted make: *** [all] Error 1 My environment and configure

Hi all, I met a problem with R-2.10.1 installation on AIX5.3. The error message is as following: make[3]: Entering directory `/rnd/homes/tmp/R-2.10.1/src/library/tools' building package 'tools' mkdir ../../../library/tools make[4]: Entering directory `/rnd/homes/tmp/R-2.10.1/src/library/tools' mkdir ../../../library/tools/R mkdir ../../../library/tools/po make[4]: Leaving

This is an enquiry not so much about what the code for loadNamespace does, but rather about the intent and design of loadNamespace, and how it interacts with the `::` function, which seems to me to follow a slightly different philosophy. It is not an urgent question - the issue that started me wondering has been resolved another way - but I would like to complete my understanding of this aspect

Hi, I'm hoping to get some clarification of the intent of some of directives used in NAMESPACE files. 1. Is import(somePkg) also intended to import all classes and methods that are exported via exportClasses and exportMethods in somePkg? I think import pulls in classes and methods, but it isn't clear from the docs whether this is as intended. 2. What is exportMethods intended

It would be nice to have a more convenient means of exporting multiple classes from a package namespace. Why not have something like exportClassPattern() that worked like exportPattern() except for classes? Thanks, Michael [[alternative HTML version deleted]]

To begin with I have not applied and am not using the patches provided by Julian Anastasov. http://www.linuxvirtualserver.org/~julian/ I do not believe at the moment they apply to the problem I am having. If they are I will go through the process of applying the patch. They mostly have to due with what happens when a connection dies. At the moment both of my connections are live, and I am having

Dear all, It is my understanding that using 'importFrom' in the NAMESPACE of a package allows to avoid conflicts between different packages defining objects with identical names. However, I can still see conflicts while loading the package using 'library'. Here is a toy example, with a package 'foo' importing 'as.igraph' from the igraph package, and 'nj'

Hi, in (at least) R v2.14.2 and R v2.15.0 alpha, '.conflicts.OK' is not exported and hence to seen by library(). DETAILS: In R-devel thread '[Rd] Suggestion: Not having to export .conflicts.OK in name spaces' on Mar 17-22, 2010 [https://stat.ethz.ch/pipermail/r-devel/2010-March/057017.html] it was discussed that one had to export '.conflicts.OK' in the namespace,

Dear R users/devs, TL;TR This is a translations status for R. Since I've revisited my own work in a github repo, I think some notes could be useful to other maintainers. ## Status The supported languages for "base": da, de, en, en_GB, es, fa, fr, it, ja, ko, nn, pl, pt_BR, ru, tr, zh_CN, zh_TW. Any single file is quite close to be completed (# of translated labels), but some