Hi, On Sun, Sep 26, 2010 at 1:10 PM, Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > Hi, > > On Sunday 26 September 2010, Prasenjit Kapat wrote: >> Yeah this kind of brings back the argument of moving these into >> internal.R, or at least move the help links to a >> rkward_for_rkward_devs.rkh page. > > yes, perhaps that is a good idea to create such a "rkward_for_rkward_devs" > page, so as not to make these too prominently visible. I'd leave moving them > to internal.R for after the release, though. No reason to risk comitting copy- > and-paste mistakes at this point.
All right, I'll add that page tonight. > Probably we want more than just internal.R, and public.R. I guess internal.R > should be for functions which will only ever be called by the C++-code, or > used by other functions. Beyond that we may want to sort into functions > dealing with output, automated testing, etc. (similar to the way you split the > .Rd-files, perhaps). Indeed, some thing to do after the release. > Also, when looking at the documentation (and again, thanks for creating this!) > I also have the strong feeling, that some of these functions can probably be > merged, or removed, completely. But that will require great care, naturally. Also, one would need to keep in mind that if we were to provide a rkward package on CRAN (although, I somehow don't like the idea) then it should behave "independently," ie, all help links and functions should be self contained. Regards, -- Prasenjit ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
