Hi,
On Sat, Sep 25, 2010 at 6:52 AM, Thomas Friedrichsmeier
<thomas.friedrichsme...@ruhr-uni-bochum.de> wrote:
> 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.
Right. This is will be a more important limitation.
> 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.
Actually in this respect, I felt, some of these functions can go in
internal*.R as well. We may want to document them (and other
functions) as part of internal*.R functions which will be helpful for
those users who want to take the next step: contribute: either plugins
/ docs / core C++ side etc... These doc / help files need not be
exposed to the "regular users."
If you prefer, I can add a pages/rkward_for_rkward_devs.rkh and move
these links there? Then, move these functions back into internal.R?
>> 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
Yeah, I always felt had to be a better solution than reading and
parsing the files from disk. I wanted to have some solution (albeit a
dumb one) before asking you ;)
> 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.
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.
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
