Re: [rkward-devel] New breaking R2HTML release

[Milan Bouchet-Valat]

I've gone ahead and uploaded R2HTML version 2.3.0 to CRAN. Feel free to
report any breakage you may observe.


Regards


Le mercredi 27 août 2014 à 19:35 +0200, Milan Bouchet-Valat a écrit :
> Dear maintainers of R packages depending on R2HTML,
> 
> We (the RKWard team and I) recently took over the maintainership of the
> R2HTML package in order to prevent it from being archived on CRAN. To
> this goal, we had to make a few (limited) breaking changes, which might
> require your packages to be slightly adapted once it is uploaded to
> CRAN. It is likely, though, that no change will be required at all.
> 
> For the record, packages depending on or suggesting R2HTML are:
> affycoretools, AffyExpress, affylmGUI, Agreement, ArrayExpressHTS,
> ArrayTools, ascii, clusterSim, DMRforPairs, EpiContactTrace, FFD,
> HTMLUtils, limmaGUI, maigesPack, PKtools, psytabs, pubmed.mineR,
> questionr, R453Plus1Toolbox, RcmdrPlugin.EACSPIR, RcmdrPlugin.temis,
> RenextGUI, rgrs, rHVDM, STAR, SwimR
> 
> The list of breaking changes and of replacement solutions is short:
> - .HTML.file is no longer stored in the global environment:
>   use HTMLSetFile() and HTMLGetFile() instead of modifying it directly.
> - .HTMLenv is no longer stored in the global environment:
>   it should never have been accessed directly in the first place.
> - fix() is no longer replaced during HTMLStart()/HTMLStop() sessions.
> - Remove obsolete handling of 'date' class from package survival.
> - Remove obsolete support for old format of objects from the rpart
> package.
> 
> I have run R CMD check on most of your packages with the new R2HTML
> version, and I found no problems. But please have a look, at least to
> check whether you find any occurrences of ".HTML.file", which is likely
> the most used of the features above. The new version can be found at
> https://github.com/nalimilan/R2HTML
> and you can install it easily using the devtools package, by the command
> devtools::install_github("R2HTML", "nalimilan")
> 
> Any more general testing of R2HTML's feature is also welcome, as we are
> not familiar with R2HTML and something might have been broken by
> mistake.
> 
> I will wait for about ten days, and if nobody reports a problem I will
> proceed and upload the new 2.3 version to CRAN. If you experience any
> issue, please contact me and I'll delay the release.
> 
> 
> Regards


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

[rkward-devel] New breaking R2HTML release

[Milan Bouchet-Valat]

Dear maintainers of R packages depending on R2HTML,

We (the RKWard team and I) recently took over the maintainership of the
R2HTML package in order to prevent it from being archived on CRAN. To
this goal, we had to make a few (limited) breaking changes, which might
require your packages to be slightly adapted once it is uploaded to
CRAN. It is likely, though, that no change will be required at all.

For the record, packages depending on or suggesting R2HTML are:
affycoretools, AffyExpress, affylmGUI, Agreement, ArrayExpressHTS,
ArrayTools, ascii, clusterSim, DMRforPairs, EpiContactTrace, FFD,
HTMLUtils, limmaGUI, maigesPack, PKtools, psytabs, pubmed.mineR,
questionr, R453Plus1Toolbox, RcmdrPlugin.EACSPIR, RcmdrPlugin.temis,
RenextGUI, rgrs, rHVDM, STAR, SwimR

The list of breaking changes and of replacement solutions is short:
- .HTML.file is no longer stored in the global environment:
  use HTMLSetFile() and HTMLGetFile() instead of modifying it directly.
- .HTMLenv is no longer stored in the global environment:
  it should never have been accessed directly in the first place.
- fix() is no longer replaced during HTMLStart()/HTMLStop() sessions.
- Remove obsolete handling of 'date' class from package survival.
- Remove obsolete support for old format of objects from the rpart
package.

I have run R CMD check on most of your packages with the new R2HTML
version, and I found no problems. But please have a look, at least to
check whether you find any occurrences of ".HTML.file", which is likely
the most used of the features above. The new version can be found at
https://github.com/nalimilan/R2HTML
and you can install it easily using the devtools package, by the command
devtools::install_github("R2HTML", "nalimilan")

Any more general testing of R2HTML's feature is also welcome, as we are
not familiar with R2HTML and something might have been broken by
mistake.

I will wait for about ten days, and if nobody reports a problem I will
proceed and upload the new 2.3 version to CRAN. If you experience any
issue, please contact me and I'll delay the release.


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] ***SPAM*** Re: R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le mercredi 27 août 2014 à 14:52 +0200, meik michalke a écrit :
> hi,
> 
> Am Mittwoch, 27. August 2014, 09:56:14 schrieb Milan Bouchet-Valat:
> > Honestly, I'm not sure I like it. It would look like
> > # Getter: OK
> > HTMLFile()
> > # Setter: weird
> > HTMLFile() <- "/my/path"
> > 
> > What do you both think about it? I think R is pretty inconsistent
> > already, with par(cex=3) instead of par("cex") <- 3.
> 
> i implemented something similar in koRpus with functions explicitly called 
> "get.kRp.env()" and "set.kRp.env()", instead of "kRp.env()" and 
> "kRp.env()<-". 
> so far no-one complained ;-)
> 
> i do use the "()<-" notation when i'm changing values of objects in 
> .GlobalEnv; e.g., change the language setting of a text object by
> 
>   language(object) <- "en"
> 
> as this feels much more intuitive than something like
> 
>   yourFunct(obj, lang="en")
> 
> 
> so, if i did this, set.HTMLFile() and get.HTMLFile() or similar would be my 
> naming of choice.
Thanks. Actually I've called them HTMLSetFile() and HTMLGetFile(), in
line with other names in R2HTML.

If Thomas agrees, I'll keep them as they are and send the message to the
maintainers.


Regards


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le mercredi 27 août 2014 à 08:42 +0200, Thomas Friedrichsmeier a écrit :
> Hi,
> 
> On Tuesday 26 August 2014 20:56:01 Milan Bouchet-Valat wrote:
> > OK, I think we are good now. I've added accessors for the
> > old .HTML.file, and this works at least with my package which uses it.
> > The checks look fine.
> > 
> > I'm going to e-mail the maintainers of reverse dependencies and leave
> > them some time to reply before pushing to CRAN. Anything I may have
> > missed?
> 
> just a nitpick:
> 
> As a C++-developer I can't quite get used to it, myself, but I think "the R 
> way" of a getter/setter pair is
> 'HTMLFile' <- function() {...}
> 'HTMLFile<-' <- function(filename) {...}
Ah, yes I think nobody from any other language than R can get used to it. :-)

Honestly, I'm not sure I like it. It would look like
# Getter: OK
HTMLFile()
# Setter: weird
HTMLFile() <- "/my/path"

What do you both think about it? I think R is pretty inconsistent
already, with par(cex=3) instead of par("cex") <- 3.


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

OK, I think we are good now. I've added accessors for the
old .HTML.file, and this works at least with my package which uses it.
The checks look fine.

I'm going to e-mail the maintainers of reverse dependencies and leave
them some time to reply before pushing to CRAN. Anything I may have
missed?


Thanks for your participation!

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le dimanche 24 août 2014 à 16:29 +0200, meik michalke a écrit :
> Am Sonntag, 24. August 2014, 12:35:16 schrieb Milan Bouchet-Valat:
> > Breaking the API because of a silly WARNING does not seem like the best
> > option to me.
> 
> i totally agree. but when it comes to keeping something on CRAN, even a silly 
> WARNING can shut the door. i really admire the quality management they keep 
> up 
> there, but the zero tolerance for even the slightest deviation is sometimes a 
> bit too harsh, for my taste. i had to withdraw roxyPackage from CRAN because 
> of such a stupid problem.[*]
Fully agreed. That's also why I prefer solution a) - solution c) is far
too risky. ;-)

> viele grüße :: m.eik
> 
> 
> [*] roxyPackage calls tools:::news2Rd() to create NEWS.Rd files -- which is 
> exactly what the manual on news() tells administrators to do. i however was 
> told not to use unexported ::: functions. but to my knowledge there is no 
> other way to do this job. so i asked them to solve this by exporting that 
> particular function in the tools package instead; i mean, if they *want* you 
> to use it, why not export it already? but they did not like the idea, and i 
> was not willing to lose the functionality i was able to implement by using 
> the 
> NEWS.Rd file (especially the RSS feed). apart from that, i find it 
> infuriating 
> that packages are being blocked if the ship a copy of the GPL in their 
> sources.
...and that we were asked to update our BSD-licensed packages to include
a LICENSE file just to mention the copyright holders, which is redundant
with the Copyright field in DESCRIPTION. ;-)


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le dimanche 24 août 2014 à 15:29 +0200, Thomas Friedrichsmeier a écrit :
> Hi,
> 
> On Sunday 24 August 2014 12:35:16 Milan Bouchet-Valat wrote:
> > > I'm uncertain, whether we should
> > > a) use S3-method markup, anyway
> > > b) rename HTML.cormat to HTMLcormat, breaking the API (although of course
> > > we could keep a deprecated HTML.cormat along with a))
> > > c) Ignore the note, assuming that CRAN maintainers will be ok with it.
> > > 
> > > I tend to think, b) may be the best option after all.
> > 
> > Breaking the API because of a silly WARNING does not seem like the best
> > option to me. Why not a) instead, since it has no effect on the actual
> > code, just on the docs? The doc page makes it obvious anyway that it's
> > not a S3 method.
> 
> well, a) is certainly the easiest option, by all means. The (acceptable) 
> downside to this is that the usage-section will then be rendered as
>   ## S3 method for class 'cormat'
>   HTML(x,[...])
> while you really have to call HTML.cormat(). The example section is not 
> affected, though.
> 
> As the package maintainer, it's your call ;-).
What a responsibility! :-)

Really, I don't care about the ## S3 method comment, as long as the
description is explicit, so go ahead with solution a).


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le dimanche 24 août 2014 à 11:46 +0200, Thomas Friedrichsmeier a écrit :
> Hi!
> 
> On Sunday 24 August 2014 10:20:56 Milan Bouchet-Valat wrote:
> > Actually I also need a setter function in my RcmdrPlugin.temis package,
> > so I'll add both a getter an a setter. The NEWS will have to mention
> > that this update breaks API anyway.
> 
> While we're at breaking the API: I've taken care of the other two notes, 
> except for:
> 
> > * checking Rd \usage sections ... NOTE
> > 
> > S3 methods shown with full name in documentation object 'HTML.cormat':
> >   ‘HTML.cormat’
> > 
> > The \usage entries for S3 methods should use the \method markup and not
> > their full name.
> 
> Now, HTML.cormat.Rd specifically says:
> 
> > Although the class \sQuote{cormat} is not defined, the function is called to
> > \code{HTML.cormat}, to highlight the fact it should be called only with a
> > correlation matrix.
> 
> So, using \method markup would seem somewhat wrong, even if it would shut up 
> the warning without too bad side-effects. Googling reveals, R2HTML 
> is not the first package with that problem(*). There appears to be no 
> workaround other than renaming the function. In fact, that may actually be 
> reasonable, because HTML.cormat *will* become an S3-method for "cormat" 
> objects, as soon as any package defines that class (not necessarily in a 
> compatible way).
> 
> I'm uncertain, whether we should
> a) use S3-method markup, anyway
> b) rename HTML.cormat to HTMLcormat, breaking the API (although of course we 
> could keep a deprecated HTML.cormat along with a))
> c) Ignore the note, assuming that CRAN maintainers will be ok with it.
> 
> I tend to think, b) may be the best option after all.
Breaking the API because of a silly WARNING does not seem like the best
option to me. Why not a) instead, since it has no effect on the actual
code, just on the docs? The doc page makes it obvious anyway that it's
not a S3 method.


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le dimanche 24 août 2014 à 08:27 +0200, Thomas Friedrichsmeier a écrit :
> On Saturday 23 August 2014 23:21:37 Milan Bouchet-Valat wrote:
> > Great! I've created a GitHub repository at
> > https://github.com/nalimilan/R2HTML
> > 
> > Please apply for commit rights (or give me your username) and I'll give them
> > to you.
> 
> Username is tfry-git (both tfry and tfried were already taken - this world is 
> so crowded...).
Indeed. ;-)

I've added you.

> > I've pushed fixes for the global assignment issue, at least the warnings
> > are gone and the tests pass, I've not yet done careful checks. I had to
> > remove an obscure feature which overrode the fix() function in order to
> > do clever things when fix() was called during an HTMLStart()/HTMLStop()
> > session. I don't think this is very useful.
> 
> Yes, I've had a glance at that, and it sure looked weird. Regarding the other 
> assignments, I guess .HTML.file is the most touchy one, as this could 
> conceivably be used by some dependent code. I guess it might be useful (not 
> to 
> RKWard, though) to add at least a getter function, so users can mix HTML() 
> and 
> custom writes more easily.
Actually I also need a setter function in my RcmdrPlugin.temis package,
so I'll add both a getter an a setter. The NEWS will have to mention
that this update breaks API anyway.


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le jeudi 21 août 2014 à 15:23 +0200, Thomas Friedrichsmeier a écrit :
> Hi!
> 
> On Wednesday 20 August 2014 23:14:59 Milan Bouchet-Valat wrote:
> > If fixing all of R2HTML would take too much time, we could as well
> > remove the offending functions, as it's always better for users than not
> > being able to install the package from CRAN at all.
> > 
> > If you are OK, I can volunteer for fixing the assignment in the global
> > environment issue, and you would fix the two easier NOTEs. Then I would
> > take care of maintaining the package. Deal? ;-)
> 
> Ok, deal.
> 
> The global assignment, and esp. maintainance were my primary concerns, the 
> other two notes look very managable, indeed.
> 
> So what's the workflow? Should I send you diffs against the current archive? 
> Or will there be a source repository? (BTW, this is not necessarily a great 
> option, but it is possible to add dedicated svn or git repos under the rkward 
> umbrella on sourceforge.)
Great! I've created a GitHub repository at https://github.com/nalimilan/R2HTML

Please apply for commit rights (or give me your username) and I'll give them to 
you.

I've pushed fixes for the global assignment issue, at least the warnings
are gone and the tests pass, I've not yet done careful checks. I had to
remove an obscure feature which overrode the fix() function in order to
do clever things when fix() was called during an HTMLStart()/HTMLStop()
session. I don't think this is very useful.


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Le mercredi 20 août 2014 à 17:23 +0200, Thomas Friedrichsmeier a écrit :
> Hi!
> 
> On Wednesday 20 August 2014 14:56:02 meik michalke wrote:
> > Am Mittwoch, 20. August 2014, 13:57:06 schrieb Milan Bouchet-Valat:
> > >  If nobody steps in to take up
> > > 
> > > maintainership, it will eventually be archived. As RKWard uses R2HTML
> > > for output, it would be quite a bad situation.
> > 
> > indeed.
> > 
> > > Would you be interested in working at fixing the few R CMD check WARNINGs
> > > and NOTEs in order to update the package?
> > 
> > i sure don't have time to dig into the package to feel comfortable enough to
> > make changes.
> 
> Well, yeah, we don't seem to be swimming in developer ressources, ATM.
> 
> > what are the options? evaluate which functionalitiy RKWard uses exactly, and
> > try to replace R2HTML with maintained alternatives (if there is any)? two
> > things come to my mind:
> > 
> >  print(xtable(), format="HTML")
> > 
> > and extending XiMpLe to make generating HTML easy enough to become
> > independent from other packages? here's some stuff i've been toying around
> > for some other project:
> 
> That may not be the part that's actually difficult. BTW, we already create a 
> custom HTML header in the first place. See rk.set.output.html.file().
> 
> The really nice thing about R2HTML is that you can simply do
>HTML (x)
> (or rk.print (x)) and expect a reasonable result for most common classes of 
> objects. I do not think we actually use too many different classes in 
> existing 
> plugins (some tables, lm-, and htest-objects, as far as I am aware), but so 
> far we can simply hint plugin authors to use rk.print(results) as a first, 
> and 
> often sufficient way to present results.
> 
> Should R2HTML really go away, copying the bits we actually use, should not be 
> too hard. Alternatively, for most purposes,
>rk.print.literal (capture.output (x))
> or
>rk.print.literal (capture.output (summary (results)))
> would do the trick reasonably well. (And in fact, for some things, it may 
> also 
> be preferrable).
> 
> One thing that could really mean trouble for us, is if R2HTML goes away, 
> before we are prepared for it. So I guess we need to decide (before 0.6.2), 
> whether
> 
> a) We rely on R2HTML to continue to be available on CRAN, because it's still 
> pretty popular, and somebody will certainly step forward.
> b) We rely on R2HTML to continue to be available on CRAN, because we take 
> care 
> of ensuring that ourselves.
> c) We modify rk.print() to be functional without R2HTML, so disappearance of 
> R2HTML won't be catastrophic to RKWard.
> 
> Thoughts?
We can probably all copy the bits we need in our packages, but this is
going to require some work anyway, and this time could be better spent
by pooling resources of people who currently rely on R2HTML. All R users
would benefit from it.

I don't think fixing it will require deep understanding of the package:
looking at the 3 NOTEs, 2 may be fixed with really trivial changes, and
only one (assignment in the global environment) appears really serious:
http://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-clang/R2HTML-00check.html

If fixing all of R2HTML would take too much time, we could as well
remove the offending functions, as it's always better for users than not
being able to install the package from CRAN at all.

If you are OK, I can volunteer for fixing the assignment in the global
environment issue, and you would fix the two easier NOTEs. Then I would
take care of maintaining the package. Deal? ;-)


Regards

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

[rkward-devel] R2HTML orphaned on CRAN

[Milan Bouchet-Valat]

Hi!

I have received this e-mail from CRAN maintainers some time ago as one
of my package depends on R2HTML. If nobody steps in to take up
maintainership, it will eventually be archived. As RKWard uses R2HTML
for output, it would be quite a bad situation. Would you be interested
in working at fixing the few R CMD check WARNINGs and NOTEs in order to
update the package? I had a quick look, and it appears they are mostly
superficial. I can devote some time to work on it.


Regards


 Message transféré 
> De: Uwe Ligges 
> Reply-to: c...@r-project.org
> À: R-Devel 
> Cc: CRAN 
> Sujet: [Rd] Looking for new maintainer of orphans R2HTML SemiPar
> cghseg hexbin lgtdl monreg muhaz operators pamr
> Date: Fri, 08 Aug 2014 18:41:13 +0200
> 
> Dear maintainers and R-devel,
> 
> Several orphaned CRAN packages are about to be archived due to 
> outstanding QC problems, but have CRAN and BioC packages depending on 
> them which would be broken by the archival (and hence need archiving 
> alongside).
> Therefore we are looking for new maintainers taking over maintainership 
> for one or more of the following packages:
> 
> R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr
> 
> Package maintainers whose packages depend on one of these may be natural 
> candidates to become new maintainers.
> Hence this messages is addressed to all these maintainers via BCC and to 
> R-devel.
> 
> See
> 
>
>
>
>
>
>
>
>
>
> 
> for information on the QC issues and the reverse dependencies.
> 
> Best wishes,
> Uwe Ligges
> (for the CRAN team)
> 
> __
> r-de...@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] New package rk.Teaching

[Milan Bouchet-Valat]

Le mardi 15 octobre 2013 à 11:36 +, SANCHEZ ALBERCA, ALFREDO a
écrit :
> Hello!
> I've been working during the last year in a new plugin for RKWard for
> teaching statistics. The new package is called rk.Teaching and at the
> moment is in Spanish, but the English translation will be available
> soon. For more info about this package you can visit the web:
> http://asalber.github.io/rkTeaching_es/ (in Spanish) or
> http://asalber.github.io/rkTeaching/ (in English but outdated).
> I'd like to upload the package to the RKWard repository
> http://rkward.sourceforge.net/R/ but I don't know how to proceed. 
This sounds great, and actually even too good to be kept as a plugin
modestly named "Teaching". I would argue that most of the features you
offer should be properly integrated into the relevant RKWard menus, and
enabled by default. I'm particularly interested in the data management
part, which I think deserves being present in the Data menu. This is a
killer feature for sociologists, who often rely on SPSS or Stata for
this.

Of course this is only my opinion ;-)

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] first draft/proposal: new graphics devices section

[Milan Bouchet-Valat]

Le dimanche 06 octobre 2013 à 21:55 +0200, meik michalke a écrit :
> hi,
> 
> a while ago, we were discussing the possible inclusion of the graphics 
> devices 
> somewhere into the main window of RKWard, instead of (or in addition to) 
> opening it in a separate window.
> 
> i made a first draft of how this could look like:
>  http://reaktanz.de/stuff/R/RKWard_graphics_section.png
> 
> the most "difficult" decision is where to put the menu entries. in the draft 
> the graphics device has focus and its menu entries completely replaced the 
> usually available menu. but maybe the normal menu should simply be added to, 
> and not being replaced?
> 
> also, if there were more graphics devices active, you'd probably need tabs in 
> that section, too. alternatively, the "graphics devices" button could work as 
> a tab (i.e., be called "graphics device #1" instead and be added more bottons 
> for additional devices).
> 
> what do you think?
That's interesting, but in the end I'm not sure this is really a good
idea. I've used Rstudio a few times, and I found that the plot is always
either too small to see the contents correctly, or too big because it
takes place that would be useful for other things. It's nice to see the
result of graphics without switching to another window, but in practice
it is merely a preview, which is not always very useful. I guess it
depends on the kind of plot.

To make matters worse, in Rstudio the size of the R device is the size
of the plot pane, not that of the separate window you can open. This
means that when you open the window to get a bigger plot, the position
of graph elements is not as good as it would have been if the plot had
been drawn directly at full size. Unfortunately, R does not recompute
everything when resizing the plot (especially visible for legends, but
not only).

So I would be very careful before doing such a change. ;-)


My two cents

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] Question about plugin's translations

[Milan Bouchet-Valat]

Le vendredi 24 mai 2013 à 21:09 +0200, Thomas Friedrichsmeier a écrit :
> On Friday 24 May 2013 19:59:39 Yuri Chornoivan wrote:
> > A patch with fixes of typos found while inspecting the POTs can be found
> > here:
> > 
> > https://dl.dropboxusercontent.com/u/55247264/typo_fix.patch
> > 
> > Many thanks for reviewing it.
> 
> Applied, except for lowess->lowest. Thanks!
> 
> Did not find the time to look at your updated script, yet.
I just wanted to note that your work on this feature is really
appreciated! I will be happy to translate the plug-ins into French when
it is ready.


Regards

--
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] Rkward windows- suggestion of bat files modifications to have invisible dos window

[Milan Bouchet-Valat]

Le samedi 11 mai 2013 à 10:12 +0200, Thomas Friedrichsmeier a écrit :
> Hi,
> 
> thanks for your suggestions!
> 
> On Friday 10 May 2013 16:58:33 Julien Martin wrote:
> > The two modifications I have done are
> > Adding start /l when initializing KDE
> 
> I did not apply this one. The point is to make sure that KDE is properly 
> initialized _before_ starting RKWard. On most system this is not needed, but 
> on some it seems to be required. If KDE is already initialized, this is very 
> fast, anyway.
Isn't there a way to do this without opening a terminal window? It looks
very old school and doesn't make RKWard a great advertisement. :-)

How do other KDE apps that work on Windows do?


Regards

--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] Painting / plotting doesn't work properly

[Milan Bouchet-Valat]

This bug was fixed in R 2.15.2 IIRC. In the meantime, you can call
X11.options(type="nbcairo")


Regards

Le dimanche 10 mars 2013 à 17:42 +0100, Friedrich Kröner a écrit :
> Thank you for your reply. It turns out the same problem happens with R too. 
> So 
> this is probably unrelated to rkward. I'm currently recompiling R, maybe this 
> will help. Another change to my system could have been switching from ati to 
> fglrx. If recompilation doesn't help, I'll test switching back.
> 
> On Sunday 10 March 2013 17:28:36 you wrote:
> > > I don't know exactly what might have broken plotting for me. But neither
> > > 0.6.0 nor svn paint properly. I always need to resize the window to have
> > > the content repainted and visible. So, while cycling through the plots it
> > > requires me to always resize the window to have its content updated.
> > > 
> > > I wonder what might have broken this, since I remember I did work in the
> > > past. Maybe an ugprade to Qt or KDE is responsible for this behavior or
> > > some configuration problem? (though I deleted all the configs already)
> > 
> > plotting issues are often specific to the platform, and / or versions of the
> > libraries, involved. So it would really be useful to have info on that. The
> > easiest way to provide all relevant version info is by pasting the output
> > of rk.sessionInfo()
> RKWard version: 0.6.0z+0.6.1+devel1
> KDE version (runtime): 4.10.00
> KDE version (compile time): 4.10.00
> 
> R version (compile time): 2.15.0  (2012-03-30 r58871)
> R runtime session info:
> R version 2.15.0 (2012-03-30)
> Platform: x86_64-pc-linux-gnu (64-bit)
> > .
> > 
> > In addition it might be useful to know which window manager you are using.
> > 
> > > I hope you can give me a hint on what to try.
> > 
> > One thing to try might be changing Settings->Configure RKWard->Onscreen
> > Graphics->Default width/height.
> Yes, I tried this already - it didn't change anything.
> > 
> Regards
> Friedrich
> 
> --
> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
> endpoint security space. For insight on selecting the right partner to 
> tackle endpoint security challenges, access the full report. 
> http://p.sf.net/sfu/symantec-dev2dev
> ___
> RKWard-devel mailing list
> RKWard-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rkward-devel


--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] [rkward-announce] Upcoming release, call for testing RKWard 0.6.0

[Milan Bouchet-Valat]

Le mercredi 10 octobre 2012 à 19:51 +0200, Thomas Friedrichsmeier a
écrit :
> Hi,
> 
> On Wednesday 10 October 2012, Milan Bouchet-Valat wrote:
> > I'm not sure we understand each other: I'm just saying that when you
> > imported French translations from Launchpad, my translations, that were
> > present in SVN, shouldn't have been replaced, because they were more
> > recent than Launchpad's. So it looks like Launchpad had not imported the
> > PO file correctly from SVN.
> 
> ok, I had thought you were talking about the most recent import, i.e. the 
> launchpad import of the .po-file after I had reverted it to your version. The 
> _current_ state on launchpad looks sane to me. I could not find meaningful 
> differences between this and SVN (but a lot of differences in line-breaks 
> make 
> it somewhat hard to compare).
Ah, no, I haven't checked Launchpad recently, and I trust you it's OK
ATM.

> > So this is food for thought... ;-)
> 
> Indeed. It is pretty much impossible to find out where exactly things went 
> wrong, however, esp. since for a while, anybody could mess with our 
> translations on launchpad. And at least some cases of mess-up clearly look 
> like they were done by a human, rather than automated logic.
> 
> I guess the lessons to learn - for now - are:
>   1. Fix permissions for translations on launchpad (done).
>   2. Don't try to sync both ways, only from LP to SVN. That should eliminate 
> at least one potential point of failure.
The problem is, you need to sync from SVN to Launchpad if you want
Launchpad to be of any use (i.e. up-to-date msgid, no duplicate
work...). Except if you know that some languages are only translated on
Launchpad, and others only on SVN...


Regards

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] [rkward-announce] Upcoming release, call for testing RKWard 0.6.0

[Milan Bouchet-Valat]

Le mercredi 10 octobre 2012 à 17:47 +0200, Thomas Friedrichsmeier a
écrit :
> On Wednesday 10 October 2012, Milan Bouchet-Valat wrote:
> > But there's probably something wrong in the synchronization with
> > Launchpad: it looks like my translations were overwritten with
> > translations that existed before I made the changes. These should have
> > been removed from Launchpad if it had correctly imported the PO files
> > from SVN...
> 
> Did you fix that, meanwhile? Otherwise, could you point me to one example 
> string that was not synced, correctly?
> 
> Note that the SVN import can take a couple of days, so perhaps the changes 
> simply had not arrived on launchpad, when you checked.
I'm not sure we understand each other: I'm just saying that when you
imported French translations from Launchpad, my translations, that were
present in SVN, shouldn't have been replaced, because they were more
recent than Launchpad's. So it looks like Launchpad had not imported the
PO file correctly from SVN.

> Perhaps it will really be best to stop using the automatic import. Then, if 
> someone sends translation updates to the list, I will upload them to 
> launchpad, directly, and only sync to SVN in the other direction. Either way, 
> I'm trying to understand, what went wrong, where. So again, an example for a 
> string that was not synced, correctly, would be nice.
For example, this string was translated into French in my version,
committed in revision 4037:
+#: plugin/rkcomponentproperties.cpp:760
+msgid "This object has %1 dimension(s), but %2 dimension(s) is/are
expected."
+msgstr "Cet objet a %1 dimension(s), alors que %2 dimension(s) sont
attendues."

Revision 4323, which imported translations from Launchpad, removed it
altogether:
 #: plugin/rkcomponentproperties.cpp:797
 msgid "This object has %1 dimension(s), but %2 dimension(s) is/are
expected."
-msgstr "Cet objet a %1 dimension(s), alors que %2 dimension(s) sont
attendues."
+msgstr ""


This happened to several subsequent strings. Other cases are more
complex: this one was added in revision 4037 too:
 #: main.cpp:115
+msgid "Many plugins, suggestions, rkwarddev package"
+msgstr "De nombreux greffons, des suggestions, le paquet rkwarddev"

And revision 4323 did not remove it, but change it to something worse
(as rkwarddev is not mentioned, so likely and older version, but I don't
really understand since it looks like I added the msgid...), and marked
it as fuzzy:
 #: main.cpp:115
+#, fuzzy
 msgid "Many plugins, suggestions, rkwarddev package"
-msgstr "De nombreux greffons, des suggestions, le paquet rkwarddev"
+msgstr "De nombreux plugins, des suggestions"


So this is food for thought... ;-)

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] [rkward-announce] Upcoming release, call for testing RKWard 0.6.0

[Milan Bouchet-Valat]

Le lundi 08 octobre 2012 à 20:24 +0200, Thomas Friedrichsmeier a écrit :
> Hi!
> 
> On Monday 08 October 2012, Milan Bouchet-Valat wrote:
> > This version seems to work fine AFAICT, but I noticed my translations
> > have been overwritten by a Launchpad import (revision 4323). Many
> > translated strings have been removed, and bad older translations have
> > been reintroduced.
> 
> Thanks for taking a close look! I have reverted fr.po to your version (+ a 
> message merge).
Thanks!

> It does look like translation permissions were set more loose than I had 
> intendend. I have now restricted access to "launchpad-translators". For some 
> existing translators, this may mean that you will have to join that group, 
> first (but if you're already doing your translations in launchpad, that 
> should 
> be a simple step). Sending translations to the list should continue to work.
> 
> I hope this will provide a decent level of quality control. At the very least 
> it gives us an address to complain to, in case of similar problems.
That should help, indeed. At least nonsensical translations should no
longer appear.

But there's probably something wrong in the synchronization with
Launchpad: it looks like my translations were overwritten with
translations that existed before I made the changes. These should have
been removed from Launchpad if it had correctly imported the PO files
from SVN...


Cheers

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] [rkward-announce] Upcoming release, call for testing RKWard 0.6.0

[Milan Bouchet-Valat]

This version seems to work fine AFAICT, but I noticed my translations
have been overwritten by a Launchpad import (revision 4323). Many
translated strings have been removed, and bad older translations have
been reintroduced. This may have affected other languages too: I think
you should really revert this commit before the release.

I strongly suggest (again) that you stop relying on Launchpad when you
don't have a known translator for the language. Have a look at this
change, which removes my translation and introduces something which is
not even French, nor English:
 msgid "Crash recovery file detected"
-msgstr "Fichier de récupération après un arrêt brutal
détecté"
+msgstr " revocery crash fichier détecté "

To give you an idea of the problem, I would translate this French
sentence to something like " file crash revocery detected " (with
trailing spaces on both sides). Really not useful, and this is not
uncommon in the file.


Good work from the developers, though!

--
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] Updated French translation

[Milan Bouchet-Valat]

Le lundi 06 août 2012 à 13:53 -0700, Francois Maurice a écrit :
> Hi,
>  
> I'd like to know where to find and how to install the French
> translation of RKWard ?
The French translation is included upstream for several months, but no
release has been made since then. So for now you will need to build
RKWard from Subversion.


Regards


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] check for debian packages

[Milan Bouchet-Valat]

Le mercredi 18 avril 2012 à 13:03 +0200, meik michalke a écrit :
> hi,
> 
> Am Dienstag, 17. April 2012 17:20:21 schrieb Milan Bouchet-Valat:
> > You would just need to give PK the package name over D-Bus, and it would
> > take care of everything, including PolicyKit authentication via the dialogs
> > adapted to the current desktop environment.
> 
> hm, that sounds neat.
> 
> however, in a first step of the process, we'd need to check if the package is 
> actually available as a *.deb package, and if not, fall back to source 
> packages. i understand that PolicyKit is a graphical-desktop-only tool, so 
> we'd have to see if you can also query simple package information without the 
> full GUI; if not, we'll lose the advantage of looking for package formats 
> other than .deb at this stage. but even if it was just .deb for now i'd be 
> completely happy ;-) and of course, for the actual installation PolicyKit 
> makes a lot of sense anyway.
Indeed. I would argue PackageKit should be smart enough to check the
package exists before asking for authentication, but it doesn't seem to
work that way currently. Luckily, API exists to check for packages
existence before trying to install them:

"Resolve a package name into a package_id. This can return installed and
available packages and allows you find out if a package is installed
locally or is available in a repository."
http://www.packagekit.org/gtk-doc/PkClient.html#pk-client-resolve-async
(for the GLib-based helper library)
http://www.packagekit.org/gtk-doc/Transaction.html#Transaction.Resolve
(for the raw D-Bus interface)

A hacky solution can be to call the command line tool 'pkcon' with
command 'resolve', then parse the output, but that's obviously not the
preferred way.

> i think i'll try to hack together something standalone like an install.deb() 
> function [remove.deb() would be needed, too, but i think we could omit 
> update.deb() as this is better left to the system globally]. someday^TM. as 
> soon as that works, it should be easy to write a wrapper for 
> install.packages() which checks if 'type="deb"' and then calls install.deb(), 
> otherwise simply forwards everything to the actual base::install.packages().
I think you'd better call it install.distrib(), to avoid the need to
rename it if you make it work for other distributions. ;-)


Cheers

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] check for debian packages

[Milan Bouchet-Valat]

Le mardi 17 avril 2012 à 10:20 +0200, Thomas Friedrichsmeier a écrit :
> Hi,
> 
> On Sunday 15 April 2012, meik michalke wrote:
> > not sure if this could be implemented as a plugin, or if it would make more
> > sense to first come up with an R package for this (with an extended
> > install.packages() that also checks debian package archives?). i'm just
> > throwing this in here, maybe you have some comments ;-)
> 
> hm, good question.
> 
> I guess there are number of reasons for implementing this in an R package, 
> first, then extending RKWard to make use of that package, later. The best 
> reason is that quite conceivably the cran2deb / r-sig-debian people may be 
> interested in helping with creating and/or maintaining this.
> 
> One issue that comes to my mind is access rights. While install.packages() 
> will install to a local library by default, for debian packages you'd need 
> admin rights. To make this a smooth user experience, it should be possible to 
> acquire admin rights, interactively. Here it would be important for us to 
> have 
> a parameter to specify a graphical, rather than console based su-command 
> (i.e. 
> kdesu / kdesudo instead of su / sudo).
I think you can easily avoid this by using PackageKit instead of a
custom hack^W implementation. You would just need to give PK the package
name over D-Bus, and it would take care of everything, including
PolicyKit authentication via the dialogs adapted to the current desktop
environment.

The package would probably need to have a C function linking to libdbus
or any D-Bus implementation, but this is not a problem on Debian. The
D-Bus message to send is very simple[1].

The other big win is that your package would work on all Linux
distributions, and for BSDs, as long as the package names are the same
(or can be adapted at runtime, which should be easy).


My two cents


1: http://www.packagekit.org/pk-faq.html#session-methods

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] Better keybindings for "Run"

[Milan Bouchet-Valat]

Le mardi 17 janvier 2012 à 17:14 +0100, Thomas Friedrichsmeier a écrit :
> well, Ctrl+R makes a lot of sense in the context of R GUIs. In our case it is 
> taken by "Replace", already, which also makes a lot of sense, in general. 
> There are two main problems with changing that. First, "Replace" is provided 
> by the embedded kate part. It is not impossible to change the associated 
> shortcut, but it's not really an intended usage of embedded KDE parts, 
> either. 
> Changing this keyboard shortcut would involve using a hack which is likely to 
> break sooner or later, without prior warning. Second, "Replace" is a 
> comparatively important task. Changing it's shortcut (which is a default 
> shortcut, shared across KDE applications) to execute some R code, instead, 
> definitely has potential for causing some unpleasant surprises.
Indeed, I could have figured it out myself. ;-)

> So I think, Ctrl+R is a no-go. Which doesn't mean to say that the current 
> shortcuts are the only / best option. But finding good shortcut combinations 
> (esp. for a series of similar actions), which do not cause conflicts, is 
> notoriously difficult.
I've had a look at a few IDEs for R. RStudio seems to have the same
scenario as RKWard, and to have a reasonable solution:
Ctrl+Enter to run current line/selection
Ctrl+Shift+Enter to run current document
Ctrl+Shift+B to run from document beginning to current line
Ctrl+Shift+E to run from current line to document end
Ctrl+Shift+F to run the current function definition
Ctrl+Shift+P to re-run previous region

(BTW, the four latter shortcuts could be useful, I never thought about
them. But that's of course a separate subject.)

> I think that's a good idea, in principle. Not sure, wether such a "combined" 
> action would replace the others, entirely. Also, I tend to think that it may 
> be more natural to combine the "run selection" behavior with "run file", in 
> case no selection exists. Many existing actions already use similar semantics 
> (also in other applications). In many cases (for simple top-level 
> statements), 
> "run line" can be used as a sort of step-by-step execution, and I think it 
> will be useful to keep this separate.
I really think merging selection/line is the most natural solution.
RStudio does this (I promise, I didn't know it did before suggesting
this change :-), but also SciViews-K (Ctrl+Shift+R). One reason can be
that running the whole file can have bad consequences, so it shouldn't
be possible to run it by mistake, e.g. if you thought you had selected
something and you actually don't. And I think it's really a specific
operation, because it doesn't depend on the place the cursor is in the
file, contrary to the two others.

> How do others feel about this? Which actions could be merged this way? Should 
> the single actions remain in addition to that? Should they continue to have a 
> default keyboard shortcut?
Now, if people think that's wrong, I won't threaten of stopping to use
RKWard or anything. ;-)

> In fact, it would be possible to keep a bit of both in the toolbar: It is 
> possible to create a tool-button with a dropdown, similar to the "back" 
> buttons on many browsers. Simply clicking the button would execute the 
> "combined" action, depending on whether or not there is a selection. Clicking 
> a small arrow at the side would show the current specific actions in a 
> dropdown.
Yeah, but I'm not sure that's really worth it. It's easier to select or
deselect some code and run the combined action, than to use the
drop-down list just to avoid selecting/deselecting the right thing.

> Could it be you are using the "Text alongside icons" placement option (RMB 
> click on the toolbar(s))? "Text below icons" can save a lot of horizontal 
> space. That is also available as a global KDE setting, so if you run into 
> similar problems in other KDE applications, consider checking your system 
> settings.
Yeah, I am. But actually I prefer saving vertical space, which is
expensive on 16:9 screens. I don't personally need the buttons that
don't fit on the toolbar, so I don't really care, but I think it should
be a goal to fix this kind of thing, especially because it seems to be
possible easily.


Let's see what others say...

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

[rkward-devel] Better keybindings for "Run"

[Milan Bouchet-Valat]

Hi!

I've been wondering for some time why the current keybindings for "run
selection", "run line" and "run file" are so cumbersome. Shift+F[7-9]
are not exactly the easiest combinations to reach. And it's probably the
one people are using the most. :-)

Maybe there are historical reasons to this, but I find this choice
weird, since all other R GUIs I know use Ctrl+R, which is much simpler.
Function keys are far away on the keyboard and require you to press Fn
on Macs and current HP laptops. With Shift, this makes three keys to
press at the same time! (I've disabled this behavior on my laptop.)

I suggest to change these keybindings. The natural solution seems to be
Ctrl+R; this would run the current selection, if any, and the current
line if there is no selection (this is what SAS does with F3). Since
running the whole file is also useful, but used a little less often, I
suggest Ctrl+Shift+R.

This would have the advantage that you wouldn't run the whole file by
mistake just because you went a little too much on the right and hit F9
instead of F8. Pressing Shift is something you can't do by mistake. And
it would be much more natural, because when you have something selected,
you rarely want to run the line: you want to run the selection. You
wouldn't need to think (somewhat subconsciously) "I want to run the
selection, so I need to choose F7 and not F8". I see no drawbacks to
this approach.

BTW, the buttons and menus could be changed accordingly. Merging "Run
selection" and "Run line" would make some space available in the
toolbar, which would allow "Run block" and "CD to script directory" to
fit on screen when translated (in French, I couldn't manage to get the
whole bar to fit on my 1366px-wide screen, and for many languages other
than English it will be the case). Anyway, reducing the visual noise on
the main toolbar is always good for users.

What do you think?

--
RSA(R) Conference 2012
Mar 27 - Feb 2
Save $400 by Jan. 27
Register now!
http://p.sf.net/sfu/rsa-sfdev2dev2
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] mac preview

[Milan Bouchet-Valat]

Le mercredi 11 janvier 2012 à 00:17 +0100, meik michalke a écrit :
> hi milan,
> 
> btw, if you didn't notice yet, the bundle package is already up:
>  o http://sourceforge.net/projects/rkwardextras/files/MacOSX/
> and i submitted the portfile to the MacPorts trac system, too. i'll add the 
> sources (1,2 GB) and some parts of the windows README to sf.net next.
> 
> Am Dienstag 10 Januar 2012, 12:39:28 schrieb Milan Bouchet-Valat:
> > Le lundi 09 janvier 2012 à 20:35 +0100, meik michalke a écrit :
> > > the bundle has a size of 810 MB (2,7 GB unpacked)
> [...]
> > Out of curiosity, why is the bundle so large? I didn't know R+Qt+KDE
> > libs were so heavy...
> 
> they aren't, at least not so much. it's partly the rest that gets drawn in 
> (e.g., the bundle currently includes a full gcc). there's much more in it 
> than 
> is absolutely neccessary, which obviously leaves room for optimization here.
> 
> the bundle is made with the MacPorts tools, which work really great, i'm 
> happy 
> to say! a port can specify other ports as dependencies, so if you install the 
> rkward-devel port, you'll get R and KDE ports installed as well, and they in 
> turn have some dependencies -- so much for a local installation.
> 
> to make a bundle, you first make this local installation, and then use the 
> port command to create an installable image from it. this will automatically 
> include the full dependency tree mentioned above, to guarantee that the 
> bundle 
> will work.
> 
> what makes it so huge is that to have KDE in the bundle, rkward-devel depends 
> on kde4-baseapps -- that's one single port, so it's not trivial to strip off 
> parts you don't need. my guess is, we should either look at the bundle image 
> (it can be mounted and examined) and remove parts we don't really need after 
> it was built, or write our own kde4-baseapps-slim port and see if we can 
> build 
> a much smaller KDE for our purpose in the first place. both approaches would 
> take some further amount of trial & error. for instance, i'm not sure how the 
> installer behaves if we just remove some parts of the package; that should be 
> rather simple though, as each component in the bundle is just a tar archive 
> or 
> something.
Thanks for the explanation. I understand now that of course if the whole
KDE environment is included in the bundle, it will be quite heavy.  But
as you said, most KDE parts can probably be skipped; and you could also
get rid of gcc and build tools, if you consider most people won't need
to build packages from source. Another option would be to ask people to
install the R bundle first, I'm not sure how this works on Mac, but that
would avoid duplicating work and space.

> do you by any chance have a mac and can do some testing? if you have some 
> ideas, just shoot ;-)
I don't own a Mac, but I occasionally grab one of my friend's to test a
few things. So I can't really help with the bundle, sorry, but I'll be
able to check for bugs and report them.

I was mainly asking to get an idea of the progress RKWard can make on
OSX. I'd live to be able to use RKWard for text mining package I'm
writing, but for now I really need it to be cross-platform. When it
works fine on OS X and Windows, I'll probably port my package from Rcmdr
to RKWard. Let's dream... ;-)


Cheers

--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] mac preview

[Milan Bouchet-Valat]

Le lundi 09 janvier 2012 à 20:35 +0100, meik michalke a écrit :
> hi,
> 
> a while ago you suggested we could announce the current MacPorts bundle of 
> RKWard to the rkward-users list. i built an updated one just today, and i 
> believe it's even better for a beta test, since we already addressed some 
> bugs 
> ;-)
> 
> so, shall we do it? the bundle has a size of 810 MB (2,7 GB unpacked), which 
> is still quite huge. can we host such big files on sf.net? in addition, i 
> think we could also release the portfile officially on MacPorts. i would take 
> care of both once you give the sign.
That's great!

Out of curiosity, why is the bundle so large? I didn't know R+Qt+KDE
libs were so heavy...



Cheers

--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] [rkward-cvs] SF.net SVN: rkward:[4063] trunk/rkward/rkward/plugins/00saveload/import

[Milan Bouchet-Valat]

Le dimanche 04 décembre 2011 à 20:24 +0100, Thomas Friedrichsmeier a
écrit :
> well, for all I can see, all available solutions have some real drawbacks. On 
> my system, perl is no problem, while my rJava installation tends to be 
> broken, 
> frequently. But certainly, for many users it will be the other way around.
FWIW, the RODBC package can be used to read .xls and .xlsx files on
Windows, since a driver is installed by default on that platform (as a
bonus, Access .mdb and .mdbx files are also read). As it's written by
Microsoft, we can expect it to support correctly these formats. ;-)

The code is relatively simple, and well documented (see [1], p. 16). For
illustration purposes, here's what I'm using in a Rcmdr plugin I wrote
(doItAndPrint() is Rcmdr way of running a command):

# 'file' contains the path to the file
ext <- tolower(substring(file, nchar(file) - sop + 2, nchar(file)))
channelStr <- switch(EXPR = ext,
 xls = "odbcConnectExcel",
 xlsx = "odbcConnectExcel2007",
 mdb = "odbcConnectAccess",
 accdb = "odbcConnectAccess2007")
doItAndPrint(paste("channel <- ", channelStr, "(\"", file, "\")",
   sep=""))

# For Excel and Access, need to select a particular sheet or table
tabdat <- sqlTables(channel)
names(tabdat) <- tolower(names(tabdat))

if(ext == "mdb" || ext == "accdb")
tabdat <- tabdat[tabdat$table_type == "TABLE", 3]

if(ext == "xls" || ext == "xlsx") {
tabname <- tabdat$table_name
tabdat <- ifelse(tabdat$table_type == "TABLE",
 substring(tabname, 2, nchar(tabname) - 2),
 substring(tabname, 1, nchar(tabname) - 1))
}

# If there are several tables
if(length(tabdat) > 1)
fil <- tk_select.list(sort(tabdat),
  title=gettext_Rcmdr("Select one table"))
else
fil <- tabdat

if(fil == "") {
Message(gettext_Rcmdr("No table selected"), type="error")
return()
}

if(ext == "xls" || ext == "xlsx")
fil <- paste("[", fil, "$]", sep = "")

# Retrieve the data
command <- paste("sqlQuery(channel=channel, select * from ", fil,")",
 sep = "")
doItAndPrint(paste("corpusDataset <- ", command, sep = ""))
doItAndPrint("odbcCloseAll()")


Just my two cents


1: http://cran.r-project.org/web/packages/RODBC/vignettes/RODBC.pdf


--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel

Re: [rkward-devel] New French translation

[Milan Bouchet-Valat]

Le vendredi 18 novembre 2011 à 17:03 +0100, Thomas Friedrichsmeier a
écrit :
> Hi,
> 
> On Friday 18 November 2011, Milan Bouchet-Valat wrote:
> > I've just finished translating RKWard to French, attached is the
> > resulting PO file. I hope that way I'll be able to suggest RKWard to
> > French R users more easily.
> 
> thanks! I have just committed this to our repository. Should be imported to 
> launchpad within a few days.
Thanks! Sorry for the late response - but I hope to give a more informed
reply that way.

> > The current French translation for RKWard was very bad, to the point I
> > think it made more harm than good to have it: very few strings were
> > translated, often with language mistakes and even a few incorrect
> > translations. Maybe it would be a good idea to avoid shipping a PO file
> > until it's known to be good enough: for having participated in the
> > French translation of Ubuntu, I know Launchpad Translations is a very
> > dangerous tool when no approved team checks for the quality of the
> > translation. Often, people come up, translate a few strings without
> > context in a very approximate way, and the aggregation of these random
> > contributions makes up a very bad PO file. Probably, the KDE translation
> > team, if willing to help, would really improve the situation - anyway,
> > that's my piece of advice. ;-)
> 
> I don't feel terribly qualified in this area. I do see your point, and in 
> fact, 
> personally, I prefer an English desktop. One reason for that is that I tend 
> to 
> be unsatisfied with translation quality across the board.
> 
> Anyway, for RKWard, the vast majority of translations was provided by actual 
> users of RKWard at some point of time, and in general I would think that's 
> probably the best warrant that translations will be at least mostly ok. Of 
> course, having a formal quality control would be much better - if we can get 
> that.
> 
> Perhaps as an interim solution, we could work on the assumption that any 
> translation which is very incomplete is not well-maintained, either. I.e. 
> perhaps we would only install translations which are at least 80% complete or 
> so.
> 
> Comments?
I think that's a reasonable position. Half-translated UIs can't be of
good quality anyway. And the existing translations are preserved in case
somebody wants to improve the situation for a given language.


> > Another area in which I'd be interested: is there any plan to allow
> > translating plugins? Would the gettext support present in R packages be
> > enough? Currently, the GUI is half-untranslated even with a full PO file
> > for the main app, which feels a little weird.
> 
> Overall, this would be feasible to add, and of course, it should be added, 
> eventually. The translations would actually happen in the frontend, but 
> that's 
> merely a detail. The biggest challenge will be creating a suitable .pot file. 
> In particular:
> - Translatable strings need to be extracted for the plugin .xml, .rkh, and 
> .js 
> files (for the .js files, translatable strings would need to be marked up by 
> the 
> plugin developer; for the other two, it's implicit).
> - In particular for the .xml-files, it will be essential to include enough 
> context in the extracted strings to enable an adequate translation. Strings 
> there are often very short fragments.
> - Probably, one .pot file should be created per .pluginmap.
> 
> If you can provide (parts of) a solution for this, then I can probably take 
> care of implementing message lookup in the GUI within a relatively short 
> amount of time.
Indeed, the biggest part is to create proper .pot files.

For JS, it's quite easy. GNOME Shell uses gettext and it works well:
xgettext treats .js files as C files, so the only need is to use "
instead of ' for translatable strings, and to surround them with _().
Then, you need to define this function so that it calls gettext(), but
I'm not sure how you can do that in RKWard (defining this from the C++
code?). You can also somewhat create a i18n() function in JS, and tell
xgettext to detect it.

For XML, it looks like it would be more complex. As I understand it, the
current XML format for RKWard plugins wouldn't work correctly with
strings extractors. It seems that Qt's .rc and .ui files, and GTK's .ui
files use the same pattern, which is that translatable strings are
always in a tag, and never in an attribute. ATM, RKWard plugin UIs are
defined using attributes, which are not supported by intltool and
extractrc.

So I think the XML format would need to be changed so that e.g. a
dialog's title isn't defined with:

but with:

  "Two Vari

[rkward-devel] Editing the wiki

[Milan Bouchet-Valat]

Hi!

I just found out about the
KDEDIRS=/usr/local:/usr
trick for people that install RKWard in /usr/local.

I wanted to add this to the wiki page about building, but it looks like
I need permissions to do that. Would you give me these rights, or add
the trick for me? Thanks!


Keep up the good work

--
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
___
RKWard-devel mailing list
RKWard-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkward-devel