Hi, On Saturday 25 September 2010, Prasenjit Kapat wrote: > I've added a rk.list.plugins (...) to public.R, I hope it is not > adding a "new feature."
well, it's sort of a new feature, but the important point is that it looks safe to add without breaking anything. > While documenting rk.call.plugin, I felt that > the user generally will have no idea of what goes as the first > argument ("plugin"). True. And also, of course, the user generally will have no idea of what the available arguments are for a particular plugin. Well, rk.call.plugin() is mostly a by-product of the "Run again" link, and the automated tests. I'm not sure whether there is a real use-case for it beyond that (and I've added some words of caution to the .Rd-file), but potentially it might be interested for scripting tutorial or similar purposes. > Is there any way to improve this? Right now, I am > just scanning the pluginmap files... Can the C++ side list all the > available plugins? Yes, and I've changed it to use that. However, the C++-side does not keep track of where the plugin was declared, so this feature is lost. Note that both versions of rk.list.plugins() also list plugins which are not really meant to be called from the top-level, i.e. including those designed for embedding, or context-sensitive plugins like the graphics export-plugin. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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