[RkWard-devel] new tests

[Thomas Friedrichsmeier]

On Thursday 01 March 2007 22:35, Prasenjit Kapat wrote:
> Is it not possible to create an environment for the variables used in
> RkWard, which does not interfere with the user's variable space? I thought
> it was possible, but haven't given much thought. I will try to dig up some
> more help pages and see.

Well, yes and no. Creating an environment for a package is done automatically, 
and we keep some variables in the rkward environment already. However, 
assigning variables to a specified environment is cumbersome (you need the 
assign() function for that, = or <- is not usable).
Adding a temporary environment above the .GlobalEnv (i.e. earlier in the 
search path, so all normal assignments would go there instead of 
to .GlobalEnv) would be nice, but isn't supported in R, as far as I know.

> Instead of hardcoding local (..) into the php files, is it possible to run
> the whole php generated R code in a local(...) environment by default,
> without any the knowledge of the plugin writer? But of course documenting
> it somewhere. This way we might not need the cleanup() function in the php
> files.

Interesting idea, and of course it would be easy to realise, technically. 
Definitely worth considering further. Some minor issues, though:

1) If a variable is to be saved in the workspace, it needs to be assigned to 
with "<<-". Currently few plugins save something, but once we add 
transformation plugins, that will change.
2) Error messages get somewhat messy:
local(stop("ouch!"))
# Error in eval(expr, envir, enclos) : ouch!
Of course, plugins should not normally generate errors in the first place, so 
this may not be too important.
3) We'd want to get rid of all the rk.temp everywhere. But this would be an 
effort well invested.
4) Should the "local ({" and "})" be shown as part of the command? As part of 
the code preview? Probably to make the going-ons transparent. That's two 
additional lines for simple plugins. OTOH, the cleanup() section would be 
obsolete.

More pros and cons?

>> 3) use local, variant b)
[...]
> I think 1 or 2 are better that this !!

Yep, it felt like a good idea, while it was just in my mind, but seems pretty 
awful once written down...

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20070301/896cf1e2/attachment.sig>