From andy_liaw at merck.com  Wed Oct 13 17:12:32 2004
From: andy_liaw at merck.com (Liaw, Andy)
Date: Wed Oct 13 17:13:48 2004
Subject: [Rd] RE: [R] debugging non-visible functions
Message-ID: <3A822319EB35174CA3714066D590DCD504AF852F@usrymx25.merck.com>

> From: Duncan Temple Lang
> 
> Prof Brian Ripley wrote:
> > On Wed, 13 Oct 2004, Liaw, Andy wrote:
> > 
> > 
> > > On a slightly different topic:  In R-2.0.0, packages with 
> NAMESPACE no
> > > longer need to use the package= argument in .C/.Fortran.  
> Does that mean if
> > > I remove those arguments, I should put R version >= 2.0.0 
> in the Depend
> > > field of the DESCRIPTION?
> > 
> > I think you should not remove the PACKAGE= (sic) arguments. 
>  There has
> > been little (none I have seen) discussion of that change, 
> and Duncan TL
> > will be able to elucidate.  But the reason given in NEWS to 
> omit them
> > relates to loading more than one versioned install of a 
> package at once,
> > something we were told originally by Robert G was not intended to be
> > allowed (and that is assumed in quite a few places in the 
> code -- there is
> > no way to have imports from a version of a namespace, for 
> example -- and
> > indeed importing from versioned install of namespaces did 
> not work in
> > 2.0.0).  Duncan?
> 
> The reason in the NEWS file is exactly the motivation.
> It is for cases where one explicitly loads a package (A) via 
> the library() function,
> and a different version of that package is imported indirectly  
> when loading another package via a dependency on an explicit 
> version of A.   And this is also the case when two packages (B and C)
> require different versions of the original package. 
> A less pressing but useful use example is when one wants to compare
> results from different versions as one develops new releases.
> And similarly for reproducible research, we often need explicit
> versions of packages within a larger context of an existing R session.
> There are easy work around for some of these, but they are 
> cumbersome.
> 
> I don't recall the exact details of Robert's original 
> statements on this topic.  As with many features
> introduced in R, the initial work (e.g. on namespaces) is not 
> entirely functional
> for all advanced, less-used aspects of other features being 
> introduced.
> So we will have to allow a NAMESPACE to import from
> a particular version as things evolve. It is an issue,
> but I don't think we want to prohibit having
> different versions of a package loaded concurrently.
> Using a namespace provides a convenient way to find
> the associated DLL.  We can also explicitly identify
 
The original problem I described to Robert is that, when I loaded two
versions of randomForest into R, calling the first one is fine, but calling
the second leads to segfault.  This is probably just laziness on my part:  I
was trying to see differences between the versions, as Duncan mentioned
above.  This can be done in other ways, but it would be nice to do within
the same R session...  I have not tried the new feature yet.


> > But if you do, yes you need (R >= 2.0.0) or R CMD check in earlier 
> > versions will scold you and users could get bitten.
> 
> And, as Andy well knows since he discovered the problem,
> if one doesn't use the new mechanism (i.e. with a NAMESPACE
> file and without the PACKAGE argument),  users can get bitten
> too.  Damned if you do, ...
> Not allowing versions is definitely easiest, but 
> the feature is feasible and desirable.
> 
> And dropping the PACKAGE argument makes the code more 
> compatible with S-Plus and so easier to maintain common
> versions across both engines.

It may be icing on the cake, but I've pretty much given up on trying to
provide an S-PLUS version of RF, especially as I make more and more calls to
utility functions via the C API.

Thanks to y'all for the help!

Best,
Andy

 
>  D.
> 
> > 
> > Brian
> > 
> > -- 
> > Brian D. Ripley,                  ripley@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
> > 
> > ______________________________________________
> > R-devel@stat.math.ethz.ch mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> -- 
> Duncan Temple Lang                        duncan@wald.ucdavis.edu
>  371, Kerr Hall
>  University of California at Davis
> 
> Phone: (530) 752-4782
> FAX:   (530) 752-7099
> 
> 
>


[Rd] RE: [R] debugging non-visible functions
Liaw, Andy