rkward-devel — Discussion of RKWard development

[rkward-devel] Quering R from dialogs

[SANCHEZ A. A. <as...@ce...>]

Hi and Happy New Year for everybody!
I've been trying to use the new property for querying R from dialogs (http://api.kde.org/doc/rkwardplugins/querying_r_for_info.html). As my requirements (for the moment) are only to list the levels of a factor, I've tried to embed the rkward::level_select plugin, but it doesn't work, exept if you embed it inside a optionset.
For example, the following dialog works perfectly

<!DOCTYPE rkplugin>
<document>
        <code file="example.js" />
        <logic>
                <connect governor="x.available" client="set.contents.levels.variable" />
        </logic>
        <dialog label="Example">
                <varselector id="vars" />
                <varslot id="x" source="vars" label="Select variable" num_dimensions="1" required="true" />
                <optionset id="set" min_rows="1" >
                        <content>
                                <row>
                                        <embed id="levels" component="rkward::level_select" />
                                        <valueslot required="true" id="values" label="" source="levels.selector" />
                                </row>
                        </content>
                </optionset>
        </dialog>
</document>

But if you put the embed outside the optionset, it fails.

Probably I don't have a full understanding of the mechanism to query R. ¿What I'm doing wrong?
Thanks!


Este mensaje y sus archivos adjuntos, enviados desde FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU, pueden contener información confidencial y está destinado a ser leído sólo por la persona a la que va dirigido por lo que queda prohibida la difusión, copia o utilización de dicha información por terceros. Si usted lo recibiera por error, por favor, notifíquelo al remitente y destruya el mensaje y cualquier documento adjunto que pudiera contener.

En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, le recordamos que podrá en todo momento ejercitar los derechos de acceso, rectificación, cancelación y oposición sobre sus datos personales que hayan podido ser incorporados en nuestros ficheros a través del envío de un correo electrónico al remitente, especificando en el cuerpo del mensaje la dirección de e-mail sobre la que desea ejercitar su derecho.

Cualquier información, opinión, conclusión, recomendación, etc. contenida en el presente mensaje no relacionada con la actividad de FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU y/o emitida por persona sin capacidad para ello, deberá considerarse como no proporcionada ni aprobada por FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU, que pone los medios a su alcance para garantizar la seguridad y ausencia de errores en la correspondencia electrónica, pero no puede asegurar la inexistencia de virus o la no alteración de los documentos transmitidos electrónicamente, por lo que declina cualquier responsabilidad a este respecto.

This message and its attachments, sent from FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU, may contain confidential information and is intended to be read only by the person to which it is directed. Therefore any disclosure, copying or use by third parties of this information is prohibited. If you receive this in error, please notify the sender and destroy the message and any attachments that it may contain.

In compliance with Law 15/1999, December 13, of Personal Data Protection, we remind you that you may at any time exercise your rights of access, rectification, cancellation and opposition of your personal data that may have been stored in our files by sending an e- mail to the sender, specifying the message body of the e-mail address on which you wish to exercise your right.

Any information, opinion, conclusion, recommendation,... contained in this message and which is unrelated to the business activity of FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU and/or issued by unauthorized personnel, shall be considered unapproved by FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU. FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU implements control measures to ensure, as far as possible, the security and reliability of all its electronic correspondence. However, FUNDACIÓN UNIVERSITARIA SAN PABLO-CEU does not guarantee that emails are virus-free or that documents have not be altered, and does not take responsibility in this respect.

Re: [rkward-devel] power analysis plugin

[Thomas F. <tho...@ru...>]

Hi,

On Tue, 14 Oct 2014 12:44:09 +0200
meik michalke <mei...@un...> wrote:
> Am Montag, 6. Oktober 2014, 20:28:45 schrieb Thomas Friedrichsmeier:
> > - Providing better control over which plugins are active. I'm still
> > not convinced, the level of individual plugins is (typically) the
> > right granularity of control, but in fact, control should be more
> > fine-grained than  the current "official" pluginmaps, and esp. more
> > fine-grained than simply using all.pluginmap, by default.
> 
> are there R functions yet to enable/disable plugins? you know, if
> there were, in combination with rk.list.plugins() i could simply
> write my own plugin for that control.

here you go, finally: rk.set.plugin.status(). So far, the only thing
that can be controlled is visibility. More could be added to that
interface, if there is a real need for that, but initially, this should
cover the most important bit.

So: Your turn, now ;-)

> a function which lists all meta (like <about>, <dependencies> and
> info on the menu structure) information on plugins would also be
> great, because the name alone doesn't explain so much.

rk.list.plugins() now lists a lot more information. Dependencies, and
most of about is not yet included, and I guess it does not make too
much sense to include all of this? (In fact, plugins with unmet
dependencies will not even be visible in rk.list.plugins(); users do
get a warning when loading a pluginmap with a plugin with unmet
dependencies, though). Let me know about the bits you'd like to use in
your "meta-plugin". Most should be easy enough to add.

Regards
Thomas

Re: [rkward-devel] rk.load.pluginmaps() broken?

[Thomas F. <tho...@ru...>]

Hi,

On Sat, 03 Jan 2015 14:00:14 +0100
meik michalke <mei...@un...> wrote:
> i was just testing the reworked plugin administration -- looks really
> great!

glad you like it. Be sure to take a look at the new
return value of rk.list.plugins(), too. R API to hide plugins (by
plugin, not pluginmap) should arrive, soon.

> i'm unsure whether this is related to a recent bug in
> rk.load.pluginmaps()? it doesn't seem to finish its work -- i see a
> plugin loaded with the function in the plugin configuration, its
> "active" checkbox is checked, but its "state" column remains empty.

Should be fixed, now.

Regards
Thomas

[rkward-devel] rk.load.pluginmaps() broken?

[meik m. <mei...@un...>]

hi,

i was just testing the reworked plugin administration -- looks really great!

i'm unsure whether this is related to a recent bug in rk.load.pluginmaps()? it 
doesn't seem to finish its work -- i see a plugin loaded with the function in 
the plugin configuration, its "active" checkbox is checked, but its "state" 
column remains empty. i have to manually
 - uncheck "active"
 - click "apply"
 - check "active"
 - click "apply"
for the plugin to actually show a "state" of "loaded" and the dialog to appear 
in the menu.


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

Re: [rkward-devel] Asking Developer Help

[Thomas F. <tho...@ru...>]

Hi,

On Fri, 19 Dec 2014 23:11:42 +0700
Jodi Jhouranda Siregar <11...@st...> wrote:
> Dear RKWard developer.
> I want to ask some help from you. my team is in final project of my
> bachelor study in indonesia. we decided to develop an open source
> statiscal software especially for spatial analysis and use R as it's
> backend. we met a problem to emmbed R engine in our software just
> like what you guys did in RKWard. we have been tried to look into
> your available source code and we still don't know how you guys did
> it. hopes you can help me in our final research.

the best high-level writeup of RKWard design is this article in
jstatsoft: http://www.jstatsoft.org/v49/i09 . You'd want to look at the
appendix, in particular. To give you a very general idea on where to
find the most central bits:

- rkward/rbackend/FindR.cmake and rkward/rbackend/CMakeLists.txt for
configuring the build
- rkward/rbackend/rkbackendprotocol_backend.cpp for setting up the
backend process
- rkward/rbackend/rkrbackend.cpp for actually starting / intializing the
R engine and doing work in R
- rkward/rbackend/rkrbackend_transmitter.cpp for passing messages to
the frontend.

That said, it's hard to tell without knowing more details, but RKWard
may be rather more complex than what you need. Much of that complexity
is for being able to run commands just like they had been typed into an
interactive R console. Another part of the complexity comes from
running the R engine and the frontend asynchronously (and in separate
processes). If you don't need either of this, embedding R will be
considerably easier. You might want to look at Rcpp. And I assume you
are familiar with the relevant section in the R-exts manual:
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Linking-GUIs-and-other-front_002dends-to-R .

I think those are the best pointers, I can give, right now. If you have
more specific questions about embedding R, feel free to ask.

Regards
Thomas

[rkward-devel] Asking Developer Help

[Jodi J. S. <11...@st...>]

Dear RKWard developer.
I want to ask some help from you. my team is in final project of my
bachelor study in indonesia. we decided to develop an open source statiscal
software especially for spatial analysis and use R as it's backend. we met
a problem to emmbed R engine in our software just like what you guys did
in RKWard. we have been tried to look into your available source code and
we still don't know how you guys did it. hopes you can help me in our final
research.

Regards,
Jodi Jhouranda Siregar
Statistical University, Indonesia
Faculty of Computational Statistic
www.stis.ac.id

Re: [rkward-devel] indentation conventions

[Thomas F. <tho...@ru...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, 18 Dec 2014 15:45:16 +0100
meik michalke <Mei...@un...> wrote:
> Am Donnerstag, 18. Dezember 2014, 14:27:30 schrieb Thomas
> Friedrichsmeier:
> > For KDE, different projects use different styles, already (and tabs
> > vs. space are not the only style-question, of course).
> 
> yes, i took this particular one because there seems to be a broad
> consensus among many coding conventions to not using tabs.
> 
> > Importantly, git blame will stop on such changes, even if the code
> > is otherwise untouched.
> 
> there's an option -w to ignore whitespace changes, so blame would
> still work.

Ah, good to know.

> it'd even be possible to commit these changes in a way
> that they "look" as if they were always there:
> http://stackoverflow.com/questions/3945382/git-commit-that-doesnt-override-original-authors-in-git-blame

That's using an evil rewrite of history, though.

> i'm ok with keeping things as they are, though.

Yes, I'd say it's not worth the trouble (for the C++-code; again, for
R code, the answer may be different). My impression is that nowadays the
holy war between tabs and spaces has cooled down, considerably. Probably
because modern editors are both, smart enough to allow indenting with
four spaces at a single key-press, _and_ to distinguish tabs and spaces,
visually.

I do confess there are some instances of mis-used tabs in RKWard,
though, i.e. to align end-of-line comments, which is simply wrong. I
never cared enough to figure out, how to replace those.

Again, though, _if_ we were to change tabs to spaces, there would be
more style questions to take care of at the same time. Things like
{} on the same line as if/else, or on different lines, spaces inside
and outside parentheses, etc. Not sure, if git blame -w could handle
all of these...

Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUkxxPAAoJEDkVkd8YWMu2j9cQAKZocGNZ4KOqBdxhXxMVmyKW
FdgVtcLFT8USq4dqYzoVroDVE29dmBwOR9m5OUF9xa8YZnkGhVN4VItsFuPGR6uA
ZdkhonZr/8d8iCFH7eblGWtQsTlCl47Q5I3SkMdfU8IFTgfm5mmGgc+qrf2yh/yi
kBDAp3mc20umVNVTJfZmc0DuUBvmt2NcjVT4lqFTZjf+oz6wZKx/mMFpPd6eBDfE
MtG0ATla5s+TBBEh6easHBhIldiE3Uaq6xTz9gxGuWhD0OTzTBnax1ec0RcAmfvW
/rjsfSBxotxD9xNyIRcHLcWO9BAxGgRl0m0DCXfemChko7MPXM8E+KnzyiFKS8m4
ZZp7hYcAN0bPdfHX1dqnMBawLMJ5+a1WwE/QfxAWccxxtkGAL5tRgTURiMqrvzAF
fH5QE8ZjTMY4bN3u+hyoKTrMKJsY6PuXPLXYFbXFUysrjM+R2xeyVxrCJ/mOQJvp
1o1QWyoYOTedo4ekrMl6FhJMH1kn9MpRUoRI96oXu2JReXFONC3cS8dK/nFQz6v7
Qw+jwOJlkOq+jGAcV6a+lzMVEXzs+1EPPTR3KCUPpwS4MwRUSD1fPRXbwt8BO2k0
UnxoSKW9nGZh7Z7VfqHHQHvr+Gwc/+o86oDrpqMdeMjOvcbT0oy1ea6BWXQ5IODD
5Q32045BKj56HqwzeYD0
=zRFi
-----END PGP SIGNATURE-----

Re: [rkward-devel] indentation conventions

[meik m. <Mei...@un...>]

hi,

Am Donnerstag, 18. Dezember 2014, 14:27:30 schrieb Thomas Friedrichsmeier:
> For KDE, different projects use different styles, already (and tabs vs.
> space are not the only style-question, of course).

yes, i took this particular one because there seems to be a broad consensus 
among many coding conventions to not using tabs.

> Importantly, git blame will stop on such changes, even if the code is
> otherwise untouched.

there's an option -w to ignore whitespace changes, so blame would still work. 
it'd even be possible to commit these changes in a way that they "look" as if 
they were always there:
http://stackoverflow.com/questions/3945382/git-commit-that-doesnt-override-original-authors-in-git-blame

i'm ok with keeping things as they are, though.


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

Re: [rkward-devel] indentation conventions

[Thomas F. <tho...@ru...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, 18 Dec 2014 11:35:53 +0100
meik michalke <mei...@un...> wrote:
> so far we seem to use tabs for indentation of code. for kdelibs, 4
> spaces instead of one tab is recommended:
>  https://techbase.kde.org/Policies/Kdelibs_Coding_Style
> the same seems to apply for R code (though 2 spaces are also fine):
>  http://cran.r-project.org/web/packages/rockchalk/vignettes/Rstyle.pdf
> 
> is this something we should care about?

For KDE, different projects use different styles, already (and tabs vs.
space are not the only style-question, of course). I'm not particularly
attached to the style we're using, but changing styles is always
somewhat problematic. Importantly, git blame will stop on such changes,
even if the code is otherwise untouched. (Arguably, git gui blame is
comfortable enough to live with this). Either way, I'd vote against
changing this, unless there are compelling reasons, _and_ a very clear
definition of what the new style should be.

For R, the case may in fact be somewhat different, esp. as the
recommended style is also what you get from deparsing / printing R
functions. Not sure, whether it would be possible to use "astyle" to
convert package code, automatically. Adjusting plugin generated code
would probably require some manual work. Sure, tabs can simply be
replaced, but perhaps there are some - few - instances of tabs worth
keeping (inside strings, for example)?

Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJUktZCAAoJEDkVkd8YWMu2FQoP/1wZQ64NtCMnvvr11/F2l4gl
0inK9kQ9RiPM/djRCtiKZ5AiC0AbZaZBtU5johr45IBZQUR/Ui5ucvPxT4CQo5VQ
R/asOy2BJ0HQkGqmQhepuSPrp2kmojqvoJ1utodX/Vw40QKnWGPURoi0gMLD8GZt
Fy3kvxbm8jEDYgDlE2D5twlyQ9PPjdL44UB0lFlT/Vnvla/BwSBwaEsnljeGqMjj
nEuM7t+HscRKTVkO6idPHK9YVB4pYxYiunHamZ5B+cSvSf+igcZL0qvoE0ZUPD/+
YwTbkuCku4r5r5ypB7JKCOjTE7JUop/pSTKzF83MXbYwhOzgXNYXafRYBR0amFFj
NbM88xta7frAlfibMfFLz9UOFBfcS4vYP8M5UOGU2H2FFBa0Alry6i/xhtfIXKuK
81Rc3suNV8PaFK3YZoYX7RiqjCqQ1SZg1RqrQK9/225j+cXXjQzDpnW8XrVSNj04
GJteppuxtpvyU9wknawaox88qZbCQIEF5LJzHAIn1X73zSryl/nwCcs0UL/xRKvf
nK30uQ/3Wjxw4kvcc+ed0XCSgf9DhmpiLGOMlc8RQXFxniuulwLGq+rJcD9onU/g
RyHgZKxxBfPhDXANuSGgbQeout9JSTYYgtQtoIVZ6mARBWGtfi5uATrVq33JfExe
YcpjhaSINn85gUtV1bzO
=phGC
-----END PGP SIGNATURE-----

[rkward-devel] indentation conventions

[meik m. <mei...@un...>]

hi,

so far we seem to use tabs for indentation of code. for kdelibs, 4 spaces 
instead of one tab is recommended:
 https://techbase.kde.org/Policies/Kdelibs_Coding_Style
the same seems to apply for R code (though 2 spaces are also fine):
 http://cran.r-project.org/web/packages/rockchalk/vignettes/Rstyle.pdf

is this something we should care about? at least, i'll try to clean up my R 
packages in the near future, to comply with this rule.


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

Re: [rkward-devel] Some minor issues in the plugin translation implementation

[Thomas F. <tho...@ru...>]

Hi,

On Sunday 07 December 2014 09:30:40 Yuri Chornoivan wrote:
> 1. Due to Gettext implementation, all translations with i18n_context
> cannot be loaded. Maybe it is worth to remove the context as it adds
> nothing to the translator interpretation of the messages. Examples:
> "Moments" submenu in the "Analysis" menu with context "Statistics",
> "against (optional)" in Wilcoxon/Mann-Whitney tests window.

should be fixed, now. The code was simply trying to look up the message with 
the wrong context ("i18n_context", instead of the value of the attribute).

I'm glad to know that the context is generally not needed (as most plugins 
don't provide any context for any of their strings at all), but I think it 
will still be good to have the feature available for those cases, where there 
are real ambiguities.
 
> 2. id's of <radio> tags translations cannot be loaded. Example: "using
> test hypothesis" in Wilcoxon/Mann-Whitney tests window.

Fixed, too. Simply a missing i18n-lookup. Just let me know, if you come across 
any further issues of this kind.

Regards
Thomas

[rkward-devel] Some minor issues in the plugin translation implementation

[Yuri C. <yu...@uk...>]

Hi,

First of all, many thanks for making plugins translatable.

Just some minor issues that spoiled the initial implementation a bit:

1. Due to Gettext implementation, all translations with i18n_context  
cannot be loaded. Maybe it is worth to remove the context as it adds  
nothing to the translator interpretation of the messages. Examples:  
"Moments" submenu in the "Analysis" menu with context "Statistics",  
"against (optional)" in Wilcoxon/Mann-Whitney tests window.

2. id's of <radio> tags translations cannot be loaded. Example: "using  
test hypothesis" in Wilcoxon/Mann-Whitney tests window.

Many thanks in advance for paying some attention to these issues.

Best regards,
Yuri

Re: [rkward-devel] Moving to KDE.org

[Mario F. <kd...@un...>]

Am Dienstag, 11. November 2014, 14.00:51 schrieb Thomas Friedrichsmeier:
> Hi once more,

Morning

> On Thursday 06 November 2014 19:44:12 Nicolás Alvarez wrote:
> > Non-fast-forward pushes (force pushes) and branch deletions are only
> > allowed for the "repository owners". You'll have to decide who that
> > will be.
> 
> I guess I'll state that in the ticket, whenever I request the repository to
> be moved to playground, right? (Mario, or would we go for kdereview,
> directly?)

I think that's done now, right? It looks like it's playground.

> Also one more admin question: So far we had a dedicated mailing list for
> SCM- commits. That was quite convenient. And in fact, it would be even
> more convenient, if we had merged it in one list with build bot
> notifications(*). That would make it easy for all developers to subscribe
> to a single pack of "all that noise" that is relevant to those who commit,
> but not so much for other interested bystanders. I'm sort of hoping to
> achieve this as part of the transition to KDE.org.

I think other KDE projects go in this direction as well. One development list 
and one noisy, commits, rr, etc. list.

> Now the KDE way of doing things seems to be using commitfilter.kde.org.
> 
> Some questions:
> - Is is possible to direct commitfiltered mail to a mailing list? (Or will
> commitfilter mail out password reminders and some such?)
> - Alternatively, is it possible to set up custom notification hooks on a
> git repo on KDE.org?

I think so. But KDE sysadmins know for sure.

> - Or is the list I have in mind a poor plan, in the first place?
> 
> Regards
> Thomas
> 
> (*) Potentially also bug tracker notifications, although perhaps it makes
> more sense for those to go to rkward-devel, after all.

griits
Mario

Re: [rkward-devel] c-formatted strings in rkward__analysis.po

[Albert A. C. <aa...@kd...>]

El Dijous, 4 de desembre de 2014, a les 21:39:14, Yuri Chornoivan va escriure:
> Hi,
> 
> Due to some subtle peculiarities of xgettext processing some extracted
> strings (those with '%') are now wrongly c-formatted which prevents them
>  from to be translated well.
> 
> #. i18n: file: rkward/plugins/analysis/t_test.xml
> #. i18n: ectx: (t-Test) <wizard label="Two Variable t-Test"> <page> <text>
> #, c-format
> msgid ""
> "Below you can specify whether one should be shown, and which confidence-"
> "level should be applied (95% corresponds to a 5% level of significance)."
> 
> #. i18n: file: rkward/plugins/analysis/variances/F_test.rkh
> #. i18n: ectx: (Loaded from F test) <settings> <setting> (refers to
> element labelled "Confidence level")
> #, c-format
> msgid "Defines the confidence level of the interval (95% is typical)."
> 
> #. i18n: file:
> rkward/plugins/analysis/ansari_bradley/ansari_bradley_test.rkh
> #. i18n: file:
> rkward/plugins/analysis/ansari_bradley/ansari_bradley_exact_test.rkh
> #, c-format
> msgid ""
> "Here you can define the confidence level of the interval (95% is
> typical)."
> msgstr ""
> 
> #. i18n: ectx: (Loaded from N to 1 Crosstabulation)
> #: rkward/plugins/analysis/crosstab.js:51
> #: rkward/plugins/analysis/crosstab.js:58
> #, c-format
> msgid "% of row"
> 
> #. i18n: ectx: (Loaded from N to 1 Crosstabulation)
> #: rkward/plugins/analysis/crosstab.js:52
> #: rkward/plugins/analysis/crosstab.js:59
> #, c-format
> msgid "% of column"
> 
> #. i18n: ectx: (Loaded from N to 1 Crosstabulation)
> #: rkward/plugins/analysis/crosstab.js:53
> #: rkward/plugins/analysis/crosstab.js:60
> #, c-format
> msgid "% of total"
> 
> It is usually enough to add "xgettext:no-c-format" for such messages to be
> processed right, but it is evidently not the case this time (tested).

How did you test this? Modifying scripts/update_plugin_messages.py ?

Cheers,
  Albert

> 
> Is there any way to post-process the file to replace #, c-format with #,
> no-c-format ?
> 
> Thanks in advance for your answers.
> 
> Best regards,
> Yuri

Re: [rkward-devel] c-formatted strings in rkward__analysis.po

[Thomas F. <tho...@ru...>]

Hi,

On Thursday 04 December 2014 21:39:14 Yuri Chornoivan wrote:
> Due to some subtle peculiarities of xgettext processing some extracted
> strings (those with '%') are now wrongly c-formatted which prevents them
>  from to be translated well.

I see.

> It is usually enough to add "xgettext:no-c-format" for such messages to be
> processed right, but it is evidently not the case this time (tested).

I guess that's because the extraction script just strips all comments that 
don't start with i18n: or translators:.

> Is there any way to post-process the file to replace #, c-format with #,
> no-c-format ?

I've tried smartening up the extraction script to insert /* xgettext:no-c-
format */ in front of the calls in question (after all comment stripping). 
This seems to produce the desired result. Please test.

Thanks!
Thomas

[rkward-devel] c-formatted strings in rkward__analysis.po

[Yuri C. <yu...@uk...>]

Hi,

Due to some subtle peculiarities of xgettext processing some extracted  
strings (those with '%') are now wrongly c-formatted which prevents them  
 from to be translated well.

#. i18n: file: rkward/plugins/analysis/t_test.xml
#. i18n: ectx: (t-Test) <wizard label="Two Variable t-Test"> <page> <text>
#, c-format
msgid ""
"Below you can specify whether one should be shown, and which confidence-"
"level should be applied (95% corresponds to a 5% level of significance)."

#. i18n: file: rkward/plugins/analysis/variances/F_test.rkh
#. i18n: ectx: (Loaded from F test) <settings> <setting> (refers to  
element labelled "Confidence level")
#, c-format
msgid "Defines the confidence level of the interval (95% is typical)."

#. i18n: file:  
rkward/plugins/analysis/ansari_bradley/ansari_bradley_test.rkh
#. i18n: file:  
rkward/plugins/analysis/ansari_bradley/ansari_bradley_exact_test.rkh
#, c-format
msgid ""
"Here you can define the confidence level of the interval (95% is  
typical)."
msgstr ""

#. i18n: ectx: (Loaded from N to 1 Crosstabulation)
#: rkward/plugins/analysis/crosstab.js:51
#: rkward/plugins/analysis/crosstab.js:58
#, c-format
msgid "% of row"

#. i18n: ectx: (Loaded from N to 1 Crosstabulation)
#: rkward/plugins/analysis/crosstab.js:52
#: rkward/plugins/analysis/crosstab.js:59
#, c-format
msgid "% of column"

#. i18n: ectx: (Loaded from N to 1 Crosstabulation)
#: rkward/plugins/analysis/crosstab.js:53
#: rkward/plugins/analysis/crosstab.js:60
#, c-format
msgid "% of total"

It is usually enough to add "xgettext:no-c-format" for such messages to be  
processed right, but it is evidently not the case this time (tested).

Is there any way to post-process the file to replace #, c-format with #,  
no-c-format ?

Thanks in advance for your answers.

Best regards,
Yuri

Re: [rkward-devel] [rkward-cvs] [rkward] rkward/plugins/00saveload/save: oops, setting an empty label for <browser> also made .addFromUI() produce an empty variable name and by that an infinte loop. maybe add a check to the JS function?

[Thomas F. <tho...@ru...>]

Hi,

On Thursday 04 December 2014 14:41:01 m. eik michalke wrote:
> oops, setting an empty label for <browser> also made .addFromUI() produce an
> empty variable name and by that an infinte loop.

hm. Two issues, here:
1) When parsing a command like 
  list(""=1)
R seems to resort to a strange hack to make this fail. In essence, this causes 
R to jump back to its top-level loop, while we did not expect it (other parse 
errors are handled in a less drastic manner). Should now be fixed, i.e. only a 
regular error, not RKWard going into an endless loop. Fortunately this only 
affected commands that are _not_ treated as user-commands in RKWard.

2) I got confused about where the label comes from. What I meant to suggest 
was rather: Keep the label on the <browser>, drop the "Save to"-label from the 
<frame> around it. That would allow you to continue using addFromUI(). 
However, it really does not matter, either way.

Regards
Thomas

[rkward-devel] New message template rkward__analysis.pot

[Thomas F. <tho...@ru...>]

Hi!

I have just pushed a commit to RKWard's Messages.sh that should result in a 
new .pot-file appearing on the next run of scripty: rkward__analysis.pot. Some 
words of explanation:

1) This is a catalog in addition to rkward.pot. It contains messages from one 
group of RKWard plugins. More such catalogs are going to appear. However, 
firstly, this will need some more work from our side (marking up i18n'able 
strings), and secondly, I'd like to hear if there is anything systematically 
wrong with the extracted messages, before adding the rest.
2) Most of this is old code that has just become i18n'able for the first time, 
and was not written with i18n in mind. I'm afraid there are going to be quite 
a bunch of messages that need to be given context. Please let us know (rkward-
devel mailing list in CC). Or, if you prefer doing changes, yourself: You can 
add context to the messages extracted from XML files by adding an attribute 
i18n_context="something" to the element in question. In our .js files, 
i18n/c/p/cp() are available.
3) The global context to assume is statistics. Please be on the watch-out for 
strings that could be statistical terms. Some of the catalogs to come are 
going to be easier in this respect, but some are going to be considerably more 
specialized. It's no dishonor to pass on catalogs that are outside your area 
of expertise. (Is it possible to add such a "warning" to a .pot-file?)
4) As RKWard plugins are not necessarily installed to a standard system path, 
neither are the corresponding catalogs. If you want to test your translations, 
place them in a subdirectory 
  i18n/plugins
in RKWards sources. Follow the naming scheme
  i18n/plugins/rkward__analysis.XY.po
(where XY is your language code). "make install" will install the catalog as 
appropriate. (Note: This may be subject to change in the mid term). 
rkward__anaylsis.pot corresponds - roughly(!) - to the "Analysis" top level 
menu.

Regards
Thomas

Re: [rkward-devel] [rkward-cvs] [rkward] rkward/plugins: added the new table/CSV export dialog for better testing. also added a help page and included the generator script.

[Thomas F. <tho...@ru...>]

Hi!

Just a small random catch:

On Tuesday 02 December 2014 21:54:50 m. eik michalke wrote:
> +       var quote = getBoolean("quote");

This works, and is ok. However, the canonical way to deal with checkbox-
options is using

  getBoolean("quote.state")

and not specifying any value in the <checkbox>-control, since version 0.6.1.

Regards
Thomas

Re: [rkward-devel] import/export CSV

[Thomas F. <tho...@ru...>]

Hi,

On Tuesday 02 December 2014 11:46:52 meik michalke wrote:
> shuffling around elements is no problem, i'll try something. however:
> > - Set the labels of the inputs for custom dec/sep to "" (these are
> > definitely expendable, IMO)
> > - Set the label of the file name selector to "". Probably
> > self-explanatory.
> 
> that could actually help, if i manage to get rkwarddev to write empty
> strings into its objects... currently, it leaves the labels out and RKWard
> auto-fills them.

I see. Would it have any negative side-effect, if you just remove the check 
for nchar > 0 in pasteXMLAttr?
 
> generally: should i simply already add the XML and JS file to git already?
> if so, should i also put the rkwarddev script somewhere there, or would you
> like to have its results, only?

I'm still not sure what is the best way to handle this. But we already have 
one rkwarddev script in plugins/rkwarddev_scripts, and so you can simply 
follow that path for now.

Of course, having both in git is potentially asking for trouble. Sooner or 
later someone (or a script) will overlook the warning at the top of the 
generated files, and make changes, there, which are not represented in the 
rkwarddev-script. Ideally, rkwarddev-based plugins would be generated during 
cmake, somehow(*), and git-ignored...

Regards
Thomas

(*): But that is not trivial, either
- Should work without prior installation of XiMpLe and rkwarddev
- Need to make sure the generated files go to the correct location
- Should ideally detect and warn about edits by hand (perhaps by storing a 
timestamp inside the generated file, or something)

Re: [rkward-devel] import/export CSV

[meik m. <mei...@un...>]

hi,

thanks for the fast feedback.

Am Dienstag, 2. Dezember 2014, 09:59:12 schrieb Thomas Friedrichsmeier:
> On Monday 01 December 2014 22:11:39 meik michalke wrote:
> > here's a refined version, what do think of the restructured comments?
> 
> definitely better, IMO. I'd suggest also putting all implicit paramteres on
> a single line of the comment, though, so the comment does not push the
> actual code out of sight.

ok, fixed.

> Some more small items:
> - When specifying custom sep / dec, that generates sep="other"/dec="other".

oops... fixed.

> - "Quote all values" would more appropriately be labelled "Quote all
> strings"

fixed.

> - Typo on <varselector>-label: "varaible"

fixed.

> Again, I think it may make sense to move the format specs to the first tab
> (and file encoding somewhere else). Sure, that makes for a rather largish
> dialog, but I think it's still just acceptable.

shuffling around elements is no problem, i'll try something. however:

> - Set the labels of the inputs for custom dec/sep to "" (these are
> definitely expendable, IMO)
> - Set the label of the file name selector to "". Probably self-explanatory.

that could actually help, if i manage to get rkwarddev to write empty strings 
into its objects... currently, it leaves the labels out and RKWard auto-fills 
them.

generally: should i simply already add the XML and JS file to git already? if 
so, should i also put the rkwarddev script somewhere there, or would you like 
to have its results, only?


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

Re: [rkward-devel] import/export CSV

[Thomas F. <tho...@ru...>]

Hi,

On Monday 01 December 2014 22:11:39 meik michalke wrote:
> here's a refined version, what do think of the restructured comments?

definitely better, IMO. I'd suggest also putting all implicit paramteres on a 
single line of the comment, though, so the comment does not push the actual 
code out of sight.

Some more small items:
- When specifying custom sep / dec, that generates sep="other"/dec="other".
- "Quote all values" would more appropriately be labelled "Quote all strings"
- Typo on <varselector>-label: "varaible"

Again, I think it may make sense to move the format specs to the first tab 
(and file encoding somewhere else). Sure, that makes for a rather largish 
dialog, but I think it's still just acceptable. To help reduce height, you 
can:
- Set the labels of the inputs for custom dec/sep to "" (these are definitely 
expendable, IMO)
- Set the label of the file name selector to "". Probably self-explanatory.
- As a rather desparate (but effective) measure, you could put varslot and 
browser on the same row.

Regards
Thomas

Re: [rkward-devel] import/export CSV

[meik m. <mei...@un...>]

hi,

here's a refined version, what do think of the restructured comments?


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

Re: [rkward-devel] import/export CSV

[Thomas F. <tho...@ru...>]

Hi,

On Monday 01 December 2014 12:14:19 meik michalke wrote:
> > Assorted comments:
> > - Why is the "append" option controlled by the predefined format?
> 
> you just wrote it yourself:
> > "append, col.names, sep, dec and qmethod cannot be altered."
> 
>   ^^^^^^^^
> 
> ;-)

yes, it occurred to me a few minutes after sending the mail...
 
> that option and the column names are the deactivated settings i was
> referring to, for write.csv() and write.csv2(). they are not all on the
> same tab

Yes. I see that now. And for the "append" option that is particularly 
unfortunate (but changing the default to "custom" does not help at that point, 
either; quite the contrary: If you first check "append" on the first tab, then 
select "CSV" on the second tab, you may be in for a nasty surprise!).

Have you tried moving all format options to the first tab? Perhaps moving 
encoding to a less prominent place?

> sure, this is only an idea. but let me explain how it came to this: firstly,
> i was thinking about people who want to learn R;

Yes, neither alternative is clearly superior to the other. But on the other 
side of the coin, listing all these parameters makes it harder to see just 
what you changed from the default.
Besides, this still does not explain what other values are permissible for 
each argument. Particularly for parameters with non-obvious semantics, such as 
col.names (and I don't think anyone would guess the correct meaning of 
col.names=NA without consulting the documentation).

[...]

> the R code currently also includes all defaults.

Except for "quote".

> having something to embed would be great, but i still didn't really get how
> to write an embeddable plugin ;-)

Simple: Just like any standalone plugin (including a <dialog>).

The additional thing to worry about is "passing information" between embedded 
and embedding plugin. The standard ways are:
1) Providing <external>-properties in the embedded plugin.
2) Generating code the usual way. The embedding plugin can retrieve that using
  getString ("embedded_id.code.calculate");
etc.

Oh, one more thing:
- The export plugin's .js code still lacks appropriate i18n()-calls. Consider 
utilizing the new Header()-functionality to make that easier (http://www.mail-archive.com/rkw...@li.../msg02499.html).

Regards
Thomas

Re: [rkward-devel] import/export CSV

[meik m. <mei...@un...>]

hi,

Am Montag, 1. Dezember 2014, 11:12:48 schrieb Thomas Friedrichsmeier:
> See my last mail. I think defaulting to CSV (_not_ CVS2!) would be sensible.

ok, i'm all for it.

> Assorted comments:
> - Why is the "append" option controlled by the predefined format?

you just wrote it yourself:

> "append, col.names, sep, dec and qmethod cannot be altered."
  ^^^^^^^^

;-)

that option and the column names are the deactivated settings i was referring 
to, for write.csv() and write.csv2(). they are not all on the same tab -- i 
tried to make the dialog as similar to the import plugin as possible, but 
there are quite some differences.

> - Uncommenting arguments, that do not apply, is a nifty idea, but does come
> with some drawbacks:
>   - Bloats the generated code
>   - Seems to suggest that these _could_ be customized for write.csv(2).
> However, the R help says: "append, col.names, sep, dec and qmethod cannot be
> altered." I'd suggest stripping these.

sure, this is only an idea. but let me explain how it came to this: firstly, i 
was thinking about people who want to learn R; there should also appear an 
explaining comment above the write.csv() call explaining that the commented 
options cannot be changed here (btw, if you try, write.csv() throws a warning 
saying the same). secondly, the commented options show the value that they're 
set to internally; for instance, "col.names" depends on the setting of 
"row.names".

@aaron: what do you think would be most useful? the generated code currently 
reads:

  # some options can't be changed with write.csv()
  # they have been commented out to show the values they are set to
  write.csv(
    x=,
    file="",
    #append=FALSE,
    #sep=",",
    eol="\n",
    na="NA",
    #dec=".",
    row.names=TRUE,
    #col.names=NA,
    #qmethod="double",
    fileEncoding=""
  )

the stripped alternative would be:

  write.csv(
    x=,
    file="",
    eol="\n",
    na="NA",
    row.names=TRUE,
    fileEncoding=""
  )

the R code currently also includes all defaults. if we want to strip it down 
to the absolutely necessary arguments only, it would result in just this:

  write.csv(
    x=,
    file=""
  )

> - Remove the "data.frame"-warning (see my last mail).

with pleasure.

> - For encoding specification, import_spss and import_stata share some code
> (currently in the form of a <snippet>. It might make sense to turn this into
> an embeddable plugin, and use it.

i actually included that snipped first, but it added another full tab and had 
a checkbox for "converting strings" which i didn't find the best wording here. 
so i copied the dropdown menu -- and added the checked "(default)" option, 
since write.table() defaults to 'fileEncoding=""'.

having something to embed would be great, but i still didn't really get how to 
write an embeddable plugin ;-)


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