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
