Re: [rkward-devel] Dependencies and 'about' information for plugins
hi,
Am Mittwoch, 20. Februar 2013, 17:32:37 schrieb Thomas Friedrichsmeier:
> On Saturday 16 February 2013, meik michalke wrote:
> > - rk.XML.matrix()
>
> Works expect for horiz_headers / vert_headers. Try
> rk.XML.matrix ("test", vert_headers=c ("a", "b"))
oops, mixed up "sep" with "collapse", is fixed now.
> > - rk.XML.dependencies()
> > - rk.XML.dependency_check()
>
> These look ok to me. I wonder if rk.XML.dependency_check() could be made to
> rely on rk.XML.dependencies, instead of duplicating the code?
right, done.
> At first I tried testing those from the plugin_skeleton plugin
> (Export->Create RKWard plugin skeleton).
oh, well, i wasn't there just yet... in fact, rk.plugin.skeleton() didn't know
about the new placement until last night, and neither did the
skeleton plugin.
i've worked on both, try again :-)
> Error in check.deps.pckg & ((isTRUE(suggest) & identical(mode, "suggest"))
> |
>
> operations are possible only for numeric, logical or complex types
> Calls: local ... rk.plugin.skeleton -> data.frame -> XML2dependencies
the internal function XML2dependencies() still tried to fetch dependencies
from , *and* i probably misplaced a bracket of an any() call when
cleaning up.
which leads me to: the package really needs a bunch of unit tests... similar
to the XiMpLe package, they're run automatically at package checks:
http://svn.code.sf.net/p/rkward/code/trunk/rkward/packages/XiMpLe/inst/tests/tests.R
if anyone has some time to spend, please help me out here. just drop me a
note, i'll guide you through ;-)
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
Ok, next:
On Saturday 16 February 2013, meik michalke wrote:
> - rk.XML.matrix()
Works expect for horiz_headers / vert_headers. Try
rk.XML.matrix ("test", vert_headers=c ("a", "b"))
> - rk.XML.dependencies()
> - rk.XML.dependency_check()
These look ok to me. I wonder if rk.XML.dependency_check() could be made to
rely on rk.XML.dependencies, instead of duplicating the code? After all, the
only differences are the tag name, and that it adds an id.
At first I tried testing those from the plugin_skeleton plugin (Export->Create
RKWard plugin skeleton). For this, I got a warning about having
inside (but the fallback worked fine). Further, I got
Error in check.deps.pckg & ((isTRUE(suggest) & identical(mode, "suggest")) |
:
operations are possible only for numeric, logical or complex types
Calls: local ... rk.plugin.skeleton -> data.frame -> XML2dependencies
which I have not tried debugging (but the plugin files seem to be generated
alright).
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
hi,
Am Dienstag, 19. Februar 2013, 16:30:28 schrieb Thomas Friedrichsmeier:
> On Monday 18 February 2013, meik michalke wrote:
> > > > - rk.XML.switch()
[...]
> > what do you think?
>
> Looks good to me.
great.
> Ok, optionset next. I tried translating the first optionset example from the
> "primary" documentation into rkwarddev. This is what I got:
cool, i've added the example to the docs. i also changed the signatures of
rk.XML.optionset() and rk.XML.optioncolumn() a little, so that
is added to automatically (can be turned off, but this way you don't
need to call rk.XML.optiondisplay() yourself), and the id of optioncolumns
will be generated from the connected id automatically. so:
> rk.XML.optionset (
> content = list (rk.XML.optiondisplay (), rk.XML.row (firstname, lastname,
> genderselect)),
> optioncolumn = list (
> rk.XML.optioncolumn("firstnames", connect=firstname, modifier="text"),
> rk.XML.optioncolumn("lastnames", connect=lastname, modifier="text"),
> rk.XML.optioncolumn("genders", connect=genderselect)
> )
> )
is shortened to:
rk.XML.optionset(
content = list(
rk.XML.row(firstname, lastname, genderselect)),
optioncolumn = list(
rk.XML.optioncolumn(firstname, modifier="text"),
rk.XML.optioncolumn(lastname, modifier="text"),
rk.XML.optioncolumn(genderselect)
)
)
which produces:
am i correct that for the JavaScript part you will only need the
ids, but not the ones used inside ? i would then have
to tweak rk.JS.scan() accordingly.
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
Hi,
On Monday 18 February 2013, meik michalke wrote:
> > > - rk.XML.switch()
[...]
> i've simplified it now, but it's a little different from what you suggested:
[...]
> i preferred it this way because it's a little more consistent with the
> output, especially since "standard" is supposed only to be valid for
> nodes (therefore i'd find "standard=TRUE/FALSE" to indicate
> nodes a bit confusing). it's a bit more to write for
> stuff, but at the same time, the original intention of a plugin author is
> documented.
>
> what do you think?
Looks good to me. Note that the original reason to have four different tags -
true, false, case, default - as child elements of the switch is simply that
there is no good way in an XML argument, to differentiate the string "TRUE"
from a logical TRUE, or an empty string from "nothing". But your points about
readability and consistency are quite valid.
> the docs do also still need more examples.
Ok, optionset next. I tried translating the first optionset example from the
"primary" documentation into rkwarddev. This is what I got:
firstname <- rk.XML.input ("Given name(s)")
lastname <- rk.XML.input ("Family name")
genderselect <- rk.XML.radio ("Gender", options = list ("Male"=c(val="m"),
Female=c(val="f")))
rk.XML.optionset (
content = list (rk.XML.optiondisplay (), rk.XML.row (firstname,
lastname,
genderselect)),
optioncolumn = list (
rk.XML.optioncolumn("firstnames", connect=firstname,
modifier="text"),
rk.XML.optioncolumn("lastnames", connect=lastname,
modifier="text"),
rk.XML.optioncolumn("genders", connect=genderselect)
)
)
Perhaps you want to add this as a code example. The generated code was correct
for this. I did not test extensively, beyond this. However, I did try a few of
parameters, and the ones I tested worked correctly, too.
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
hi,
Am Sonntag, 17. Februar 2013, 10:57:38 schrieb Thomas Friedrichsmeier:
> I'm having lots of real-life distraction ATM, so my feedback will be coming
> in a piecemeal fashion:
no problem ;-)
> > - rk.XML.switch()
>
> Generated code looks correct to me. However,
thanks, that's the most important news :-)
> a) An example for using case and default would be really helpful.
done -- and i hope it's what is intended?
> b) Perhaps the function signature could be simplified to
>
> rk.XML.switch(condition, modifier = NULL, cases, id.name = "auto")
yeah, i was thinking about something similar when i started, but somehow lost
it. i must say it took me a good deal of thinking to understand all those new
nodes with all options and their implications, and i'm not sure whether i got
it all right, so it's well appreciated that you do some checking.
i've simplified it now, but it's a little different from what you suggested:
> # if there are exactly two cases, and their standards are logical(!)
> TRUE/FALSE, generate a true/false switch
> rk.XML.switch ("foo", cases = list (
> list (standard=TRUE, fixed_value="foo"),
> list (standardúLSE, fixed_value="bar")
> ))
this is now
rk.XML.switch ("foo", cases = list (
true = list (fixed_value="foo"),
false = list (fixed_value="bar")
))
> # otherwise a "case" switch. If the final case specification has no standard
> (or standard=NULL), make it a .
> rk.XML.switch ("foo", cases = list (
> list (standard="square", fixed_value="foo"),
> list (standard="circle", fixed_value="bar"),
> list (fixed_value="other")
> ))
and this would be:
rk.XML.switch ("foo", cases = list (
case = list (standard="square", fixed_value="foo"),
case = list (standard="circle", fixed_value="bar"),
default = list (fixed_value="other")
))
i preferred it this way because it's a little more consistent with the output,
especially since "standard" is supposed only to be valid for nodes
(therefore i'd find "standard=TRUE/FALSE" to indicate nodes a bit
confusing). it's a bit more to write for stuff, but at the same time,
the original intention of a plugin author is documented.
what do you think?
the docs do also still need more examples.
viele grüße :: m.eik
--
dipl. psych. meik michalke
institut f"ur experimentelle psychologie
abt. f"ur diagnostik und differentielle psychologie
heinrich-heine-universit"at d-40204 d"usseldorf
signature.asc
Description: This is a digitally signed message part.
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
Hi!
On Saturday 16 February 2013, meik michalke wrote:
> ok, i think i have most of the new stuff more or less implemented in
> rkwarddev now.
Great!
> could you play around with these new funtions:
I'm having lots of real-life distraction ATM, so my feedback will be coming in
a piecemeal fashion:
> - rk.XML.switch()
Generated code looks correct to me. However,
a) An example for using case and default would be really helpful.
b) Perhaps the function signature could be simplified to
rk.XML.switch(condition, modifier = NULL, cases, id.name = "auto")
# if there are exactly two cases, and their standards are logical(!)
TRUE/FALSE, generate a true/false switch
rk.XML.switch ("foo", cases = list (
list (standard=TRUE, fixed_value="foo"),
list (standard=FALSE, fixed_value="bar")
))
# otherwise a "case" switch. If the final case specification has no standard
(or standard=NULL), make it a .
rk.XML.switch ("foo", cases = list (
list (standard="square", fixed_value="foo"),
list (standard="circle", fixed_value="bar"),
list (fixed_value="other")
))
(If it wasn't for the optional "modifier" argument, cases could even be passed
through a "..." argument, which would remove the need for a nested list).
Regards
Thomas
signature.asc
Description: This is a digitally signed message part.
--
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
is your hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials, tech docs,
whitepapers, evaluation guides, and opinion stories. Check out the most
recent posts - join the conversation now. http://goparallel.sourceforge.net/___
RKWard-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
hi, Am Dienstag, 5. Februar 2013, 12:05:40 schrieb Thomas Friedrichsmeier: > > well, the package needs a function for the new matrix element anyway. i > > hope it won't take me too long. > > ... and the new element, and :-). ok, i think i have most of the new stuff more or less implemented in rkwarddev now. could you play around with these new funtions: - rk.XML.switch() - rk.XML.optionset() - rk.XML.matrix() - rk.XML.dependencies() - rk.XML.dependency_check() especially to see if they produce the code they're supposed to? you don't need to write full plugins or any files, the XML code will be printed in the console if you call the resulting objects. viele grüße :: m.eik -- dipl. psych. meik michalke abt. f"ur diagnostik und differentielle psychologie institut f"ur experimentelle psychologie heinrich-heine-u iversit"at pgpR5BTvQMsAR.pgp Description: This is a digitally signed message part. -- The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/___ RKWard-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
Hi, On Monday 04 February 2013, meik michalke wrote: > oops, this will take some time, as it will require changes in several parts > of rkwarddev. it will also break backwards compatibility, previous scripts > will have to be changed (e.g., the "dependencies", "package" and > "pluginmap" arguments of rk.XML.about() need to be transformed into a > function of its own). well, if it causes a _lot_ of trouble, that change is certainly debateable. My reasons were: - It is a rather different kind of data, compared to the other info in . - Dependencies should always be handled in the .pluginmap for performance reasons: It avoids having to parse each individual plugin xml file on startup. In contrast, the data can be lazy-loaded, later, and it makes some sense to allow it on the level of plugin xml files, too. - The shares its syntax with , which is another indication that this is a rather "independent" element. Perhaps some (transitory) backwards compatibility could be kept, by keeping "dependencies", "packages", and "pluginmap" in rk.XML.about() with a warning, and smartening up rk.xml.plugin(map) to look at dependencies inside about data, if (missing(dependencies)). > i will look into it. i'm not sure if this also requires rather complex > internal changes. currently, the namespace "rkward" is hardwired in > rk.XML.pluginmap(). One option might be to simply set namespace = name. It does not really have a meaning other than to avoid name clashes (internally, the id of pluginmaps becomes "namespace::id"). As it was not possible to pluginmaps by their id, before, this should not cause any compatibility issues. > well, the package needs a function for the new matrix element anyway. i > hope it won't take me too long. ... and the new element, and :-). Talking about the timeline, R 3.0.0 (scheduled for March/April 2013) will come with a few changes that will break RKWard 0.6.0. So we will have to target a new release of RKWard around that time, too. This could be a minimal maintainance release, but I'd certainly prefer a "real" release. Don't worry, I don't have plans for any further new xml elements before the next release... (for the release _after_ that, I'd like to tackle the problem of querying R for information such as factor levels from inside a plugin). > btw, XiMpLe and roxyPackage are on CRAN now, did i mention that? Not as far as I remember. Cool! Regards Thomas signature.asc Description: This is a digitally signed message part. -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb___ RKWard-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkward-devel
Re: [rkward-devel] Dependencies and 'about' information for plugins
hi, Am Montag, 4. Februar 2013, 19:13:32 schrieb Thomas Friedrichsmeier: > As a quick reference for what will need to be covered in rkwarddev: > - is a direct child of , not of . It can > also be specified per oops, this will take some time, as it will require changes in several parts of rkwarddev. it will also break backwards compatibility, previous scripts will have to be changed (e.g., the "dependencies", "package" and "pluginmap" arguments of rk.XML.about() need to be transformed into a function of its own). > - gains a new parameter "map", for including plugin maps from > different packages > - new element for providing more compatiblity inside > plugins > - new parameter "priority" in the element of .pluginmap files. > Controls whether newly installed pluginmaps will be activated by default. ok, that shouldn't be too hard. > - Contrary to what the documentation may have suggested, before, it is a > good idea to set the "namespace" of .pluginmaps to something unique, > instead of "rkward". At least, if you want to make it possbile for others > to your .pluginmaps. i will look into it. i'm not sure if this also requires rather complex internal changes. currently, the namespace "rkward" is hardwired in rk.XML.pluginmap(). well, the package needs a function for the new matrix element anyway. i hope it won't take me too long. i'll probably write some proper "get" and "is" methods for the XiMpLe package first, to get rid of some ugly passages in the rkwarddev code, while i'm at it. btw, XiMpLe and roxyPackage are on CRAN now, did i mention that? viele grüße :: m.eik -- dipl. psych. meik michalke institut f"ur experimentelle psychologie abt. f"ur diagnostik und differentielle psychologie heinrich-heine-universit"at d-40204 d"usseldorf signature.asc Description: This is a digitally signed message part. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan___ RKWard-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkward-devel
[rkward-devel] Dependencies and 'about' information for plugins
Hi! Over the past two weeks, I've been working on providing some basic handling of dependencies and 'about' information for plugins. Esp. concerning dependencies, there is certainly room for further improvements, but I think for the moment, this should cover the most important bits. Not all of this is all new, as Meik had already blueprinted a syntax for specifying dependencies and 'about' data. But I have made a few changes while working on the implementation, and added some bits here and there. You can read up on everything at http://rkward.sourceforge.net/documents/devel/plugins/chapter_dependencies.html and the following chapter. As a quick reference for what will need to be covered in rkwarddev: - is a direct child of , not of . It can also be specified per - gains a new parameter "map", for including plugin maps from different packages - new element for providing more compatiblity inside plugins Also, somewhat unrelated, but not entirely so: - new parameter "priority" in the element of .pluginmap files. Controls whether newly installed pluginmaps will be activated by default. And another hint: - Contrary to what the documentation may have suggested, before, it is a good idea to set the "namespace" of .pluginmaps to something unique, instead of "rkward". At least, if you want to make it possbile for others to your .pluginmaps. Regards Thomas signature.asc Description: This is a digitally signed message part. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan___ RKWard-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rkward-devel
