Re: [Rd] [patch] Add support for editor function in edit.default

[Scott Kostyshak]

On Tue, Sep 9, 2014 at 2:24 AM, Deepayan Sarkar
 wrote:
> On Sun, Aug 24, 2014 at 9:14 AM, Scott Kostyshak  
> wrote:
>> On Tue, May 20, 2014 at 5:55 AM, Scott Kostyshak  
>> wrote:
>>> Regarding the following extract of ?options:
>>>  ‘editor’: a non-empty string, or a function that is called with a
>>>   file path as argument.
>>>
>>> edit.default currently calls the function with three arguments: name,
>>> file, and title. For example, running the following
>>
>> To be clear with what I view as problematic, note in the above that
>> the documentation says the function is called with a file path as an
>> argument, suggesting one argument; but in practice it is called with
>> three arguments.
>>
>>> vimCmd <- 'vim -c "set ft=r"'
>>> vimEdit <- function(file_) system(paste(vimCmd, file_))
>>> options(editor = vimEdit)
>>> myls <- edit(ls)
>>>
>>> gives "Error in editor(name, file, title) : unused arguments (file, title)".
>>>
>>> The attached patch changes edit.default to call the editor function
>>> with just the file path. There is at least one inconsistent behavior
>>> that this patch causes in its current form. It does not obey the
>>> following (from ?edit):
>>>  Calling ‘edit()’, with no arguments, will result in the temporary
>>> file being reopened for further editing.
>>>
>>> I see two ways to address this: (1) add a getEdFile() function to
>>> utils/edit.R that calls a function getEd() defined in edit.c that
>>> returns DefaultFileName; or (2) this patch could be rewritten in C in
>>> a new function in edit.c.
>>>
>>> Is there any interest in this patch?
>>> If not, would there be interest in an update of the docs, either
>>> ?options (stating the possibility that if 'editor' is a function, it
>>> might be called with 'name', 'file', and 'title' arguments) or ?edit
>>>  ?
>>
>> Any interest in this patch? If not, would a patch for the
>> documentation be considered?
>
> Given that edit() itself is called with the three arguments, it seems
> more general to pass them to the editor function, and I don't see the
> need for a special case. You can always write your function as
>
> vimEdit <- function(file_, ...) system(paste(vimCmd, file_))

Indeed, makes sense.

> I will clarify the documentation.

Great. Thanks a lot for taking the time to understand the issue.

Best,

Scott


--
Scott Kostyshak
Economics PhD Candidate
Princeton University

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Luca Sartore]

Dear all,

I will pick up monreg.

Best regards,
Luca Sartore


2014-09-08 1:03 GMT+02:00 Uwe Ligges :
>
>
> On 08.09.2014 01:01, Gregory R. Warnes wrote:
>>
>> And I’ll pick up hexbin.
>
>
> Err, that one has been adopted a month ago already.
>
> open are:
>
> SemiPar cghseg monreg
>
>
> Best,
> Uwe Ligges
>
>
>>
>> -Greg
>>
>> On Sep 7, 2014, at 12:17 PM, Romain Francois 
>> wrote:
>>
>>> I'll pick up operators.
>>>
>>> Le 7 sept. 2014 à 18:03, Uwe Ligges  a
>>> écrit :
>>>


 On 05.09.2014 20:25, Greg Snow wrote:
>
> Uwe,
>
> Have all of these packages found new maintainers? if not, which ones
> are still looking to be adopted?


 Thanks for asking, the ones still looking to be adaopted are:
 SemiPar cghseg monreg operators

 Best,
 Uwe Ligges


>
> thanks,
>
> On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges 
> wrote:
>>
>> 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-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
>
>

 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Duncan Murdoch]

On 09/09/2014, 2:45 AM, Philippe Grosjean wrote:
> Yihui and Gábor,
> 
> I agree with you, and I also think that using Travis CI would be very nice. 
> However, there are hundreds of page on the R wiki to migrate… and syntax is a 
> little bit different than Markdown.
> 
> Of course, a solution would be to start again from scratch, but I think that 
> those who have contributed to the R Wiki deserve more respect. Any 
> suggestion, or idea about this?

It's often not hard to write a simple parser for markup languages like
this, and then you can parse the original and rewrite the equivalent new
markup.  If the markup is only a "little bit" different than Markdown,
you can ignore all the similar bits, and only worry about parsing the
different parts.  (And if the parsing isn't perfect, it may be that
manual tweaking isn't so hard.)

Of course, you did also say something about being "very busy with exams
+ Master and PhD theses", so now might not be the time...

Duncan


> 
> Best, 
> 
> Philippe
> On 08 Sep 2014, at 23:12, Gábor Csárdi  wrote:
> 
>> I second this suggestion.
>>
>> One possible complication I see is that if you would like to run the R
>> code (to display its output for example), then AFAIK you cannot simply
>> use Jekyll on Github's side, but would need some additional
>> infrastructure.
>>
>> It might be possible to use Travis (or some other) CI for it, and
>> avoid installing additional software and/or servers, but anyway, this
>> requires some care and effort.
>>
>> If you don't want to run the code, then it is very easy, apart from
>> the (one-time) migration cost.
>>
>> Best,
>> Gabor
>>
>> On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie  wrote:
>>> I want to make a humble suggestion: migrate the wiki to Github, and
>>> build the pages using Jekyll+Markdown. That way, I think it will
>>> attract more volunteers. Simply look how many pull requests that
>>> Hadley has got for his up-coming book hosted on Github
>>> (http://adv-r.had.co.nz): https://github.com/hadley/adv-r/pulls I have
>>> had the experience of maintaining web servers and different wiki/CMS
>>> systems (including Dokuwiki -- I have even written a PHP plugin for
>>> it), and eventually I found I could not afford the time on the job of
>>> a system admin. Now I never do that again, and I just focus on
>>> maintaining the content. Let the professionals do the hosting and
>>> compilation service, and my life has become so much better (no more
>>> worries about security holes and attacks).
>>>
>>> Regards,
>>> Yihui
>>> --
>>> Yihui Xie 
>>> Web: http://yihui.name
>>>
>>>
>>> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
>>>  wrote:
 Uwe and all,

 I have problems with the R wiki engine. It seems that there is a 
 systematic attack of the R wiki site that produces an overconsumption of 
 the server's CPU, and consequently, my provider did shutdown the whole 
 SciViews.org web site.

 Now, it is a bad time for me to work on this (very busy with exams + 
 Master and PhD theses). I am currently looking for an expert in CMS to 
 look at the problem. I don't know when I will be able to solve this and 
 reopen the R Wiki.

 Best,

 Philippe
 ..<°}))><
 ) ) ) ) )
 ( ( ( ( (Prof. Philippe Grosjean
 ) ) ) ) )
 ( ( ( ( (Numerical Ecology of Aquatic Systems
 ) ) ) ) )   Mons University, Belgium
 ( ( ( ( (
 ..

 On 06 Sep 2014, at 17:28, Uwe Ligges  
 wrote:

> Rather than asking here, I'd ask Philippe Grosjean directly, hence CCIng.
>
> Best,
> Uwe Ligges
>
>
>
> On 06.09.2014 01:17, André Z. D. A. wrote:
>> This does not answer you, but if you are looking for something that 
>> existed on that wiki, it may help:
>>
>> https://web.archive.org/web/20140112055032/http://rwiki.sciviews.org/
>> doku.php
>>
>> And that wiki doesn't look like it had a lot of activity:
>> https://web.archive.org/web/2014030100*/http://rwiki.sciviews.org/
>>>
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Philippe Grosjean]

On 09 Sep 2014, at 13:39, Duncan Murdoch  wrote:

> On 09/09/2014, 2:45 AM, Philippe Grosjean wrote:
>> Yihui and Gábor,
>> 
>> I agree with you, and I also think that using Travis CI would be very nice. 
>> However, there are hundreds of page on the R wiki to migrate… and syntax is 
>> a little bit different than Markdown.
>> 
>> Of course, a solution would be to start again from scratch, but I think that 
>> those who have contributed to the R Wiki deserve more respect. Any 
>> suggestion, or idea about this?
> 
> It's often not hard to write a simple parser for markup languages like
> this, and then you can parse the original and rewrite the equivalent new
> markup.  If the markup is only a "little bit" different than Markdown,
> you can ignore all the similar bits, and only worry about parsing the
> different parts.  (And if the parsing isn't perfect, it may be that
> manual tweaking isn't so hard.)
> 
Yes, you are right. I have looked at Pandoc, but it only supports DokuWiki in 
output, not in input.


> Of course, you did also say something about being "very busy with exams
> + Master and PhD theses", so now might not be the time…
> 
Indeed,… unless there are volunteers over there to help?

Philippe

> Duncan
> 
> 
>> 
>> Best, 
>> 
>> Philippe
>> On 08 Sep 2014, at 23:12, Gábor Csárdi  wrote:
>> 
>>> I second this suggestion.
>>> 
>>> One possible complication I see is that if you would like to run the R
>>> code (to display its output for example), then AFAIK you cannot simply
>>> use Jekyll on Github's side, but would need some additional
>>> infrastructure.
>>> 
>>> It might be possible to use Travis (or some other) CI for it, and
>>> avoid installing additional software and/or servers, but anyway, this
>>> requires some care and effort.
>>> 
>>> If you don't want to run the code, then it is very easy, apart from
>>> the (one-time) migration cost.
>>> 
>>> Best,
>>> Gabor
>>> 
>>> On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie  wrote:
 I want to make a humble suggestion: migrate the wiki to Github, and
 build the pages using Jekyll+Markdown. That way, I think it will
 attract more volunteers. Simply look how many pull requests that
 Hadley has got for his up-coming book hosted on Github
 (http://adv-r.had.co.nz): https://github.com/hadley/adv-r/pulls I have
 had the experience of maintaining web servers and different wiki/CMS
 systems (including Dokuwiki -- I have even written a PHP plugin for
 it), and eventually I found I could not afford the time on the job of
 a system admin. Now I never do that again, and I just focus on
 maintaining the content. Let the professionals do the hosting and
 compilation service, and my life has become so much better (no more
 worries about security holes and attacks).
 
 Regards,
 Yihui
 --
 Yihui Xie 
 Web: http://yihui.name
 
 
 On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
  wrote:
> Uwe and all,
> 
> I have problems with the R wiki engine. It seems that there is a 
> systematic attack of the R wiki site that produces an overconsumption of 
> the server's CPU, and consequently, my provider did shutdown the whole 
> SciViews.org web site.
> 
> Now, it is a bad time for me to work on this (very busy with exams + 
> Master and PhD theses). I am currently looking for an expert in CMS to 
> look at the problem. I don't know when I will be able to solve this and 
> reopen the R Wiki.
> 
> Best,
> 
> Philippe
> ..<°}))><
> ) ) ) ) )
> ( ( ( ( (Prof. Philippe Grosjean
> ) ) ) ) )
> ( ( ( ( (Numerical Ecology of Aquatic Systems
> ) ) ) ) )   Mons University, Belgium
> ( ( ( ( (
> ..
> 
> On 06 Sep 2014, at 17:28, Uwe Ligges  
> wrote:
> 
>> Rather than asking here, I'd ask Philippe Grosjean directly, hence CCIng.
>> 
>> Best,
>> Uwe Ligges
>> 
>> 
>> 
>> On 06.09.2014 01:17, André Z. D. A. wrote:
>>> This does not answer you, but if you are looking for something that 
>>> existed on that wiki, it may help:
>>> 
>>> https://web.archive.org/web/20140112055032/http://rwiki.sciviews.org/
>>> doku.php
>>> 
>>> And that wiki doesn't look like it had a lot of activity:
>>> https://web.archive.org/web/2014030100*/http://rwiki.sciviews.org/
 
 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
> 
> ___

Re: [Rd] r wiki

[Philippe Grosjean]

On 09 Sep 2014, at 14:14, Philippe Grosjean  wrote:

> 
> On 09 Sep 2014, at 13:39, Duncan Murdoch  wrote:
> 
>> On 09/09/2014, 2:45 AM, Philippe Grosjean wrote:
>>> Yihui and Gábor,
>>> 
>>> I agree with you, and I also think that using Travis CI would be very nice. 
>>> However, there are hundreds of page on the R wiki to migrate… and syntax is 
>>> a little bit different than Markdown.
>>> 
>>> Of course, a solution would be to start again from scratch, but I think 
>>> that those who have contributed to the R Wiki deserve more respect. Any 
>>> suggestion, or idea about this?
>> 
>> It's often not hard to write a simple parser for markup languages like
>> this, and then you can parse the original and rewrite the equivalent new
>> markup.  If the markup is only a "little bit" different than Markdown,
>> you can ignore all the similar bits, and only worry about parsing the
>> different parts.  (And if the parsing isn't perfect, it may be that
>> manual tweaking isn't so hard.)
>> 
> Yes, you are right. I have looked at Pandoc, but it only supports DokuWiki in 
> output, not in input.

Oh, by the way, I found this one: 
https://github.com/ludoza/DokuWiki-to-Markdown-Converter

PhG

> 
> 
>> Of course, you did also say something about being "very busy with exams
>> + Master and PhD theses", so now might not be the time…
>> 
> Indeed,… unless there are volunteers over there to help?
> 
> Philippe
> 
>> Duncan
>> 
>> 
>>> 
>>> Best, 
>>> 
>>> Philippe
>>> On 08 Sep 2014, at 23:12, Gábor Csárdi  wrote:
>>> 
 I second this suggestion.
 
 One possible complication I see is that if you would like to run the R
 code (to display its output for example), then AFAIK you cannot simply
 use Jekyll on Github's side, but would need some additional
 infrastructure.
 
 It might be possible to use Travis (or some other) CI for it, and
 avoid installing additional software and/or servers, but anyway, this
 requires some care and effort.
 
 If you don't want to run the code, then it is very easy, apart from
 the (one-time) migration cost.
 
 Best,
 Gabor
 
 On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie  wrote:
> I want to make a humble suggestion: migrate the wiki to Github, and
> build the pages using Jekyll+Markdown. That way, I think it will
> attract more volunteers. Simply look how many pull requests that
> Hadley has got for his up-coming book hosted on Github
> (http://adv-r.had.co.nz): https://github.com/hadley/adv-r/pulls I have
> had the experience of maintaining web servers and different wiki/CMS
> systems (including Dokuwiki -- I have even written a PHP plugin for
> it), and eventually I found I could not afford the time on the job of
> a system admin. Now I never do that again, and I just focus on
> maintaining the content. Let the professionals do the hosting and
> compilation service, and my life has become so much better (no more
> worries about security holes and attacks).
> 
> Regards,
> Yihui
> --
> Yihui Xie 
> Web: http://yihui.name
> 
> 
> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
>  wrote:
>> Uwe and all,
>> 
>> I have problems with the R wiki engine. It seems that there is a 
>> systematic attack of the R wiki site that produces an overconsumption of 
>> the server's CPU, and consequently, my provider did shutdown the whole 
>> SciViews.org web site.
>> 
>> Now, it is a bad time for me to work on this (very busy with exams + 
>> Master and PhD theses). I am currently looking for an expert in CMS to 
>> look at the problem. I don't know when I will be able to solve this and 
>> reopen the R Wiki.
>> 
>> Best,
>> 
>> Philippe
>> ..<°}))><
>> ) ) ) ) )
>> ( ( ( ( (Prof. Philippe Grosjean
>> ) ) ) ) )
>> ( ( ( ( (Numerical Ecology of Aquatic Systems
>> ) ) ) ) )   Mons University, Belgium
>> ( ( ( ( (
>> ..
>> 
>> On 06 Sep 2014, at 17:28, Uwe Ligges  
>> wrote:
>> 
>>> Rather than asking here, I'd ask Philippe Grosjean directly, hence 
>>> CCIng.
>>> 
>>> Best,
>>> Uwe Ligges
>>> 
>>> 
>>> 
>>> On 06.09.2014 01:17, André Z. D. A. wrote:
 This does not answer you, but if you are looking for something that 
 existed on that wiki, it may help:
 
 https://web.archive.org/web/20140112055032/http://rwiki.sciviews.org/
 doku.php
 
 And that wiki doesn't look like it had a lot of activity:
 https://web.archive.org/web/2014030100*/http://rwiki.sciviews.org/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
 
 __

Re: [Rd] r wiki

[Gábor Csárdi]

[...]
>> Yes, you are right. I have looked at Pandoc, but it only supports DokuWiki 
>> in output, not in input.
>
> Oh, by the way, I found this one: 
> https://github.com/ludoza/DokuWiki-to-Markdown-Converter
>
> PhG

An probably you can keep the full history as well:
https://github.com/hoxu/dokuwiki2git

Gabor

[...]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Martin Maechler]

> Philippe Grosjean 
> on Tue, 9 Sep 2014 08:45:14 +0200 writes:

> Yihui and Gábor, I agree with you, and I also think that
> using Travis CI would be very nice. However, there are
> hundreds of page on the R wiki to migrate… and syntax is a
> little bit different than Markdown.

> Of course, a solution would be to start again from
> scratch, but I think that those who have contributed to
> the R Wiki deserve more respect. Any suggestion, or idea
> about this?

(and we have seen more on this thread ..)

As one contributor to the former wiki and maintainer of the
good olde mailing lists, I completely agree (with
Yihui and Gábor and you) that it's best to move it over to an
infrastructure which takes care of authentication of legitimate
users and protection from thieves burglers, spammers, and the like.  

Markdown is definitely much better for R users (given knittr and
Rmd ..), and github is currently the place to host -- and once
it ceases to be that, markdown will be easier to migrate from.

Martin

> Best,

> Philippe On 08 Sep 2014, at 23:12, Gábor Csárdi
>  wrote:

>> I second this suggestion.
>> 
>> One possible complication I see is that if you would like
>> to run the R code (to display its output for example),
>> then AFAIK you cannot simply use Jekyll on Github's side,
>> but would need some additional infrastructure.
>> 
>> It might be possible to use Travis (or some other) CI for
>> it, and avoid installing additional software and/or
>> servers, but anyway, this requires some care and effort.
>> 
>> If you don't want to run the code, then it is very easy,
>> apart from the (one-time) migration cost.
>> 
>> Best, Gabor
>> 
>> On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie
>>  wrote:
>>> I want to make a humble suggestion: migrate the wiki to
>>> Github, and build the pages using Jekyll+Markdown. That
>>> way, I think it will attract more volunteers. Simply
>>> look how many pull requests that Hadley has got for his
>>> up-coming book hosted on Github
>>> (http://adv-r.had.co.nz):
>>> https://github.com/hadley/adv-r/pulls I have had the
>>> experience of maintaining web servers and different
>>> wiki/CMS systems (including Dokuwiki -- I have even
>>> written a PHP plugin for it), and eventually I found I
>>> could not afford the time on the job of a system
>>> admin. Now I never do that again, and I just focus on
>>> maintaining the content. Let the professionals do the
>>> hosting and compilation service, and my life has become
>>> so much better (no more worries about security holes and
>>> attacks).
>>> 
>>> Regards, Yihui
>>> --
>>> Yihui Xie  Web: http://yihui.name
>>> 
>>> 
>>> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
>>>  wrote:
 Uwe and all,
 
 I have problems with the R wiki engine. It seems that
 there is a systematic attack of the R wiki site that
 produces an overconsumption of the server's CPU, and
 consequently, my provider did shutdown the whole
 SciViews.org web site.
 
 Now, it is a bad time for me to work on this (very busy
 with exams + Master and PhD theses). I am currently
 looking for an expert in CMS to look at the problem. I
 don't know when I will be able to solve this and reopen
 the R Wiki.
 
 Best,
 
 Philippe
 ..<°}))><
 ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean ) ) ) ) ) (
 ( ( ( ( Numerical Ecology of Aquatic Systems ) ) ) ) )
 Mons University, Belgium ( ( ( ( (
 ..
 
 On 06 Sep 2014, at 17:28, Uwe Ligges
  wrote:
 
> Rather than asking here, I'd ask Philippe Grosjean
> directly, hence CCIng.
> 
> Best, Uwe Ligges
> 
> 
> 
> On 06.09.2014 01:17, André Z. D. A. wrote:
> This does not answer you, but if you are looking for
> something that existed on that wiki, it may help:
> 
> https://web.archive.org/web/20140112055032/http://rwiki.sciviews.org/
> doku.php
> 
> And that wiki doesn't look like it had a lot of activity:
> https://web.archive.org/web/2014030100*/http://rwiki.sciviews.org/
>>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailma

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Uwe Ligges]

On 09.09.2014 09:52, Luca Sartore wrote:

Dear all,

I will pick up monreg.


Please try to coordinate efforts with Scott Kostyshak  who offered the 
same thing yesterday.


Best,
Uwe Ligges




Best regards,
Luca Sartore


2014-09-08 1:03 GMT+02:00 Uwe Ligges :



On 08.09.2014 01:01, Gregory R. Warnes wrote:


And I’ll pick up hexbin.



Err, that one has been adopted a month ago already.

open are:

SemiPar cghseg monreg


Best,
Uwe Ligges




-Greg

On Sep 7, 2014, at 12:17 PM, Romain Francois 
wrote:


I'll pick up operators.

Le 7 sept. 2014 à 18:03, Uwe Ligges  a
écrit :




On 05.09.2014 20:25, Greg Snow wrote:


Uwe,

Have all of these packages found new maintainers? if not, which ones
are still looking to be adopted?



Thanks for asking, the ones still looking to be adaopted are:
SemiPar cghseg monreg operators

Best,
Uwe Ligges




thanks,

On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges 
wrote:


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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel







__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with order() and I()

[Martin Maechler]

> MacQueen, Don 
> on Mon, 8 Sep 2014 16:06:21 + writes:

> I have found that order() fails in a rather arcane circumstance, as in
> this example:

>> foo <- I( c('x','\265g') )
>> order(foo)
> Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed

>> foo <-c('x','\265g')
>> order(foo)
> [1] 1 2

yes, this is not desirable.
order() in such cases calls xtfrm()  {as documented}
and that ends up calling rank() and then the internal  .gt()
where the bug happens because

 > I("x") > I("\xb5g")
 [1] NA

but really I think the change should happen in xtfrm.Asis(.)
which I think should drop the class also in this case.

More on this, once we have fixed it.

Thank you, Don, very much!

Martin Maechler,
ETH Zurich

>> sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-apple-darwin13.1.0 (64-bit)

> locale:
> [1] C

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base

> Thanks
> -Don

> p.s.
> Just a little background, irrelevant unless one wonders why I¹m using I()
> and \265:

> If I were writing new code I wouldn¹t be using I(), since there are better
> ways now to achieve the same end (preventing the creation of factors in
> data frames), but the scripts that use it are quite old,  originally
> developed in 2001.

> In at least some but perhaps limited contexts, Œ\265¹ produces the greek
> letter mu, and that¹s why I¹m using it. And if I remember correctly, 2001
> is prior to the current R support for locales and extended character sets.
> Using \265 is what I could find at that time to get a mu into my output.

> I came across this while checking some things; it¹s not actually breaking
> my scripts, so I doubt it¹s due to any recent change.


> -- 
> Don MacQueen

> Lawrence Livermore National Laboratory
> 7000 East Ave., L-627
> Livermore, CA 94550
> 925-423-1062

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Gábor Csárdi]

FWIW, I have created a project for an R wiki engine @ github:
https://github.com/gaborcsardi/r-wiki-engine

The idea is that R developers and users can use this project to create
R wikis, by simply cloning it, or including it as a git submodule.

The basis will be Hadley's setup for his books; this way I'll have
something useable almost immediately. I'll try to add more wiki-ish
features, like tags, and search later.

Gabor

On Tue, Sep 9, 2014 at 9:48 AM, Martin Maechler
 wrote:
>> Philippe Grosjean 
>> on Tue, 9 Sep 2014 08:45:14 +0200 writes:
>
> > Yihui and Gábor, I agree with you, and I also think that
> > using Travis CI would be very nice. However, there are
> > hundreds of page on the R wiki to migrate… and syntax is a
> > little bit different than Markdown.
>
> > Of course, a solution would be to start again from
> > scratch, but I think that those who have contributed to
> > the R Wiki deserve more respect. Any suggestion, or idea
> > about this?
>
> (and we have seen more on this thread ..)
>
> As one contributor to the former wiki and maintainer of the
> good olde mailing lists, I completely agree (with
> Yihui and Gábor and you) that it's best to move it over to an
> infrastructure which takes care of authentication of legitimate
> users and protection from thieves burglers, spammers, and the like.
>
> Markdown is definitely much better for R users (given knittr and
> Rmd ..), and github is currently the place to host -- and once
> it ceases to be that, markdown will be easier to migrate from.
>
> Martin
>
> > Best,
>
> > Philippe On 08 Sep 2014, at 23:12, Gábor Csárdi
> >  wrote:
>
> >> I second this suggestion.
> >>
> >> One possible complication I see is that if you would like
> >> to run the R code (to display its output for example),
> >> then AFAIK you cannot simply use Jekyll on Github's side,
> >> but would need some additional infrastructure.
> >>
> >> It might be possible to use Travis (or some other) CI for
> >> it, and avoid installing additional software and/or
> >> servers, but anyway, this requires some care and effort.
> >>
> >> If you don't want to run the code, then it is very easy,
> >> apart from the (one-time) migration cost.
> >>
> >> Best, Gabor
> >>
> >> On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie
> >>  wrote:
> >>> I want to make a humble suggestion: migrate the wiki to
> >>> Github, and build the pages using Jekyll+Markdown. That
> >>> way, I think it will attract more volunteers. Simply
> >>> look how many pull requests that Hadley has got for his
> >>> up-coming book hosted on Github
> >>> (http://adv-r.had.co.nz):
> >>> https://github.com/hadley/adv-r/pulls I have had the
> >>> experience of maintaining web servers and different
> >>> wiki/CMS systems (including Dokuwiki -- I have even
> >>> written a PHP plugin for it), and eventually I found I
> >>> could not afford the time on the job of a system
> >>> admin. Now I never do that again, and I just focus on
> >>> maintaining the content. Let the professionals do the
> >>> hosting and compilation service, and my life has become
> >>> so much better (no more worries about security holes and
> >>> attacks).
> >>>
> >>> Regards, Yihui
> >>> --
> >>> Yihui Xie  Web: http://yihui.name
> >>>
> >>>
> >>> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
> >>>  wrote:
>  Uwe and all,
> 
>  I have problems with the R wiki engine. It seems that
>  there is a systematic attack of the R wiki site that
>  produces an overconsumption of the server's CPU, and
>  consequently, my provider did shutdown the whole
>  SciViews.org web site.
> 
>  Now, it is a bad time for me to work on this (very busy
>  with exams + Master and PhD theses). I am currently
>  looking for an expert in CMS to look at the problem. I
>  don't know when I will be able to solve this and reopen
>  the R Wiki.
> 
>  Best,
> 
>  Philippe
>  ..<°}))><
>  ) ) ) ) ) ( ( ( ( ( Prof. Philippe Grosjean ) ) ) ) ) (
>  ( ( ( ( Numerical Ecology of Aquatic Systems ) ) ) ) )
>  Mons University, Belgium ( ( ( ( (
>  ..
> 
>  On 06 Sep 2014, at 17:28, Uwe Ligges
>   wrote:
> 
> > Rather than asking here, I'd ask Philippe Grosjean
> > directly, hence CCIng.
> >
> > Best, Uwe Ligges
> >
> >
> >
> > On 06.09.2014 01:17, André Z. D. A. wrote:
>> This does not answer you, but if you are looking for
> > something that existed on that wiki, it may help:
>>
>> https

Re: [Rd] Problem with order() and I()

[peter dalgaard]

It's actually a little more complicated. I wrote a note, but it seems to be 
stuck in the outbox on my home machine (I probably forgot to click Send...). 

One important aspect is that

> "x" < "\265g"
[1] NA

which makes me wonder if the bug really is in the case that "works". It seems 
that it is possible to rank() character vectors that contain incomparable 
elements.

-pd

On 09 Sep 2014, at 16:19 , Martin Maechler  wrote:

>> MacQueen, Don 
>>on Mon, 8 Sep 2014 16:06:21 + writes:
> 
>> I have found that order() fails in a rather arcane circumstance, as in
>> this example:
> 
>>> foo <- I( c('x','\265g') )
>>> order(foo)
>> Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
> 
>>> foo <-c('x','\265g')
>>> order(foo)
>> [1] 1 2
> 
> yes, this is not desirable.
> order() in such cases calls xtfrm()  {as documented}
> and that ends up calling rank() and then the internal  .gt()
> where the bug happens because
> 
>> I("x") > I("\xb5g")
> [1] NA
> 
> but really I think the change should happen in xtfrm.Asis(.)
> which I think should drop the class also in this case.
> 
> More on this, once we have fixed it.
> 
> Thank you, Don, very much!
> 
> Martin Maechler,
> ETH Zurich
> 
>>> sessionInfo()
>> R version 3.1.1 (2014-07-10)
>> Platform: x86_64-apple-darwin13.1.0 (64-bit)
> 
>> locale:
>> [1] C
> 
>> attached base packages:
>> [1] stats graphics  grDevices utils datasets  methods   base
> 
>> Thanks
>> -Don
> 
>> p.s.
>> Just a little background, irrelevant unless one wonders why I¹m using I()
>> and \265:
> 
>> If I were writing new code I wouldn¹t be using I(), since there are better
>> ways now to achieve the same end (preventing the creation of factors in
>> data frames), but the scripts that use it are quite old,  originally
>> developed in 2001.
> 
>> In at least some but perhaps limited contexts, Œ\265¹ produces the greek
>> letter mu, and that¹s why I¹m using it. And if I remember correctly, 2001
>> is prior to the current R support for locales and extended character sets.
>> Using \265 is what I could find at that time to get a mu into my output.
> 
>> I came across this while checking some things; it¹s not actually breaking
>> my scripts, so I doubt it¹s due to any recent change.
> 
> 
>> -- 
>> Don MacQueen
> 
>> Lawrence Livermore National Laboratory
>> 7000 East Ave., L-627
>> Livermore, CA 94550
>> 925-423-1062
> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Hodgess, Erin]

I'll do R2HTML, please.

Thanks,
Erin


From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
of Uwe Ligges [lig...@statistik.tu-dortmund.de]
Sent: Tuesday, September 09, 2014 8:53 AM
To: Luca Sartore
Cc: c...@r-project.org; R-Devel
Subject: Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg 
hexbin lgtdl monreg muhaz operators pamr

On 09.09.2014 09:52, Luca Sartore wrote:
> Dear all,
>
> I will pick up monreg.

Please try to coordinate efforts with Scott Kostyshak  who offered the
same thing yesterday.

Best,
Uwe Ligges



> Best regards,
> Luca Sartore
>
>
> 2014-09-08 1:03 GMT+02:00 Uwe Ligges :
>>
>>
>> On 08.09.2014 01:01, Gregory R. Warnes wrote:
>>>
>>> And I’ll pick up hexbin.
>>
>>
>> Err, that one has been adopted a month ago already.
>>
>> open are:
>>
>> SemiPar cghseg monreg
>>
>>
>> Best,
>> Uwe Ligges
>>
>>
>>>
>>> -Greg
>>>
>>> On Sep 7, 2014, at 12:17 PM, Romain Francois 
>>> wrote:
>>>
 I'll pick up operators.

 Le 7 sept. 2014 à 18:03, Uwe Ligges  a
 écrit :

>
>
> On 05.09.2014 20:25, Greg Snow wrote:
>>
>> Uwe,
>>
>> Have all of these packages found new maintainers? if not, which ones
>> are still looking to be adopted?
>
>
> Thanks for asking, the ones still looking to be adaopted are:
> SemiPar cghseg monreg operators
>
> Best,
> Uwe Ligges
>
>
>>
>> thanks,
>>
>> On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges 
>> wrote:
>>>
>>> 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-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>
>>
>>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


 __
 R-devel@r-project.org mailing list
 https://stat.ethz.ch/mailman/listinfo/r-devel
>>>
>>>
>>
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with order() and I()

[MacQueen, Don]

You are welcome.

-Don



Sent with Good (www.good.com)


-Original Message-
From: Martin Maechler 
[maech...@stat.math.ethz.ch]
Sent: Tuesday, September 09, 2014 07:19 AM Pacific Standard Time
To: MacQueen, Don
Cc: R-devel@r-project.org
Subject: Re: [Rd] Problem with order() and I()


> MacQueen, Don 
> on Mon, 8 Sep 2014 16:06:21 + writes:

> I have found that order() fails in a rather arcane circumstance, as in
> this example:

>> foo <- I( c('x','\265g') )
>> order(foo)
> Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed

>> foo <-c('x','\265g')
>> order(foo)
> [1] 1 2

yes, this is not desirable.
order() in such cases calls xtfrm()  {as documented}
and that ends up calling rank() and then the internal  .gt()
where the bug happens because

 > I("x") > I("\xb5g")
 [1] NA

but really I think the change should happen in xtfrm.Asis(.)
which I think should drop the class also in this case.

More on this, once we have fixed it.

Thank you, Don, very much!

Martin Maechler,
ETH Zurich

>> sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-apple-darwin13.1.0 (64-bit)

> locale:
> [1] C

> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base

> Thanks
> -Don

> p.s.
> Just a little background, irrelevant unless one wonders why I¹m using I()
> and \265:

> If I were writing new code I wouldn¹t be using I(), since there are better
> ways now to achieve the same end (preventing the creation of factors in
> data frames), but the scripts that use it are quite old,  originally
> developed in 2001.

> In at least some but perhaps limited contexts, Œ\265¹ produces the greek
> letter mu, and that¹s why I¹m using it. And if I remember correctly, 2001
> is prior to the current R support for locales and extended character sets.
> Using \265 is what I could find at that time to get a mu into my output.

> I came across this while checking some things; it¹s not actually breaking
> my scripts, so I doubt it¹s due to any recent change.


> --
> Don MacQueen

> Lawrence Livermore National Laboratory
> 7000 East Ave., L-627
> Livermore, CA 94550
> 925-423-1062

> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg hexbin lgtdl monreg muhaz operators pamr

[Uwe Ligges]

On 09.09.2014 17:01, Hodgess, Erin wrote:

I'll do R2HTML, please.


Thanks, but a new version with new maintainer is on CRAN already.

Best,
Uwe Ligges




Thanks,
Erin


From: r-devel-boun...@r-project.org [r-devel-boun...@r-project.org] on behalf 
of Uwe Ligges [lig...@statistik.tu-dortmund.de]
Sent: Tuesday, September 09, 2014 8:53 AM
To: Luca Sartore
Cc: c...@r-project.org; R-Devel
Subject: Re: [Rd] Looking for new maintainer of orphans R2HTML SemiPar cghseg 
hexbin lgtdl monreg muhaz operators pamr

On 09.09.2014 09:52, Luca Sartore wrote:

Dear all,

I will pick up monreg.


Please try to coordinate efforts with Scott Kostyshak  who offered the
same thing yesterday.

Best,
Uwe Ligges




Best regards,
Luca Sartore


2014-09-08 1:03 GMT+02:00 Uwe Ligges :



On 08.09.2014 01:01, Gregory R. Warnes wrote:


And I’ll pick up hexbin.



Err, that one has been adopted a month ago already.

open are:

SemiPar cghseg monreg


Best,
Uwe Ligges




-Greg

On Sep 7, 2014, at 12:17 PM, Romain Francois 
wrote:


I'll pick up operators.

Le 7 sept. 2014 à 18:03, Uwe Ligges  a
écrit :




On 05.09.2014 20:25, Greg Snow wrote:


Uwe,

Have all of these packages found new maintainers? if not, which ones
are still looking to be adopted?



Thanks for asking, the ones still looking to be adaopted are:
SemiPar cghseg monreg operators

Best,
Uwe Ligges




thanks,

On Fri, Aug 8, 2014 at 10:41 AM, Uwe Ligges 
wrote:


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-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel







__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel





__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel



__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Baptiste Auguie]

One small technical issue currently limiting the deployment of true
reproducible wikis based on knitr + github-markdown is the lack of reverse
synchronisation between the rendered output (markdown), edited online, and
the original Rmd source. It think the combination of wiki features +
reproducible source code has great potential for community-driven
documentation (even for individual packages), but this relatively new
use-case for reproducible documents may highlight a limitation in knitr's
current framework [1].

On a more general note, and considering the positive sentiment toward
github in the R community, it might be a good time to register a
semi-official R-project organisation to regroup such initiatives,

https://help.github.com/articles/creating-a-new-organization-account

In the long-run, it would be nice to centralise some valuable resources
that have appeared independently over the years, such as the R wiki, the R
graph gallery [?], the unofficial CRAN mirror [2], the unofficial r-source
mirror [3], and probably many others I forget or don't know about.

Regards,

baptiste

[1] related discussion here: https://github.com/yihui/knitr/issues/536
[?] http://addictedtor.free.fr/graphiques/
[2] https://github.com/cran, https://github.com/metacran/
[3] https://github.com/wch/r-source

On 9 September 2014 10:48, Martin Maechler 
wrote:

> > Philippe Grosjean 
> > on Tue, 9 Sep 2014 08:45:14 +0200 writes:
>
> > Yihui and Gábor, I agree with you, and I also think that
> > using Travis CI would be very nice. However, there are
> > hundreds of page on the R wiki to migrate… and syntax is a
> > little bit different than Markdown.
>
> > Of course, a solution would be to start again from
> > scratch, but I think that those who have contributed to
> > the R Wiki deserve more respect. Any suggestion, or idea
> > about this?
>
> (and we have seen more on this thread ..)
>
> As one contributor to the former wiki and maintainer of the
> good olde mailing lists, I completely agree (with
> Yihui and Gábor and you) that it's best to move it over to an
> infrastructure which takes care of authentication of legitimate
> users and protection from thieves burglers, spammers, and the like.
>
> Markdown is definitely much better for R users (given knittr and
> Rmd ..), and github is currently the place to host -- and once
> it ceases to be that, markdown will be easier to migrate from.
>
> Martin
>
> > Best,
>
> > Philippe On 08 Sep 2014, at 23:12, Gábor Csárdi
> >  wrote:
>
> >> I second this suggestion.
> >>
> >> One possible complication I see is that if you would like
> >> to run the R code (to display its output for example),
> >> then AFAIK you cannot simply use Jekyll on Github's side,
> >> but would need some additional infrastructure.
> >>
> >> It might be possible to use Travis (or some other) CI for
> >> it, and avoid installing additional software and/or
> >> servers, but anyway, this requires some care and effort.
> >>
> >> If you don't want to run the code, then it is very easy,
> >> apart from the (one-time) migration cost.
> >>
> >> Best, Gabor
> >>
> >> On Mon, Sep 8, 2014 at 4:15 PM, Yihui Xie
> >>  wrote:
> >>> I want to make a humble suggestion: migrate the wiki to
> >>> Github, and build the pages using Jekyll+Markdown. That
> >>> way, I think it will attract more volunteers. Simply
> >>> look how many pull requests that Hadley has got for his
> >>> up-coming book hosted on Github
> >>> (http://adv-r.had.co.nz):
> >>> https://github.com/hadley/adv-r/pulls I have had the
> >>> experience of maintaining web servers and different
> >>> wiki/CMS systems (including Dokuwiki -- I have even
> >>> written a PHP plugin for it), and eventually I found I
> >>> could not afford the time on the job of a system
> >>> admin. Now I never do that again, and I just focus on
> >>> maintaining the content. Let the professionals do the
> >>> hosting and compilation service, and my life has become
> >>> so much better (no more worries about security holes and
> >>> attacks).
> >>>
> >>> Regards, Yihui
> >>> --
> >>> Yihui Xie  Web: http://yihui.name
> >>>
> >>>
> >>> On Mon, Sep 8, 2014 at 12:10 PM, Philippe GROSJEAN
> >>>  wrote:
>  Uwe and all,
> 
>  I have problems with the R wiki engine. It seems that
>  there is a systematic attack of the R wiki site that
>  produces an overconsumption of the server's CPU, and
>  consequently, my provider did shutdown the whole
>  SciViews.org web site.
> 
>  Now, it is a bad time for me to work on this (very busy
>  with exams + Master and PhD theses). I am currently
>  looking for an expert in CMS to look at the problem. I
>  don't know when I will be able to solve thi

Re: [Rd] Problem with order() and I()

[Martin Maechler]

> peter dalgaard 
> on Tue, 9 Sep 2014 16:36:19 +0200 writes:

> It's actually a little more complicated. I wrote a note, but it seems to 
be stuck in the outbox on my home machine (I probably forgot to click Send...). 
> One important aspect is that

>> "x" < "\265g"
> [1] NA

> which makes me wonder if the bug really is in the case that "works". It 
seems that it is possible to rank() character vectors that contain incomparable 
elements.

> -pd

yes you are right that it is even more complicated.
In both cases, our Scollate() is involved,
(Scollate: the one where we had a discussion about making it part of the C
 level R API, which would help package authors ..)

After

  ch <- c('x','\265g')
  foo <- I(ch)

Of the four expressions,

  order(ch)
  order(foo)
  ch [1] < ch [2]
  foo[1] < foo[2]

only the first one "works", the others give NA or an error because of NA
and the first one is the only of the 4 that does not use
do_relop_dflt()

It's not even clear what we'd want (as I think  pd also alluded to):
Ideally all of these should work consistently, which because of
 "<(.,.)" returning NA in both cases,
would mean that order(ch) also should give an error as order(foo)
{{ an error we should improve the message in any case!!}.
Big Q:  Can we afford  order(ch)  giving an error in such cases.
Pretty high chance that this will "break" much user (and probably
even package) code out there.

Still, the other solution, namely  order(foo) behaving as
order(ch) now does would correspond to the ">" giving FALSE
instead of NA, so this solution is not ok in my view.

Martin


> On 09 Sep 2014, at 16:19 , Martin Maechler  
wrote:

>>> MacQueen, Don 
>>> on Mon, 8 Sep 2014 16:06:21 + writes:
>> 
>>> I have found that order() fails in a rather arcane circumstance, as in
>>> this example:
>> 
 foo <- I( c('x','\265g') )
 order(foo)
>>> Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE 
needed
>> 
 foo <-c('x','\265g')
 order(foo)
>>> [1] 1 2
>> 
>> yes, this is not desirable.
>> order() in such cases calls xtfrm()  {as documented}
>> and that ends up calling rank() and then the internal  .gt()
>> where the bug happens because
>> 
>>> I("x") > I("\xb5g")
>> [1] NA
>> 
>> but really I think the change should happen in xtfrm.Asis(.)
>> which I think should drop the class also in this case.
>> 
>> More on this, once we have fixed it.
>> 
>> Thank you, Don, very much!
>> 
>> Martin Maechler,
>> ETH Zurich
>> 
 sessionInfo()
>>> R version 3.1.1 (2014-07-10)
>>> Platform: x86_64-apple-darwin13.1.0 (64-bit)
>> 
>>> locale:
>>> [1] C
>> 
>>> attached base packages:
>>> [1] stats graphics  grDevices utils datasets  methods   base
>> 
>>> Thanks
>>> -Don
>> 
>>> p.s.
>>> Just a little background, irrelevant unless one wonders why I¹m using 
I()
>>> and \265:
>> 
>>> If I were writing new code I wouldn¹t be using I(), since there are 
better
>>> ways now to achieve the same end (preventing the creation of factors in
>>> data frames), but the scripts that use it are quite old,  originally
>>> developed in 2001.
>> 
>>> In at least some but perhaps limited contexts, Œ\265¹ produces the greek
>>> letter mu, and that¹s why I¹m using it. And if I remember correctly, 
2001
>>> is prior to the current R support for locales and extended character 
sets.
>>> Using \265 is what I could find at that time to get a mu into my output.
>> 
>>> I came across this while checking some things; it¹s not actually 
breaking
>>> my scripts, so I doubt it¹s due to any recent change.
>> 
>> 
>>> -- 
>>> Don MacQueen
>> 
>>> Lawrence Livermore National Laboratory
>>> 7000 East Ave., L-627
>>> Livermore, CA 94550
>>> 925-423-1062
>> 
>>> __
>>> R-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

> -- 
> Peter Dalgaard, Professor,
> Center for Statistics, Copenhagen Business School
> Solbjerg Plads 3, 2000 Frederiksberg, Denmark
> Phone: (+45)38153501
> Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] r wiki

[Gábor Csárdi]

On Tue, Sep 9, 2014 at 10:29 AM, Baptiste Auguie
 wrote:
> One small technical issue currently limiting the deployment of true
> reproducible wikis based on knitr + github-markdown is the lack of reverse
> synchronisation between the rendered output (markdown), edited online, and
> the original Rmd source.

The idea is that you would edit the (r)md file on github, e.g. like this:
https://github.com/gaborcsardi/r-wiki-engine/edit/wiki/welcome.md
You need to fork to do it, unless you are a collaborator.

If you use .md file extensions instead of .rmd, then you even get a
preview. (You can still treat the files as Rmd, of course when
building the web site.) Then, when you save your edit (and are a
collaborator), your edit will be a commit, and Travis will build the
new version of the web page.

If you are not a collaborator, then you need to submit a pull request,
and whenever this is
OK-d, the wiki and web pages will be updated.

It is not exactly a real wiki, but probably as close as you can get
with free services and without setting up a server.

Another possibility would be using the wikis Github provides, for
editing, but one would still need to build the web pages with Travis,
to run the R code, so I am not sure how much that would be better.

The good thing with this setup is, that you can switch to a dedicated
server later, as all the build tools are open-source. Then you would
get a real wiki, but the effort you need is much bigger.

Gabor

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] Problem with order() and I()

[peter dalgaard]

[This is the note I alluded to earlier today.]

On 08 Sep 2014, at 18:06 , MacQueen, Don  wrote:

> I have found that order() fails in a rather arcane circumstance, as in
> this example:
> 
>> foo <- I( c('x','\265g') )
>> order(foo)
> Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
>> foo <-c('x','\265g')
>> order(foo)
> [1] 1 2
> 
> 

The oddity is really that it works (for some value of "works") in the unclassed 
case:

> foo <- I( c('x','\265g') )
> order(foo)
Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
> foo[[1]]
[1] "x"
> foo[[2]]
[1] "\xb5g"
> foo[[1]] < foo[[2]]
[1] NA
> foo[[1]] > foo[[2]]
[1] NA


> fee <- c('x','\265g') 
> fee[[1]]
[1] "x"
> fee[[2]]
[1] "\xb5g"
> fee[[1]] < fee[[2]]
[1] NA
> fee[[1]] > fee[[2]]
[1] NA
> order(fee)
[1] 2 1

Notice that the unclassed `fee` has exactly the same issue that its elements 
are incomparable as `foo` does.

The thing is that xtfrm.AsIs will use elementwise comparison, whereas 
xtfrm.default will use rank(), which somehow manages to do something with 
character vectors for which the sort order is undefined:

> rank(foo)
Error in if (xi > xj) 1L else -1L : missing value where TRUE/FALSE needed
> rank(fee)
[1] 2 1

(Notice that xtfrm calls rank and vice versa, presumably without creating a 
loop. I gave up on sorting out the logic.)

> 
>> sessionInfo()
> R version 3.1.1 (2014-07-10)
> Platform: x86_64-apple-darwin13.1.0 (64-bit)
> 
> locale:
> [1] C
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> Thanks
> -Don
> 
> p.s.
> Just a little background, irrelevant unless one wonders why I¹m using I()
> and \265:
> 
> If I were writing new code I wouldn¹t be using I(), since there are better
> ways now to achieve the same end (preventing the creation of factors in
> data frames), but the scripts that use it are quite old,  originally
> developed in 2001.
> 
> In at least some but perhaps limited contexts, Œ\265¹ produces the greek
> letter mu, and that¹s why I¹m using it. And if I remember correctly, 2001
> is prior to the current R support for locales and extended character sets.
> Using \265 is what I could find at that time to get a mu into my output.
> 
> I came across this while checking some things; it¹s not actually breaking
> my scripts, so I doubt it¹s due to any recent change.
> 
> 
> -- 
> Don MacQueen
> 
> Lawrence Livermore National Laboratory
> 7000 East Ave., L-627
> Livermore, CA 94550
> 925-423-1062
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk  Priv: pda...@gmail.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel